比特币：点对点电子现金论文
原始发布页
打开来源页面查看 1 个交叉存档
我会尽快发布源代码，作为参考，帮助澄清所有这些实现问题。
Ray Dillinger（Bear）写道：
当一枚币被花费时，买方和卖方会对一份（盲化的）交易记录进行数字签名。
只有买方签名，而且没有盲化。
如果有人进行双重支付，那么交易记录就可以被揭盲，从而揭示作弊者的身份。
系统不使用身份，也不依赖事后追责。一切都是预防。
这是通过一种相当标准的选择-披露算法完成的，买方使用秘密份额回应若干挑战。
没有挑战或秘密份额。基本交易就是第 2 节图中所示的内容：一个满足前一笔交易公钥的（买方）签名，以及一个新的（卖方）公钥；下一次花费它时必须满足这个新公钥。
在他们工作时，他们也可能收到与其正在尝试扩展的链一样长的链，其中最后几个“链接”与他们正在工作的链并不共同。他们会忽略这些链。
对，如果长度相等，就保留最早收到的那条，以此打破平局。
如果其中包含双重支付，他们就创建一笔作为双重支付证明的“交易”，将它加入池 A，广播它，然后继续工作。
不需要这样报告“双重支付证明”。如果同一条链包含两笔支付，那么区块无效，会被拒绝。
如果某个区块没有足够的工作量证明，情况也一样。该区块无效，会被拒绝。没有必要传播关于它的报告。每个节点都能看出来，并在转发之前拒绝它。
如果有两条相互竞争的链，每条都包含同一笔交易的不同版本，一条试图把钱给某个人，另一条试图把同一笔钱给另一个人，那么确定哪一笔支付有效，正是整个工作量证明链所要解决的问题。
我们不是在“留意”双重支付，拉响警报并抓住作弊者。我们只是裁定哪一笔支付有效。交易接收方必须等待几个区块，以确保裁定有时间完成。想作弊的人可以随意同时进行双重支付，而他们所能达到的全部效果，就是在几个区块之内，其中一笔支付变得有效，其他支付变得无效。主链中已经有一笔支付后，任何之后的双重支付都会立即被拒绝。
即使较早的支付还没有进入链，如果它已经存在于所有节点的池中，那么所有已经拥有第一笔支付的节点都会拒绝第二笔支付。
如果新链被接受，他们就放弃添加当前的链接，把池 L 中的所有交易放回池 A（连同自开始工作以来收到或创建的交易），从池 A 中删除那些已经属于新链中某个链接的交易记录，然后重新开始工作，尝试扩展新链。
对。他们也会在收到新交易时刷新，因此 L 基本上始终包含 A 中的所有内容。
用 CPU 密集型数字签名算法对包含新块 L 的链进行签名。
这是 Hashcash 风格的 SHA-256 工作量证明（以零开头的部分原像），不是签名。
有没有某种机制确保“链”不只是由最快的 3 或 4 个节点添加的链接组成？因为广播的交易记录很容易错过这 3 或 4 个节点；如果发生这种情况，而这些节点继续主导链条，这笔交易可能永远无法被加入。
如果你把它理解成 CPU 密集型数字签名，那么你可能会以为这是竞相首先完成一项很长的操作，而且最快的节点总是获胜。
工作量证明是 Hashcash 风格的 SHA-256 碰撞寻找过程。这是一个无记忆的过程，你每秒计算数百万次哈希，每次都有很小的机会找到一个解。那 3 或 4 个最快节点的主导程度只会与它们占总 CPU 算力的比例相称。任何节点在任意时刻找到解的机会，都与其 CPU 算力成正比。
届时会有交易费，因此节点会有动力接收并纳入它们能接收的所有交易。当生成的总币数达到预先确定的上限后，节点最终仅靠交易费就能得到补偿。
此外，添加链接到链上的工作量要求应当（同样以指数方式）随前一周添加到该链上的链接数量变化，从而严格控制新币生成的速度（以及通货膨胀）。
对。
你需要币聚合才能实现规模化。应该有一种“可证明”的交易：有人销毁十个单币，并创建一个面额为十的新币，等等。
每笔交易都是这种交易。第 9 节“合并和拆分价值”。
Satoshi Nakamoto
英文原文
展开英文原文
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