-- > James A. Donald wrote: >> OK, suppose one node incorporates a bunch of >> transactions in its proof of work, all of them honest >> legitimate single spends and another node >> incorporates a different bunch of transactions in its >> proof of work, all of them equally honest legitimate >> single spends, and both proofs are generated at about >> the same time. >> >> What happens then?
Satoshi Nakamoto wrote: > They both broadcast their blocks. All nodes receive > them and keep both, but only work on the one they > received first. We'll suppose exactly half received > one first, half the other. > > In a short time, all the transactions will finish > propagating so that everyone has the full set. The > nodes working on each side will be trying to add the > transactions that are missing from their side. When > the next proof-of-work is found, whichever previous > block that node was working on, that branch becomes > longer and the tie is broken. Whichever side it is, > the new block will contain the other half of the > transactions, so in either case, the branch will > contain all transactions. Even in the unlikely event > that a split happened twice in a row, both sides of > the second split would contain the full set of > transactions anyway. > > It's not a problem if transactions have to wait one or > a few extra cycles to get into a block. So what happened to the coin that lost the race? On the one hand, we want people who make coins to be motivated to keep and record all transactions, and obtain an up to date record of all transactions in a timely manner. On the other hand, it is a bit harsh if the guy who came second is likely to lose his coin. Further, your description of events implies restrictions on timing and coin generation - that the entire network generates coins slowly compared to the time required for news of a new coin to flood the network, otherwise the chains diverge more and more, and no one ever knows which chain is the winner. You need to make these restrictions explicit, for network flood time may well be quite slow. Which implies that the new coin rate is slower. We want spenders to have certainty that their transaction is valid at the time it takes a spend to flood the network, not at the time it takes for branch races to be resolved. At any given time, for example at 1 040 689 138 seconds we can look back at the past and say: At 1 040 688 737 seconds, node 5 was *it*, and he incorporated all the coins he had discovered into the chain, and all the new transactions he knew about on top of the previous link At 1 040 688 792 seconds, node 2 was *it*, and he incorporated all the coins he had discovered into the chain, and all the new transactions he knew about into the chain on top of node 5's link. At 1 040 688 745 seconds, node 7 was *it*, and he incorporated all the coins he had discovered into the chain, and all the new transactions he knew about into the chain on top of node 2's link. But no one can know who is *it* right now So how does one know when to reveal one's coins? One solution is that one does not. One incorporates a hash of the coin secret whenever one thinks one might be *it*, and after that hash is securely in the chain, after one knows that one was *it* at the time, one can then safely spend the coin that one has found, revealing the secret. This solution takes care of the coin revelation problem, but does not solve the spend recording problem. If one node is ignoring all spends that it does not care about, it suffers no adverse consequences. We need a protocol in which your prospects of becoming *it* also depend on being seen by other nodes as having a reasonably up to date and complete list of spends - which this protocol is not, and your protocol is not either. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]