Cryptography Mailing List
Bitcoin P2P e-cash paper
2008-11-10 22:18:20 UTC - Original Email - View in Thread
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
> 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
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
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
> 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
> 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
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
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com