12. On Confirmation and Block Time

12

On Confirmation and Block Time

IN THE FIRST ANSWER BELOW, Satoshi addresses double spend and confirmation.

In the second answer, he covers how the difficulty on the proofof-work is adjusted based on the effective time between each block so that the network attempts to maintain 10 minutes per block. Chapter 2’s discussion on proof-of-work compared it to a lottery. A maximum number, in hexadecimal or base 16, is selected, and the miners’ proofof-work consists of generating a number that is less than this number. The number is generated through the Bitcoin system and is random. The first miner to obtain a hash output less than the maximum “wins” the right to process that block and be awarded its transaction fees and the 25 BTC awarded per block. The value chosen for the maximum determines the level of difficulty of the proof-of-work; the larger the value, the more likely a hash output generated by the miner’s system is to fall below the maximum, and the smaller the number, the less likely the miner’s number is to fall below the maximum.

The last question addressed is in regard to the speed of the transaction not being a feature. He makes the point that bouncing checks and credit card chargebacks can take several days or even weeks to process, in contrast to the 60 minutes or so for Bitcoin to validate with a high level of confidence a fully irreversible bitcoin transaction.

Re: Bitcoin P2P e-cash paper

Satoshi Nakamoto Tue, 11 Nov 2008 06:30:220800

James A. Donald wrote:

So what happened to the coin that lost the race?

. . . it is a bit harsh if the guy who came second is likely to lose his coin.

When there are multiple double-spent versions of the same transaction, one and only one will become valid.

The receiver of a payment must wait an hour or so before believing that it’s valid. The network will resolve any possible double-spend races by then.

The guy who received the double-spend that became invalid never thought he had it in the first place. His software would have shown the transaction go from “unconfirmed” to “invalid”. If necessary,the UI can be made to hide transactions until they’re sufficiently deep in the block chain.

Further, your description of events implies restrictions ontiming 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

Sorry if I didn’t make that clear. The target time between blocks will probably be 10 minutes.

Every block includes its creation time. If the time is off by more than 36 hours, other nodes won’t work on it. If the timespan over the last 6*24*30 blocks is less than 15 days, blocks are being generated too fast and the proof-of-work difficulty doubles. Everyone does the same calculation with the same chain data, so they all get the same result at the same link in the chain.

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.

Instantant non-repudiability is not a feature, but it’s still much faster than existing systems. Paper cheques can bounce up to a week or two later. Credit card transactions can be contested up to 60 to 180 days later. Bitcoin transactions can be sufficiently irreversible in an hour or two.

If one node is ignoring all spends that it does not care about, it suffers no adverse consequences.

With the transaction fee based incentive system I recently posted, nodes would have an incentive to include all the paying transactions they receive.

Satoshi Nakamoto

The Cryptography Mailing List