Re: Bitcoin P2P e-cash paper
From: Eugen Leitl <eugen () leitl ! org>
Date: 2008-11-17 19:37:11
Message-ID: 20081117193711.GP11544 () leitl ! org
[Download RAW message or body]

----- Forwarded message from Ray Dillinger <bear@sonic.net> -----

From: Ray Dillinger <bear@sonic.net>
Date: Fri, 14 Nov 2008 18:20:23 -0800
To: satoshi@vistomail.com
Cc: jamesd@echeque.com, cryptography@metzdowd.com
Subject: Re: Bitcoin P2P e-cash paper
X-Mailer: Evolution 2.6.3

Okay.... I'm going to summarize this protocol as I understand it.

I'm filling in some operational details that aren't in the paper
by supplementing what you wrote with what my own "design sense"
tells me are critical missing bits or "obvious" methodologies for
use.

First, people spend computer power creating a pool of coins to use
as money. Each coin is a proof-of-work meeting whatever criteria
were in effect for money at the time it was created. The time of
creation (and therefore the criteria) is checkable later because
people can see the emergence of this particular coin in the
transaction chain and track it through all its "consensus view"
spends. (more later on coin creation tied to adding a link).

When a coin is spent, the buyer and seller digitally sign a (blinded)
transaction record, and broadcast it to a bunch of nodes whose purpose
is keeping track of consensus regarding coin ownership. If someone
double spends, then the transaction record can be unblinded revealing
the identity of the cheater. This is done via a fairly standard cut-
and-choose algorithm where the buyer responds to several challenges
with secret shares, and the seller then asks him to "unblind" and
checks all but one, verifying that they do contain secret shares any
two of which are sufficient to identify the buyer. In this case the
seller accepts the unblinded spend record as "probably" containing
a valid secret share.

The nodes keeping track of consensus regarding coin ownership are in
a loop where they are all trying to "add a link" to the longest chain
they've so far recieved. They have a pool of reported transactions
which they've not yet seen in a "consensus" signed chain. I'm going
to call this pool "A". They attempt to add a link to the chain by
moving everything from pool A into a pool "L" and using a CPU-
intensive digital signature algorithm to sign the chain including
the new block L. This results in a chain extended by a block
containing all the transaction records they had in pool L, plus
the node's digital signature. While they do this, new
transaction records continue to arrive and go into pool A again
for the next cycle of work.

They may also recieve chains as long as the one they're trying to
extend while they work, in which the last few "links" are links
that are *not* in common with the chain on which they're working.
These they ignore. (? Do they ignore them? Under what
circumstances would these become necessary to ever look at again,
bearing in mind that any longer chain based on them will include
them?)

But if they recieve a _longer_ chain while working, they
immediately check all the transactions in the new links to make
sure it contains no double spends and that the "work factors" of
all new links are appropriate. If it contains a double spend,
then they create a "transaction" which is a proof of double
spending, add it to their pool A, broadcast it, and continue work.
If one of the "new" links has an inappropriate work factor (ie,
someone didn't put enough CPU into it for it to be "licit"
according to the rules) a new "transaction" which is a proof
of the protocol violation by the link-creating node is created,
broadcast, and added to pool A, and the chain is rejected. In
the case of no double spends and appropriate work factors for
all links not yet seen, they accept the new chain as consensus.