Hal Finney wrote: > it is mentioned that if a broadcast transaction does not reach all nodes, > it is OK, as it will get into the block chain before long. How does this > happen - what if the node that creates the "next" block (the first node > to find the hashcash collision) did not hear about the transaction, > and then a few more blocks get added also by nodes that did not hear > about that transaction? Do all the nodes that did hear it keep that > transaction around, hoping to incorporate it into a block once they get > lucky enough to be the one which finds the next collision? Right, nodes keep transactions in their working set until they get into a block. If \ a transaction reaches 90% of nodes, then each time a new block is found, it has a 90% \ chance of being in it. > Or for example, what if a node is keeping two or more chains around as > it waits to see which grows fastest, and a block comes in for chain A > which would include a double-spend of a coin that is in chain B? Is that > checked for or not? (This might happen if someone double-spent and two > different sets of nodes heard about the two different transactions with > the same coin.) That does not need to be checked for. The transaction in whichever branch ends up \ getting ahead becomes the valid one, the other is invalid. If someone tries to \ double spend like that, one and only one spend will always become valid, the others \ invalid. Receivers of transactions will normally need to hold transactions for perhaps an hour \ or more to allow time for this kind of possibility to be resolved. They can still \ re-spend the coins immediately, but they should wait before taking an action such as \ shipping goods. > I also don't understand exactly how double-spending, or cancelling > transactions, is accomplished by a superior attacker who is able to muster > more computing power than all the honest participants. I see that he can > create new blocks and add them to create the longest chain, but how can > he erase or add old transactions in the chain? As the attacker sends out > his new blocks, aren't there consistency checks which honest nodes can > perform, to make sure that nothing got erased? More explanation of this > attack would be helpful, in order to judge the gains to an attacker from > this, versus simply using his computing power to mint new coins honestly. The attacker isn't adding blocks to the end. He has to go back and redo the block \ his transaction is in and all the blocks after it, as well as any new blocks the \ network keeps adding to the end while he's doing that. He's rewriting history. Once \ his branch is longer, it becomes the new valid one. This touches on a key point. Even though everyone present may see the shenanigans \ going on, there's no way to take advantage of that fact. It is strictly necessary that the longest chain is always considered the valid one. \ Nodes that were present may remember that one branch was there first and got replaced \ by another, but there would be no way for them to convince those who were not present \ of this. We can't have subfactions of nodes that cling to one branch that they think \ was first, others that saw another branch first, and others that joined later and \ never saw what happened. The CPU power proof-of-work vote must have the final say. \ The only way for everyone to stay on the same page is to believe that the longest \ chain is always the valid one, no matter what. > As far as the spending transactions, what checks does the recipient of a > coin have to perform? Does she need to go back through the coin's entire > history of transfers, and make sure that every transaction on the list is > indeed linked into the "timestamp" block chain? Or can she just do the > latest one? The recipient just needs to verify it back to a depth that is sufficiently far back \ in the block chain, which will often only require a depth of 2 transactions. All \ transactions before that can be discarded. > Do the timestamp nodes check transactions, making sure that > the previous transaction on a coin is in the chain, thereby enforcing > the rule that all transactions in the chain represent valid coins? Right, exactly. When a node receives a block, it checks the signatures of every \ transaction in it against previous transactions in blocks. Blocks can only contain \ transactions that depend on valid transactions in previous blocks or the same block. \ Transaction C could depend on transaction B in the same block and B depends on \ transaction A in an earlier block. > Sorry about all the questions, but as I said this does seem to be a > very promising and original idea, and I am looking forward to seeing > how the concept is further developed. It would be helpful to see a more > process oriented description of the idea, with concrete details of the > data structures for the various objects (coins, blocks, transactions), > the data which is included in messages, and algorithmic descriptions > of the procedures for handling the various events which would occur in > this system. You mentioned that you are working on an implementation, > but I think a more formal, text description of the system would be a > helpful next step. I appreciate your questions. I actually did this kind of backwards. I had to write \ all the code before I could convince myself that I could solve every problem, then I \ wrote the paper. I think I will be able to release the code sooner than I could \ write a detailed spec. You're already right about most of your assumptions where you \ filled in the blanks. Satoshi Nakamoto