8. About Transactions

8

About Transactions

SEVERAL QUESTIONS and answers were covered in this post. Hal Finney, the first recipient of a bitcoin transaction, posed the questions.

In the first part, Satoshi explains how miners retain transactions until they form them into a block.

In the second, he explains how double spending cannot occur on a specific block chain and how only one block chain will prevail given that two miners solve their blocks simultaneously. It also covers how transactions need to be held for an hour by receivers until they are formally confirmed in the block chain. Satoshi refers to six blocks (10 minutes per block times six blocks gives an hour) as an appropriate amount of time for a transaction to be confirmed and forever made a part of the block chain.

To the third question, he describes what an attacker would have to do to “rewrite history”, i.e., reconstruct and change the block chain. To add or remove transactions in prior past blocks would require rewriting them faster than all miners on the network still working on the existing block chain. Remember from the discussion of orphan blocks that the longest block chain is what the network uses. Satoshi says: 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.

The fourth question concerns transaction verification of a payment transfer by a recipient.

The fifth question concerns the role of nodes (i.e., miners) in the system. When one miner discovers the proof-of-work (the hash with the appropriate number of leading 0s), it will broadcast the block it just “mined”, which contains several transactions. Each miner on the network that receives this block has to validate it by checking the validity of each transaction the block contains.

Finally, Satoshi reports that he wrote the code prior to writing the white paper announcing Bitcoin in order to prove to himself that all issues were resolved.

Re: Bitcoin P2P e-cash paper

Satoshi Nakamoto Sun, 09 Nov 2008 11:13:340800

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 aboutthat transaction? Do all the nodes that did hear it keep thattransaction 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-spendof 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 superiorattacker 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 whilehe’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 presentof 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 dependson transaction A in an earlier block.

Sorry about all the questions, but as I said this does seemto 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 whichis 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 inthe blanks.

Satoshi Nakamoto

The Cryptography Mailing List