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. > If someone double spends, then the transaction record > can be unblinded revealing the identity of the cheater. Identities are not used, and there's no reliance on recourse. It's all prevention. > This is done via a fairly standard cut-and-choose > algorithm where the buyer responds to several challenges > with secret shares No challenges or secret shares. A basic transaction is just what you see 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 seller) 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. 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" > which is a proof of double spending, add it to their pool A, > 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 rejected. 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 node could see that \ and reject it before relaying it. If there are two competing chains, each containing a different version of 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 catch the \ cheater. We merely adjudicate which one of the spends is valid. Receivers of \ transactions must wait a few blocks to make sure that resolution has had time to \ complete. Would be cheaters can try and simultaneously 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 invalid. Any later double-spends are immediately rejected once \ there's already a spend in the main chain. Even if an earlier spend wasn't in the chain yet, if it was already in all the nodes' \ pools, then the second spend would be turned away by all those 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 pretty much \ contains everything in A all the time. > CPU-intensive digital signature algorithm to > sign the chain including the new block L. It's a Hashcash style SHA-256 proof-of-work (partial pre-image of zero), not a \ signature. > 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 may 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 small 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. Anyone's chance of finding a solution at any time is \ proportional to their CPU power. There will be transaction fees, so nodes will have an incentive to receive 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. Right. > 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. Every transaction is one of these. Section 9, Combining and Splitting Value. Satoshi Nakamoto