中本聪致 Dustin Trammell：v0.1.3 修复漏洞，提出发送比特币（2009 年 1 月 13 日）
历史档案 / 镜像
打开历史存档来源说明
Published verbatim by Dustin Trammell in November 2013. Full mbox archive distributed as Satoshi_Nakamoto.zip via Trammell's blog (https://blog.dustintrammell.com/i-am-not-satoshi/).
它实际上会把哈希区块发布到一个名为“proof-hashes”的 Google 群组，因此效果与发布到 Usenet 类似。
http://groups.google.com/group/proof-hashes
因为这个群组由我运营，而且它的唯一用途就是存档工作量证明哈希，所以如果你愿意，尽管加入一个账号，让你的系统也在那里发布。
太好了，我之前有一次在 Usenet 上寻找过这样的群组，想看看有需要时可以用什么，但没有真正合适的。我相信发布到 Google 群组要容易得多。
在某些情况下，Usenet 或 Google 群组可以用作补充防御。比特币最脆弱的时候是在早期，那时整个网络的 CPU 算力很小。不过，比特币规模小时，攻击它的动机也很低，这一点形成了抵消。希望只需发展壮大、度过那个阶段，这个简单的解决办法就能奏效。如果不能，那么真到了那个地步，也有一些办法可以让 Google 群组提供帮助。
电子货币和密码学是我非常感兴趣的两件事，所以正如你所料，我在密码学邮件列表看到这个项目发布后立刻被吸引了。需要反馈或测试新功能时尽管联系我，我很乐意帮忙。
我们确实有相似的兴趣！
你知道，我觉得 90 年代对这件事感兴趣的人要多得多，但在基于可信第三方的系统（Digicash 等）失败了十多年之后，他们把这看成了一件没有希望的事。我希望他们能看出区别：据我所知，这是我们第一次尝试不以信任为基础的系统。
币成熟后，会生成一条新的“credit”交易，还是更新现有生成交易行的 credit 字段？
现有的交易行会发生变化。
打开 0.1.3 版本后，我的四条交易仍然都显示“unconfirmed”，但现在描述显示“Generated (not accepted)”。这是否意味着另一个节点先延长了链，而我的币是在一条死分支中生成的？如果是，为什么之前的软件实例没有立即发现这一点，并开始在获胜分支中生成币？是 0.1.0 的漏洞吗？
你说得对，抱歉。这就是 0.1.3 修复的漏洞。通信线程会被阻塞，所以你虽然建立了连接，但过一会儿它们就会静默。你找到区块后无法把它广播给网络，因此它不会进入区块链。你也收不到任何消息来得知网络已经在没有你的情况下继续前进，直到重启软件才会发现。
这个漏洞也是 bitcoin.exe 无法退出的原因。通信线程被阻塞，因此无法退出。比特币会谨慎地关机，以防当时正处于某项重要交易的中间阶段，但实际上强制终止它是完全安全的。
这些问题在 0.1.3 中都修好了。如果你把 IP 给我，我会给你发一些币。
我还有一个问题……是什么阻止拥有最多 CPU 算力的单个节点生成并保留大多数比特币？如果每个节点都独立工作，一个节点明显更强，它不是很可能在其他节点之前得到正确结果吗？算力不足的节点偶尔可能走运一次，但如果算力优势很大，我会预期大多数比特币都由最强的节点生成。
这不像赛车，不是一辆车的速度快一倍，它就总能获胜。一次 SHA-256 运算用时不到一微秒，而每次猜测都有相互独立的成功机会。每台计算机找到哈希碰撞的概率与它的 CPU 算力成线性比例。速度只有一半的计算机，会得到一半数量的币。
我会观察这个实例，看看情况如何……
告诉我结果。如果遇到任何问题，把你的 debug.log 文件发给我。我经常只看这个文件就能弄清楚哪里出了错。
中本聪
英文原文
展开英文原文
It actually posts the hash blocks to a Google Group called 'proof-hashes', so similar result as if it were posting to Usenet.
http://groups.google.com/group/proof-hashes
Since I run that group, and it's sole purpose is to archive proof-of-work hashes, feel free to join an account to have your system post there as well if you like.
Sweet, I was looking for a group like that on Usenet at one point to see what I would use if I needed, and nothing really fit. I'm sure Google groups is a lot easier to post to.
There are some scenarios where a Usenet or Google group could be used as a supplemental defence. Bitcoin is at its most vulnerable in the beginning when the total network CPU power is small. That's offset by the fact that the incentive to attack it is also low when it's small. Hopefully the easy solution of just growing up and getting past that stage will work. If not, there are ways a Google group could help, if it really came to that.
Electronic currency and cryptography are two things that I am very interested in so as you would assume I was drawn to this project immediately when I saw it posted to the Cryptography email list. Feel free to ping me for feedback or to test out new features, I'll be happy to help out.
We definitely have similar interests!
You know, I think there were a lot more people interested in the 90's, but after more than a decade of failed Trusted Third Party based systems (Digicash, etc), they see it as a lost cause. I hope they can make the distinction, that this is the first time I know of that we're trying a non-trust based system.
When the coins mature, will that generate a new 'credit' transaction, or will the existing generation transaction line's credit field be updated?
The existing transaction line will change.
Upon opening version 0.1.3, all four of my transaction entries still say 'unconfirmed', but now the Descriptions say 'Generated (not accepted)'. Does this mean that some other node had extended the chain first and my coins were generated in a dead branch? If so, why did the previous instance of the software not detect this immediately and begin generating coins in the winning branch? Bug in 0.1.0?
You're right, sorry about that. It's the bug that was fixed in 0.1.3. The communications thread would get blocked, so you would make connections, but they would go silent after a while. When you found a block, you couldn't broadcast it to the network, so it didn't get into the chain. You weren't receiving anything either to know that the network had gone on without you, until you restarted it.
The bug is also what caused bitcoin.exe to fail to exit. The communications thread was blocked and failed to exit. Bitcoin does a careful shutdown in case it might be in the middle of an important transaction, but actually it's completely safe to kill it.
This is all fixed in 0.1.3. If you give me your IP, I'll send you some coins.
One other question I had... What prevents the single node with the most CPU power from generating and retaining the majority of the BitCoins? If every node is working independently of all others, if one is significantly more powerful than the others, isn't it probable that this node will reach the proper conclusion before other nodes? An underpowered node may get lucky once in a while, but if they are at a significant horsepower advantage I would expect the majority of BitCoins to be generated by the most powerful node.
It's not like a race where if one car is twice as fast, it'll always win. It's an SHA-256 that takes less than a microsecond, and each guess has an independent chance of success. Each computer's chance of finding a hash collision is linearly proportional to it's CPU power. A computer that's half as fast would get half as many coins.
I'll watch this instance and see how it goes...
Let me know how it goes. If you have any trouble with it, send me your debug.log file. I can often figure out what went wrong just from that.
Satoshi