Elden Tyrell [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-01-02 to 2012-12-24
💬 Posted a total of 5 messages
📚 Participated in the following categories: Bitcoin-development, PROPOSAL
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 10:43:32

- reply

📅 Original date posted:2012-12-23
📝 Original message:On 2012-12-21 17:05:21 +0000, Stephen Pair said:
> Also, identity is one thing, an elaborate trust based identity
> verification system (like CA's) is a whole other thing.
Your distinction between "identity" and "trust-based identity" is one
of the most important insights to emerge from this thread. Thank you
for pointing this out.
> the first task at hand is to implement secure, private messaging...
> it's easy to do and you don't need to solve the PKI problem.

2023-06-07 02:57:38

- reply

📅 Original date posted:2012-01-29
📝 Original message:On 2012-01-23 20:00:59 -0600, Alberto Torres said:
> This proposal describes how to add a hash-tree based check in the
> blockchain that allows to verify if a transaction is unspent without
> downloading and checking all the blockchain. The idea is not new, but
> at the time of this writing there isn't any technical description of
> how this should be done.
Thanks for writing this up (it's high time somebody did). I like your
acronym, but shouldn't it be "MTUO" since you spend *outputs* rather
than *transactions*? A transaction can have multiple outputs, some of
which are spent and others which aren't.
I've added a link to your proposal on the
https://en.bitcoin.it/wiki/Thin_Client_Security wiki page.
> Once 55% of blocks includes a valid MTUT hash in a 2-week timespan,
> they should reject any block with an invalid (i.e. probably malicious)
> MTUT hash block while accepting blocks without MTUT.
Just like OP_EVAL/p2sh, this creates the (small) risk of a blockchain split.
Unlike adding a new transaction type, here it's possible to eliminate
this risk: give each MTUT an additional "prev" pointer (hash of some
prior block) which points to the latest prior block with a correct
MTUT. This produces a "chain within the chain" of blocks that have
valid MTUTs. Hostile miners are free to add bogus-MTUT-blocks; those
bogus blocks will simply never be included in the "inner chain", just
like invalid blocks mined by hostile miners are never included in the
blockchain. By downloading the last day's worth of blocks (which is
not much data at all), a client can see which "inner chain" the
majority of the hashpower believed during the last 24 hours. This
eliminates the need for a vote in any specific block -- in effect you
get a "rolling election".
This "inner chain" approach can be broadened to a K-ary tree by
including K-many prior-block pointers. With one of these in every
block (and sensible choices) you wind up with
O(log_K(chain_length))-operation hash-secure access to arbitrary blocks
in the middle of the chain. This is an important building block for
ultra-high-security thin clients. Even if only a 1/K of the network's
hashpower starts adding these pointers the worst-case number of
operations needed to reach an arbitrary block will still converge
(though much more slowly) towards this ideal.
- e

2023-06-07 02:54:33

- reply

📅 Original date posted:2012-01-02
📝 Original message:On 2012-01-02 14:41:10 -0800, Gregory Maxwell said:
> make this possible: https://bitcointalk.org/index.php?topic=21995.0
Neat! I had a similar idea but you've clearly beat me to [a big part of] it.
> Er, no— if a node controls the private keys for a transaction, and
> that transaction makes it into the chain then it can safely assume
> that its unspent (at least once its buried a few blocks into the
> chain).
I'm not so sure about that. If you accept X successor blocks as proof
that none of the transactions in a block re-used an output, then the
cost of attacking is X*50BTC since the hashpower needed for the attack
could have earned that much reward.
However, an attacker could use the same faked X-block sequence to
attack multiple clients by putting several double-spend transactions in
the first faked block. This would spread out the cost over more than
one attack. So simply checking that the value of the transaction is
less than X*50 isn't necessarily enough, although the logistics of the
attack aren't exactly easy.
There's also the question of knowing what the difficulty for those X
blocks ought to be. If the attacker controls your network connection
(e.g. your ISP attacks you) you wouldn't be able to get a second
opinion on how high the difficulty ought to be, and might get fooled by
X very-low-difficulty blocks that were each produced with a lot less
than 50BTC worth of hashpower.
- e

2023-06-07 02:54:27

- reply

📅 Original date posted:2012-01-02
📝 Original message:On 2012-01-02 05:31:19 -0800, Christian Decker said:
> Later full blocks would be required to detect usable inputs for future
> outgoing transactions.
Er, yes, this is what I meant; I guess I should have been more specific.
So, a paranoid client cannot confirm reciept of coins until it has an
unstubbed copy of the entire chain. It can do other things (like send
coins) using a stubbed chain, but it needs the whole unstubbed chain in
order to be sure that incoming coins haven't already been spent.
Thanks for confirming this.

2023-06-07 02:54:20

- reply

📅 Original date posted:2012-01-02
📝 Original message:Satoshi's paper mentions that storage requirements for the blockchain
can be reduced by deleting transactions whose outputs have been spent.
If I understand correctly, this technique can only be used for reducing
*storage* requirements, not *bandwidth* needed for the initial chain
download by a high-security client that doesn't trust any of its peers
-- right?
The rule is "trust the longest valid chain of blocks". Part of a block
being "valid" is that each transaction's inputs are unspent and their
sum exceeds the transaction's outputs unless it is a coinbase. This
cannot be verified for "stubbed out" transactions -- they have outputs
but no inputs, and aren't coinbases. So a paranoid client booting up
for the first time needs to be given an un-stubbed chain, right?
Of course, if a client decided to accept a stubbed blocks only when the
sum of the difficulties in the blocks after it exceeds some number N,
then attacking it could be made very expensive by picking a large
enough N.
Please let me know if I have misunderstood something.

2023-06-06 01:49:07

- reply

{"author":"Elden Tyrell","date":"2012-01-02T22:23:16","text":"On 2012-01-02 05:31:19 -0800, Christian Decker said:\n> Later full blocks would be required to detect usable inputs for future \n> outgoing transactions.\n\nEr, yes, this is what I meant; I guess I should have been more specific.\n\nSo, a paranoid client cannot confirm reciept of coins until it has an \nunstubbed copy of the entire chain. It can do other things (like send \ncoins) using a stubbed chain, but it needs the whole unstubbed chain in \norder to be sure that incoming coins haven't already been spent.\n\nThanks for confirming this."}

2023-06-06 01:49:03

- reply

{"author":"Elden Tyrell","date":"2012-01-02T05:04:03","text":"Satoshi's paper mentions that storage requirements for the blockchain \ncan be reduced by deleting transactions whose outputs have been spent.\n\nIf I understand correctly, this technique can only be used for reducing \n*storage* requirements, not *bandwidth* needed for the initial chain \ndownload by a high-security client that doesn't trust any of its peers \n-- right?\n\nThe rule is \"trust the longest valid chain of blocks\". Part of a block \nbeing \"valid\" is that each transaction's inputs are unspent and their \nsum exceeds the transaction's outputs unless it is a coinbase. This \ncannot be verified for \"stubbed out\" transactions -- they have outputs \nbut no inputs, and aren't coinbases. So a paranoid client booting up \nfor the first time needs to be given an un-stubbed chain, right?\n\nOf course, if a client decided to accept a stubbed blocks only when the \nsum of the difficulties in the blocks after it exceeds some number N, \nthen attacking it could be made very expensive by picking a large \nenough N.\n\nPlease let me know if I have misunderstood something."}

- reply

- reply

- reply

- reply

- reply