Bitcoin P2P e-cash paper

[James A. Donald]

     --
 > 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 majordomo at metzdowd.com