[137797] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: Bitcoin P2P e-cash paper

daemon@ATHENA.MIT.EDU (Satoshi Nakamoto)
Mon Nov 17 12:04:31 2008

Date: Sat, 15 Nov 2008 12:43:00 +0800
From: "Satoshi Nakamoto" <satoshi@vistomail.com>
Reply-To: satoshi@vistomail.com
To: bear@sonic.net
Cc: cryptography@metzdowd.com, jamesd@echeque.com

I'll try and hurry up and release the sourcecode as soon as possible to =
serve as a reference to help clear up all these implementation questions=

Ray Dillinger (Bear) wrote:
> When a coin is spent, the buyer and seller digitally sign a (blinded)
> transaction record.

Only the buyer signs, and there's no blinding.=20

> If someone double spends, then the transaction record=20
> can be unblinded revealing the identity of the cheater.=20

Identities are not used, and there's no reliance on recourse.  It's all =

> This is done via a fairly standard cut-and-choose=20
> algorithm where the buyer responds to several challenges
> with secret shares

No challenges or secret shares.  A basic transaction is just what you se=
e in the figure in section 2.  A signature (of the buyer) satisfying the=
 public key of the previous transaction, and a new public key (of the se=
ller) that must be satisfied to spend it the next time.

> They may also receive 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.=20

Right, if it's equal in length, ties are broken by keeping the earliest =
one received.

> If it contains a double spend, then they create a "transaction"=20
> which is a proof of double spending, add it to their pool A,=20
> broadcast it, and continue work.

There's no need for reporting of "proof of double spending" like that.  =
If the same chain contains both spends, then the block is invalid and re=
jected. =20

Same if a block didn't have enough proof-of-work.  That block is invalid=
 and rejected.  There's no need to circulate a report about it.  Every n=
ode could see that and reject it before relaying it.

If there are two competing chains, each containing a different version o=
f the same transaction, with one trying to give money to one person and =
the other trying to give the same money to someone else, resolving which=
 of the spends is valid is what the whole proof-of-work chain is about.

We're not "on the lookout" for double spends to sound the alarm and catc=
h the cheater.  We merely adjudicate which one of the spends is valid.  =
Receivers of transactions must wait a few blocks to make sure that resol=
ution has had time to complete.  Would be cheaters can try and simultane=
ously double-spend all they want, and all they accomplish is that within=
 a few blocks, one of the spends becomes valid and the others become inv=
alid.  Any later double-spends are immediately rejected once there's alr=
eady a spend in the main chain. =20

Even if an earlier spend wasn't in the chain yet, if it was already in a=
ll the nodes' pools, then the second spend would be turned away by all t=
hose nodes that already have the first spend.

> If the new chain is accepted, then they give up on adding their
> current link, dump all the transactions from pool L back into pool
> A (along with transactions they've received or created since
> starting work), eliminate from pool A those transaction records
> which are already part of a link in the new chain, and start work
> again trying to extend the new chain.

Right.  They also refresh whenever a new transaction comes in, so L pret=
ty much contains everything in A all the time.

> CPU-intensive digital signature algorithm to=20
> sign the chain including the new block L.=20

It's a Hashcash style SHA-256 proof-of-work (partial pre-image of zero),=
 not a signature. =20

> Is there a mechanism to make sure that the "chain" does not consist
> solely of links added by just the 3 or 4 fastest nodes? 'Cause a
> broadcast transaction record could easily miss those 3 or 4 nodes
> and if it does, and those nodes continue to dominate the chain, the
> transaction might never get added.

If you're thinking of it as a CPU-intensive digital signing, then you ma=
y be thinking of a race to finish a long operation first and the fastest=
 always winning.

The proof-of-work is a Hashcash style SHA-256 collision finding.  It's a=
 memoryless process where you do millions of hashes a second, with a sma=
ll chance of finding one each time.  The 3 or 4 fastest nodes' dominance=
 would only be proportional to their share of the total CPU power.  Anyo=
ne's chance of finding a solution at any time is proportional to their C=
PU power.

There will be transaction fees, so nodes will have an incentive to recei=
ve and include all the transactions they can.  Nodes will eventually be =
compensated by transaction fees alone when the total coins created hits =
the pre-determined ceiling.

> Also, the work requirement for adding a link to the chain should
> vary (again exponentially) with the number of links added to that
> chain in the previous week, causing the rate of coin generation
> (and therefore inflation) to be strictly controlled.


> You need coin aggregation for this to scale. There needs to be
> a "provable" transaction where someone retires ten single coins
> and creates a new coin with denomination ten, etc.=20

Every transaction is one of these.  Section 9, Combining and Splitting V=
alue. =20

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

home help back first fref pref prev next nref lref last post