in email@example.com mail archive
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" <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org
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 =
> 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=
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=
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=
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=
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to email@example.com