--
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 [EMAIL PROTECTED]
