安全与钱包

引用的来信Mike Hearn来源 ↗

顺便说一下，如果你还没看到，论坛上有一个关于 secp256k1 安全性的讨论：

http://www.bitcoin.org/smf/index.php?topic=2699.0

Hal（我猜是 Hal Finney）

对，是他。他在密码学邮件列表上给予了支持，也运行了最早的节点之一。

引用的来信Mike Hearn来源 ↗

似乎认为这条曲线比随机曲线更容易受到攻击。我猜你选择 secp256k1，是为了提到的性能提升？

我必须承认，这个项目在发布前开发了 2 年，面对众多问题，我能花在每个问题上的时间都有限。我找到了关于 SHA 和 RSA 推荐长度的指导，却没找到 ECDSA 的，当时它还比较新。我取了 RSA 的推荐密钥长度，换算成 ECDSA 的等效密钥长度，然后又提高了一些，好让整个应用可以称为具有 256 位安全性。我没找到推荐哪种曲线类型的资料，所以就……选了一条。希望密钥长度足以弥补任何不足。

当时，我担心，即便使用 ECDSA，所需的带宽和存储空间仍会过大，难以实际使用。RSA 的巨大密钥根本不用考虑。那时候，存储和带宽似乎更紧张。我觉得这个大小要么刚刚变得可行，要么很快就会可行。我介绍它时，很惊讶其他人都不担心大小，不过我也惊讶于他们争论的问题之多，更惊讶的是，其中每一个问题我都已想过并解决了。

结果看来，ECDSA 验证时间可能才是更大的瓶颈。（在我的测试中，OpenSSL 每次 ECDSA 验证耗时 3.5ms，也就是每秒大约 285 次验证。）客户端版本绕过了这个问题。

随着情况发展，需要运行全节点的人数，比我最初想象的更少。如果处理负载变得很重，网络只靠少量节点也能正常运作。

抱歉，其实是 ECDSA（椭圆曲线数字签名算法），不是 RSA。我不该说「质数」。ECDSA 生成密钥对花不了多少时间。

引用 · 发言者未注明

这里有一篇论文声称能在 2^52 次密码运算内找到 SHA-1 碰撞。而一个最优安全的哈希需要 2^80 次运算。2^52 仍然很大，但已经进入集群和僵尸网络的射程。

2^80 是指能用生日攻击的情况。这里用不了生日攻击，因此难度是完整的 2^160 位。不过，如果你要攻击的是 100 万（2^20）笔交易中的任意一笔，可以做部分生日攻击：2^160/2^20 = 2^140。

比特币地址是唯一用到 160 位哈希的地方。其他一切都是 SHA-256。计算方式是：

bitcoinaddress = RIPEMD-160(SHA-256(publickey))

如果我说错了请纠正我（拜托，我乐意认错），但我认为这种情况下对 RIPEMD-160 很难实施分析型攻击。分析型攻击会指定某个输入范围或模式去尝试，大幅提高找到碰撞的概率。而在这里，你对 RIPEMD-160 的输入没有这种控制力，因为输入是 SHA-256 的输出。如果分析型攻击帮你找到一个能产生碰撞的 RIPEMD-160 输入，你拿它怎么办？你还得让 SHA-256 输出那个值，因此你照样还得破解 SHA-256。

对暴力破解而言，RIPEMD-160(SHA-256(x)) 并不比单独的 RIPEMD-160 更强。但对分析型攻击而言，似乎必须同时分析攻击 RIPEMD-160 和 SHA-256。如果我错了，那强度就等于 RIPEMD-160，SHA-256 只是充当一轮密钥加强而已。

其他参与者原话knightmbJuly 25, 2010原帖 ↗

如果我算出公钥 123456 生成哈希 ABCD

而

公钥 654321 也生成哈希 ABCD

我手里仍然没有私钥。

但照你的说法，我只需要公钥 654321，就能冒充公钥 123456 去花币。

你仍然得用公钥 654321 签名。你需要用一个自己知道私钥的公钥去找碰撞。

当你认领一笔比特币地址交易时，你给出与哈希匹配的公钥，然后必须用那把钥签名。

Red 的意思是：快速生成不安全的公钥很容易，你可以先找到碰撞，再去破解公钥拿到私钥。

他指出，如果要求公钥必须是安全的那种——即必须花费大量工夫才能找到生成它所需的质数——那安全性就会高于仅靠哈希函数的水平。想暴力破解的人每次尝试都得花时间生成一把钥。

Red，谢谢你先私下告诉我！请发出来吧（也替大家解除悬念！）

他的观点是：支付到比特币地址的交易，其安全性受制于哈希函数的安全性。为了让比特币地址简短，它是公钥的哈希，而非公钥本身。攻击者只需要破解哈希函数，不需要破解 ECDSA。

最好先私下告诉我，以便先修复。

我刚把我的 e-mail 地址发给你了。（或者在这里 PM 我也行）

SHA256 不同于从 128 位到 160 位那一步。

打个比方，它更像从 32 位到 64 位地址空间那一步。16 位计算机的地址空间我们很快用完了，32 位计算机在 4GB 处用完了，但这不意味着 64 位也会很快用完。

在我们有生之年，SHA256 不会被摩尔定律式的算力提升攻破。如果它会被攻破，那会是某种突破性的破解方法。能把破解 SHA256 所需的计算量降到可行范围的攻击，很可能也会顺带重创 SHA512。

如果我们看到 SHA256 的弱点在逐渐显现，可以在某个区块号之后过渡到新的哈希函数。所有人必须在那个区块号之前升级软件。新软件会给所有旧区块再存一个新哈希，确保它们不会被换成另一个带相同旧哈希的区块。

其他参与者原话llamaJuly 01, 2010原帖 ↗

但是，如果发生的是签名被攻破（也许整数分解被解决了？量子计算机？），那么就算对最后一个有效区块达成共识也毫无意义。

没错，如果它是突然发生的。如果它是渐进的，我们仍能过渡到更强的方案。你第一次运行升级后的软件时，它会用新的更强签名算法给你所有的钱重新签名。（方式是创建一笔使用更强签名、把钱转给自己的交易）

这里有一个对类似问题的回答，关于如何从重大故障中恢复。

https://www.bitcoin.org/smf/index.php?topic=191.msg1585#msg1585

中本聪原话中本聪June 14, 2010原帖 ↗

如果 SHA-256 被彻底攻破，我想我们可以就"麻烦开始之前哪条是诚实的区块链"达成共识，把它锁定，然后用一个新的哈希函数从那里继续。

如果哈希崩溃是渐进发生的，我们可以有序地过渡到新哈希。软件可以设定为在某个区块号之后启用新哈希。所有人都得在那之前升级。软件可以保存所有旧区块的新哈希，确保不能使用与旧哈希相同的不同区块。

SHA-256 非常强。它不像 MD5 到 SHA1 那种渐进的一步。除非出现某种重大的突破性攻击，它可以用上几十年。

如果 SHA-256 被彻底攻破，我想我们可以就"麻烦开始之前哪条是诚实的区块链"达成共识，把它锁定，然后用新的哈希函数从那里继续。

如果哈希是逐渐失效的，我们可以有序地过渡到新哈希。软件可以被设定为在某个区块号之后开始使用新哈希。所有人都必须在那时之前升级。软件可以保存所有旧区块的新哈希，确保无法使用一个与旧哈希相同的不同区块。

其他参与者原话DataWraithMay 19, 2010原帖 ↗

容我插一句，问一下为什么会这样？在我看来，如果 Bitcoin 用公钥密码学来转移比特币的所有权，那么加入一条只有收款方可读的短消息应该是轻而易举的事。

差不多，但还不完全准确。Bitcoin 用的是 EC-DSA，它只能做数字签名，不能加密。RSA 两者都能，但我没用它，因为它大出一个数量级，会不切实际。

每个比特币地址都有独立的公钥/私钥对。不存在一把解锁一切的单一私钥。比特币地址是公钥的 160 位哈希，系统里其他一切都是 256 位的。

如果发生碰撞，撞出者可以花掉发往那个地址的任何钱。只是发往那个地址的钱，而不是整个钱包。

如果你存心要制造碰撞，目前生成一个碰撞的比特币地址，所需时间是生成一个区块的 2^126 倍。你靠生成区块能赚到多得多的钱。

生成随机种子时，已经充分采集了各种随机性来源。在 Windows 上，它使用全部性能监视器数据——自你的计算机启动以来的每一项磁盘性能、网卡指标、CPU 时间、分页等。Linux 有内建的熵收集器。除此之外，每当你在 Bitcoin 窗口里移动鼠标，你就在产生熵，熵还会从磁盘操作的计时中采集。

是真的。用按 IP 发送选项，你就是在把币发给应答那个 IP 的任何人。发送到比特币地址，则没有这个问题。

计划是实现一个 IP + 比特币地址的组合选项，兼得两者之利。每笔交易仍会用不同的地址，但收款方会用给定的比特币地址，对这个一次性地址签名，以证明它属于预期的收款人。

此前来信Mike Hearn→ 中本聪2009-04-18核对英文来源 ↗

你好，中本聪：

我给你发了 32.51 枚币，我的比特币地址是 1JuEjh9znXwqsy5RrnKqgzqY4Ldg7rnj5n

我目前的 IP 是 84.73.233.199，不过这是一台笔记本电脑，你处理这封邮件时，它不一定在线。我建议改用比特币地址。如果间接转账也能使用同样的备注功能，会很方便。能不能用收款人的公钥加密备注，再把它放进区块里？

我转回了 32.51 和 50.00。

我非常想找到一种办法，在间接转账中附带备注，但实在没有办法。比特币使用 EC-DSA，这对让区块链足够紧凑、能在当今技术条件下实际使用至关重要，因为它的签名比 RSA 小一个数量级。但 EC-DSA 不能像 RSA 那样加密消息，只能用来验证签名。

这个钱包之前是配合什么用的？早期的账户补丁还是 git 构建？

出错是在加载钱包时。我想一定是在这段里：

else if (strType == "acentry")
    {
        string strAccount;
        ssKey >> strAccount;
        uint64 nNumber;
        ssKey >> nNumber;
        if (nNumber > nAccountingEntryNumber)
            nAccountingEntryNumber = nNumber;
    }

你能用这个检查：

else if (strType == "acentry")
    {
        string strAccount;
        assert(!ssKey.empty());
        ssKey >> strAccount;
        uint64 nNumber;
        if (ssKey.size() != 8 )
            printf("***** %s %d
", strAccount.c_str(), ssKey.size());
        assert(ssKey.empty() == false);
        ssKey >> nNumber;
        if (nNumber > nAccountingEntryNumber)
            nAccountingEntryNumber = nNumber;
    }

git 上某个时期是否有过一个账户功能的过渡版本，其键仅有 ("acentry", "account")？

如果你有 gdb，能在 gdb 里运行它并做一次回溯。

gdb --args bitcoin ...

run

(等待异常出现)

bt

引用 · 发言者未注明

它会自动同步吗？

完全不会。不建议也不支持使用多份 wallet.dat，事实上整个比特币的设计就是为了防住这种用法。两份副本都会被搞坏。

如果你想把多台机器上生成的币并进一个钱包，现在更好的办法是在那些机器上跑 getwork 挖矿程序。jgarzik 有个 CPU 挖矿程序，支持 tcatm 的 4 路 SSE2，因此如果你用的是 AMD 或较新的 Intel（酷睿 3、5 或 7），在 Windows 上最高能比内置 SHA 快一倍。

新的演示版 CPU 挖矿程序已发布：

http://bitcointalk.org/index.php?topic=1925.0

SVN rev 163（版本 0.3.13.3）加入了密钥池功能。预生成的新密钥先在队列里放置一段时间再启用，这样 wallet.dat 的备份就持有你将来会用到的密钥。

目前我把默认池大小设为 100。能用 -keypool= 配置。注意，增大池需要一些时间，因此别玩过头。磁盘占用约为每把密钥 1K。

恢复方面我还没有处理。如果你真的恢复了一个旧的 wallet.dat，我想你恐怕得删掉 blk*.dat，以便在重新下载时找回自己的交易。

我做的测试还比较有限。在它经过更多测试之前，网站服务器恐怕不该用它。

rpc backupwallet 已进 SVN rev 147。

我本来在另一个主题里发，这里再重复一遍，这个主题看起来更切题。

备份的主要改进会是预生成的密钥池，以及加载时重新扫描、从区块历史里捞出被漏掉的交易。那样一次备份就能管用很久。

我正准备发和你一样的想法，nelisky。

加一个 json-rpc 命令如何：锁定钱包、刷盘、把 wallet.dat 拷贝到你指定的位置，然后解锁？这比密钥池工程量小，也许可以先做。

拷贝文件最简单的可移植方法是什么？Boost 里有现成的吗？

该叫什么名字？也许：

backupwallet

在有时间好好写代码解决之前，任何备份流程/办法都只是权宜之计。在代码到位之前，我们可以先用文字缓解局面。

备份的主要改进会是预生成的密钥池，以及加载时重新扫描、从区块历史里捞出被漏掉的交易。那样一次备份就能管用很久。

其他参与者原话sirius-mAugust 11, 2010原帖 ↗

我在 FAQ 里加了「每笔交易之后都要备份」的警告。顺便问一句，备份之前有必要停掉客户端吗？那有点麻烦。自动备份确实会很有用。

如果在备份前的几秒钟内（比如 5 秒）你什么都没做、也没收到付款，那么不停客户端直接备份也行。

其他参与者原话grideconAugust 11, 2010原帖 ↗

等等，我又糊涂了。我一直以为那个意外之处的关键是：Bitcoin 被编程为在*每一笔*交易时「清空你的钱包」。

不，它通常不会在每笔交易时清空你的钱包。它会用能找到的最小比特币集合凑出接近的金额。这个例子里，不走运，他的钱包里只有一张 9000 BTC 的整钞，必须破开它才能拿到 1 BTC 和 8999 BTC 的找零。

我不明白它怎么会让你在未成熟时发送。你的余额应该低于那个金额才对。它应该显示余额 0.01，对吧？我这样做的话，它会提示 "you don't have enough money"，命令行下是 "Insufficient funds"。

你发送的时候，它说还差多少个区块成熟？

有可能这笔交易最终还是会成功。

你有没有以任何方式复制或移动过 wallet.dat？

我们应该在钱包里预生成一批备用地址，需要新地址时取用。它们不大，多存一些也无妨。这样也能应对另一种情况，适用范围更广：某人做了备份，之后请求了一个新地址并用它收了一大笔款。也许应该分设几个队列，免得某一用途耗尽备用地址，导致其他用途无地址可用。

这些地址会照常创建并存在常规位置，同时登记在另一个「已创建但从未使用」的名单上。请求地址时，从未使用队列队首的地址被发放，同时创建一个新地址加到队尾。

区块加载代码里有某种重新扫描机制，本来是用来修复有人复制了 wallet.dat 的情形。我需要确认，这个重新扫描机制能否从已经收到的区块中，重新找出那些因恢复钱包备份而丢失记录的收款。

嗯，做个备份没坏处，定期备份也是好习惯，不过不用，安装这个之前不需要备份。

你比我发回复还快就自己搞明白了。

看起来 laszlo 构建的 Berkeley DB 带的 database/log.* 文件与我们的不兼容。.dat 文件没问题，它们的格式不应改变。所有数据都存在 .dat 文件里。你自己的所有数据都存在 wallet.dat 里。如果你当时等它重新下载区块链，你的缺失交易和生成记录就会随着区块链推进到那些交易被记录的位置而出现。

你把目录拷了过来、只排除 log.0000000002，那是最好的解法。现在应该没问题了。

database/log.* 文件只包含临时数据库数据。如果你上次是正常退出 bitcoin 的——不是被强杀或崩溃——那么 database/log.* 文件通常可以安全删除。它们只在这种情况有用：如果数据库执行某个事务的过程中，计算机崩溃，或程序被终止、崩溃，这些文件能帮助它恢复，避免数据丢失。

请尽量继续使用 v0.3，别退回 v0.2.10。

其他遇到这个问题的人：把 database\log.000000000* 文件挪到别处去。（如果之后一切正常，可以稍后删掉它们）

我不愿让安装程序去删除或移动那些文件。如果上一次运行是崩溃或被杀而停止的，那样做就是错的。

我已把这个修复上传到 SVN。它会在加载时监视已花掉的比特币并更新你的钱包，也会随区块到来持续更新。我还放了一条更好的错误信息，但应该永远不会碰到它，因为它总能提前发现已花掉的比特币——除非你同时在两台电脑上把同一笔钱花掉。

想试用的话，请通过私信或邮件告诉我你的邮箱地址和操作系统（win、linux 32 位、linux 64 位），我会把文件作为附件发给你。

重新同步的做法是遍历你的钱包，对照区块索引，找出你当前这台电脑不知道已被花掉的交易。如果你在另一台用钱包副本的电脑上花了钱，或者你不得不把钱包恢复到花钱之前的备份，就会出现这种情况。目前软件只是默认自己总是知道哪些交易已花掉，因为花钱时它会在 wallet.dat 里做标记。

钱包合并工具可以做，但一旦重新同步解决了大部分问题，对它的需求就小多了。有了重新同步，你把一个钱包里的全部钱发给另一个钱包，效果差不多。接收方重新同步后发现所有重叠的比特币都已花掉，然后在新的交易里再收一遍。

到处复制钱包文件，就会出现这种情况。如果你把钱包文件复制到第二台电脑，两台机器都会以为钱包里的钱是自己的。一台花掉了其中一些，另一台却并不知道这些比特币已被花掉，就会试图再花一次——你碰到的，就是这个错误。

既然现在明确了这是条关键错误信息，它应该写成类似"这笔钱似乎已被花掉……如果你在另一台电脑上使用过钱包文件的副本，就可能发生这种情况。"

你可以移动或备份钱包文件，但各个副本必须保持单一的使用和更新顺序，同一时间只能在一处使用。一旦把钱转出去，就不能再使用任何先前的副本。

这引出了一个好问题。对于恢复一份可能早于某次花钱之前的备份的情况，我们需要加上重新同步的功能，找出哪些比特币已被花掉。这不难做，只是还没实现。我加进清单了。有了它，多数情况下能直接修好，而不是抛出那条错误信息。

引用的来信Dustin D. Trammell来源 ↗

关于这个话题，我想到一点：如果系统故障，可能会丢失 BitCoin。程序似乎没有在其运行目录中保存任何数据，所以我猜它把数据保存在注册表和其他位置（我还没有打开 ProcessExplorer 自己检查）。因此，也许应该让程序能够把恢复所需的一切导出到一个文件中，便于备份到系统以外。

文件位于“%appdata%\Bitcoin”，需要备份的就是这个目录。数据存储在事务型数据库 DBM 中，所以如果发生崩溃或断电，应该不会丢失。

%appdata% 的访问权限按用户区分。大多数新程序，例如 Firefox，都把设置文件放在那里，尽管 Microsoft 每发布一个 Windows 版本就更改目录名，而且目录名里全是空格，长得超出了屏幕。

引用的来信Dustin D. Trammell来源 ↗

今天我还注意到，关闭程序时，它似乎没有正常关闭网络套接字（TCP RST 开始满天飞）。大概可以放进低优先级待办事项里（：

刚刚已为下一个版本添加了解决这个问题的代码。

Satoshi

如果你编译这些依赖库，告诉我进展如何。在 Windows 上编译东西总是比在 Linux 上更麻烦。我一直很讨厌依赖一大堆大型库的项目，但这里没法避免，每一个都是必需的。

我还是没弄明白，你的磁盘满了之后，为什么出现的是读取异常，而不是写入异常。虽然可能性不大，但这件事也许破坏了你的区块数据文件。要是这样，可能还会出现类似的异常；如果状态栏里的区块数量不再增加，也说明有问题。此时此刻，区块数量是 375。

如果有问题，删除区块文件就能轻松解决，步骤如下：

（退出 Bitcoin，并确认它已经停止运行）

cd /d "%appdata%\bitcoin"

（先备份这个目录）

del blk0001.dat
del blkindex.dat

然后它会重新下载区块链。在下载完成之前，你的交易和生成的区块会显示为 0/unconfirmed（0 次确认／未确认）。

最重要、必须备份的文件是 wallet.dat。如果 bitcoin 正在运行，你就必须备份整个 %appdata%\bitcoin 目录，包括 database 子目录；不过，即使它没有运行，每次都备份整个目录也总让人更放心。

可惜，数据库会把自己的文件命名为“log.0000000001”。对其他人来说，“log”意味着可以随便删除；但对做数据库的人来说，它意味着删了就会丢掉其他文件里的全部内容。我把这些文件放进 database 子目录，尽量避免它们被误删。之后我会编写代码，在每次钱包发生变化后刷新日志，让 wallet.dat 几乎随时都可以安全地单独保存。

Satoshi

引用 Hal 的来信Hal Finney来源 ↗

你好，Satoshi——抱歉今天没能多做一些，看起来我这周会很忙。这次我又在 MSVC 调试器下启动了 0.1.3，如果今晚它再次崩溃，我也许能拿到更多信息。

我现在想起来了，昨晚我的磁盘满了。我下载了一些依赖库（boost 等），打算试着自己编译，而我的磁盘本来就已经很满了。我很确定，这就是导致 0.1.3 崩溃的原因。我附上了 debug.log，里面还包括另外几次运行的记录。错误出现在日志大约三分之一的位置，内容是：

EXCEPTION: NSt8ios_base7failureE CAutoFile::read : end of file

以如今大家使用的磁盘容量来说，正常情况下这种事应该很少发生。

Hal

其他参与者原话da2ce7December 11, 2010原帖 ↗

直接向 IP 地址转账似乎是个显而易见的攻击面。

那也得先找到有人开启了这个功能才行。它默认是关闭的。

其他参与者原话witchspaceDecember 11, 2010原帖 ↗

没有办法绝对保证不存在缓冲区溢出攻击。不过，用一种通过检查数组下标来避免缓冲区溢出的语言实现客户端（Python、Java、C# 等）会有帮助。

全程用的都是 STL。几乎不存在什么缓冲区。

它不必是那么破坏性的变更。新节点可以在很长一段时间内继续接受旧交易，直到多数节点已升级，再开始拒绝没有 PoW 的交易。或者，它们可以永远接受旧交易，但每个时间段只限一定数量。

我想过很多次给交易加 PoW，但通常想来想去，觉得 0.01 手续费本质上与之相似且更好。0.01 基本就是一份工作量证明，但不是浪费。不过如果问题出在验证大量交易上，那 PoW 的验证可以更快。

一种能缓解多类问题的办法，是实现前面提到的想法：检测收到区块的频率是否出现了不太可能由偶然因素造成的骤降。这样攻击者仍需要掌握网络算力的相当部分，才能从 DoS 攻击中获益。

其他参与者原话gavinandresenAugust 11, 2010原帖 ↗

Bitcoin 的 p2p 网络容易受到各种拒绝服务攻击。

好了，我把话说出来了。

+1

此刻任何演示性测试都只能证明我们已知的东西，还会把开发时间从强化系统挪去救火。

0.3.2 加了一些安全防护，把区块链锁定到当前时点，万一有人拿到 50%，也能限制一点损害。

但如果有人握有 50% 以上的 CPU 算力且心怀恶意，他们能证明设计文档里已经写明的那件事。

此前来信Dustin D. Trammell→ 中本聪2009-01-15核对英文来源 ↗

很高兴看到，你考虑过比特币客户端向自己付款的情况，并在交易日志里给出了合适的说明 (:

我这么做，主要是为了抓取交易期间的网络数据包，进行分析。由于不知道你的数据包结构，我只能在包里看到一点明文信息，主要是交易详情里显示的姓名、备注等内容。线路上还出现了‘version’和‘reply’等其他几个字符串，不过剩下的内容就很难辨认了。

思考交易时，我意识到，除了 IP 地址或比特币地址，没有其他可识别的信息。对于通过 IP 进行的交易，比特币客户端似乎相信，自己连接到的 IP 确实就是这笔交易预定的收款人。发起中间人攻击、窃取收到的付款其实很容易。设想我和一位同事各自的工作站都在同一个局域网里。我如果居心不良，可以在本地广播域里进行 ARP 欺骗，让所有发往他工作站的流量都经过我的工作站中转。我们俩都不是好员工，都玩当下流行的大型多人在线角色扮演游戏，还喜欢用比特币买卖游戏物品。我很容易监视 TCP 端口 8333 上传入的连接，让我的工作站成为这些连接的终点，而不再转发给他的工作站。是的，这有点绕，但能说明问题。这类攻击可以发生在交易双方之间路由上的任意一跳。如果我是美国某家大型 ISP 里作恶的管理员——你明白我的意思。

我建议不要允许用网络地址作为预定收款人的地址。我想，始终要求使用比特币地址来交易，会更安全一些。如果我理解这种方式是如何工作的，你只是把交易计算进区块链，再让预定收款人自己‘发现’它，对吗？另一种办法，是让网络节点提供解析服务：它们向其他节点询问某个比特币地址对应的网络地址，如果那个节点在线，等网络对这个地址达成共识后，发送方的比特币程序再直接连接过去。因为比特币地址与节点的密钥绑定，我想应该能设计一种办法，证明发送节点拥有那个比特币地址；如果是这样，就不继续进行交易。至少，如果你打算保留用 IP 指定收款人的方式，我建议允许比对双方共享秘密的哈希，或者其他中间人不知道的内容。不过，既然加密机制和生成好的密钥本来就已经具备，直接使用它们会是强得多的方案。

还是说我想得太多了，网络连接只是为了立即通知交易，以及传递备注之类的上下文信息？比特币程序提到要取得收款人的公钥，还做了其他几件事；从网络流量来看，它做的似乎远不止发送一条简单通知。

回头再聊。

-- Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

我把攻击分为两类：

1. 只有确实处在通信链路中的人 才能实施的攻击
2. 互联网上任何人在任何地方都能实施的攻击

第 1 类让你面临来自家中或公司局域网内人员、沿途互联网服务提供商管理员，以及接收方局域网内人员的攻击。第 2 类则让你面临十亿人的潜在攻击，其中任何人都可以自行决定成为攻击者，而且只要开发出一种攻击技术，就能攻击多名受害者，取得规模效应。

通过 IP 发送时会请求一个新的公钥，所以，是的，它容易受到第 1 类中间人攻击。如果担心这个问题，发送到比特币地址就没有这个弱点，不过隐私上会有一点取舍。我感觉，大多数时候，人们会从未使用 SSL 的网站和未签名的明文电子邮件中取得比特币地址，而这些途径本来就容易受到第 1 类攻击，以及通过 DNS 污染实施的第 2 类攻击。

一个解决办法是发送时同时使用 IP 和比特币地址（也许像 1.2.3.4-1Kn8iojk... 这样），接收方用比特币地址的公钥为新公钥签名，证明你确实是在向自己以为的那个人发送。如果系统开始用于真正的商业用途，我一定会实现这一点。另一种办法是使用 SSL。

就目前而言，很明显，如果你向一个 IP 发送，却没有提供接收方的其他任何身份信息，那就是盲目地发送给回应这个 IP 的任何人。

以后还会增加一个功能：可以选择加密钱包。

引用的来信Dustin D. Trammell来源 ↗

如果我正确理解了做法，你只是把这笔交易计算进区块链，然后让预定接收方“发现”它，对吗？

没错。

引用的来信Dustin D. Trammell来源 ↗

另一种办法是让网络节点提供解析服务，彼此询问某个 BitCoin 地址对应的网络地址。如果该节点在线，等网络就这个地址达成一致后，发送方的 BitCoin 程序就直接连接过去。

如果只需要比特币地址，在后台就能确定 IP，会很方便。不过可能会有隐私或拒绝服务方面的问题。当然，在实现另一种发送方式之前，现在有充足的时间把设计想清楚，确保这是最好的办法。

Satoshi

引用的来信John Levine来源 ↗

引用的中本聪旧文中本聪来源 ↗

只要诚实节点掌握网络中最多的 CPU 算力，它们就能生成最长链，超过任何攻击者。

但事实并非如此。坏人经常控制着由 100,000 台甚至更多机器组成的僵尸网络。我认识一些维护垃圾邮件僵尸机黑名单的人，他们告诉我，经常一天就看到一百万台新僵尸机。

这也是 hashcash 在今天的互联网上行不通的原因 ——好人的计算能力远远不如坏人。

谢谢你提出这一点。

我那句话其实还可以说得更明确。要求是，好人合计拥有的 CPU 算力要超过任何单个攻击者。

会有许多较小的僵尸网络，它们的规模不足以压倒整个网络，但仍能通过生成比特币来赚钱。这样一来，较小的僵尸网络就是“诚实节点”。（我需要找一个比“诚实”更好的词。）越多的小型僵尸网络转而生成比特币，压倒网络的门槛就越高，使得更大的僵尸网络也变得不足以压倒它，于是它们不如也去生成比特币。按照“长尾”理论，小型、中型和只是较大型的僵尸网络加在一起，规模应该远大于最大的僵尸网络。

即使坏人真的压倒了网络，也并不意味着他会立刻发财。他能做的只是拿回自己花出去的钱，就像开出一张会被退票的支票。要利用这一点，他必须先从商家那里买东西，等货物发出后，再压倒网络，试图把钱拿回来。我不认为他靠这种类似盗刷的骗局，能赚得比生成比特币更多。有了那么大的僵尸网络，他能生成的比特币会比其他所有人加起来还多。

比特币网络实际上可能会让僵尸网络转去生成比特币，从而减少垃圾邮件。

Satoshi Nakamoto

其他参与者原话theymosOctober 21, 2010原帖 ↗

他的区块数一直「卡」在 1698。

他在难度 1.0 下生成无效区块。他的 blk0001.dat 或 blkindex.dat 文件里一定有一条损坏的记录。他只需删掉 blk*.dat 让它重新下载。

安全锁定检测到了问题，显示着「WARNING: Displayed transactions may not be correct!」，因它看到了一条存在但无法接受的更长链。安全锁定不能停止挖矿，否则会制造一种攻击可能。

其他参与者原话gavinandresenOctober 22, 2010原帖 ↗

在你拥有截至最后一个区块检查点的全部区块之前，Bitcoin 客户端实在不该允许挖矿。

好主意，我做了一个改动，确保在下载到检查点区块 74000 之前不挖矿。

目前，能不能请一些用静态 IP、可接受入站连接、正在跑 0.3.10 的人把 IP 贴出来？我们好 -addnode= 连上，确保至少连到一个 0.3.10 节点。

我怀疑如果你连接的节点全是 0.3.9 或更低，接收区块会很困难。我们需要足够多的人升级，保证你连接到的节点里至少有一个是 0.3.10。等我们占到全网的 1/8 以上，问题就会开始消失。

做端口转发会有帮助，这样你能拿到更多连接。

未升级的节点大部分时间持有正确的链，但它们仍在试图把那笔溢出交易打包进每个区块，所以它们在不停地尝试分叉、生成无效区块。老版本节点重启后，交易池会被清空，所以在那笔交易再次广播之前，它可能有一段时间能生成有效区块。0.3.9 及更低版本的节点仍然必须升级。

SVN 现在有了我们需要的代码，可以自动重组区块链，不用再手动删 blk*.dat 文件。我知道昨天自己没时间又快又稳地把这个代码写出来，所以先走了快速的手动方案。

看来我们在 74689 附近反超了坏链。0.3.9 及更低版本的节点过去几个小时里返回的都已经是当前区块号了。

也就是说，升级前不再需要删 blk*.dat 了。直接升级就行，它会自动重组掉坏区块链。

感谢大家的快速响应！

Windows 上：findstr /c:"version message" debug.log

坏链最近到 74678 号区块了。等不及要反超它。

从 http://nullvoid.org/bitcoin/statistix.php 的统计看，最近 3 小时每小时 5 个区块。大约一天前刚做过难度调整，应该回到每小时 6 个区块的水平。

随着更多节点升级，坏链同样被拖慢了。

74638 之后我们已经生成了 14 个区块。0.3.10 的构建大约 2 到 3 小时前上传。在我连接的节点里，超过一半已经是 0.3.10。我可以说我们的算力大概率已经超过坏链了。

其他参与者原话trebronicsAugust 16, 2010原帖 ↗

大多数跑客户端的人并不会看这个帖子。那么……问几个傻问题：

1) 这对还带着坏区块链的 3.8.1（灾难前）客户端会持续造成什么影响？

2) 对升级到 3.8.10 但没删掉区块链文件的客户端又有什么影响？

1) 一旦超过 50% 的节点算力完成升级、好链反超坏链，0.3.10 节点就会让任何坏交易都很难获得确认。

2) 如果你没删 blk*.dat 文件，你就没在为那 50% 出力，而且你会一直显示坏交易，直到好链反超坏链。

其他参与者原话kosovitoAugust 16, 2010原帖 ↗

我做完了全部步骤，现在我的客户端是 0.3.10，停在了区块 74638。一切正常吗？

如果你仍然显示 74638 个区块，说明你没有连上任何 0.3.10 节点。

今天的话，试试加上这些参数：

-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=68.68.99.14

见

http://bitcointalk.org/index.php?topic=828

其他参与者原话Ground LoopAugust 16, 2010原帖 ↗

问一个后续影响的问题：我在坏区块出现之后、基于坏区块链提交过一笔交易。

那笔交易现在是什么状态？

就我能看到的，我（升级后的）发送方客户端钱包仍显示这笔款项已扣除。

它会被并入修复后的链吗？收款方能把它花出去吗？

对，它会被并入修复后的链。交易不会消失，两边都还能看到它，只是确认数会跳回 0，然后重新开始累计。

只有当你在坏链上、区块 74638 之后生成过区块，那 50 BTC 才会消失。坏链上的任何区块那时都还没成熟。

*** 警告 *** 我们正在调查一个问题。在问题解决之前，请勿信任 15.08.2010 17:05 UTC（区块 74638）之后发生的任何交易。

*** 警告 *** 我们正在调查一个问题。在问题解决之前，请勿信任发生于 15.08.2010 17:05 UTC（区块 74638）之后的任何交易。

自动附加的广告与页脚邮件列表系统来源 ↗

---

这封 SF.net 邮件的赞助方为

自动附加的广告与页脚邮件列表系统来源 ↗

打造一款让他们离不开的应用
参加 BlackBerry 开发者挑战赛
http://p.sf.net/sfu/RIM-dev2dev

---

bitcoin-list 邮件列表
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list

0.3.10 版修复了区块 74638 的溢出 bug。http://bitcointalk.org/index.php?topic=823

Linux 版包含 tcatm 的 4 路 SSE2 SHA-256，能让 i5、i7（开超线程）和 AMD CPU 挖矿更快。试试 "-4way" 开关启用，看看对你是不是更快。

从 sourceforge 下载：

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.10/

SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe

SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip

SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz

SHA1 b812ccff4881778b9090f7c0b0255bcba7b078ac bitcoin-0.3.10-macosx.zip

现在不再需要删 blk*.dat 了。好链已经反超坏链，直接升级就行，它会自动重组掉坏区块链。

从 67000 开始再好不过。

是，目前你会停在 74638。随着更多节点升级和挖矿，它应该会开始缓慢爬升。

Linux 构建链接在下面。

Linux 版包含 tcatm 的 4 路 SSE2 SHA-256，能让 i5 和 AMD CPU 挖矿更快。用 "-4way" 开关启用，看看对你是不是更快。

下载链接：

http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe

http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip

http://www.bitcoin.org/download/bitcoin-0.3.10-linux.tar.gz

SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe

SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip

SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz

其他参与者原话knightmbAugust 15, 2010原帖 ↗

[编辑] 刚看到你的帖子，那我就做一个只包含 74000 之前区块的版本，至少能帮你们这些技术人员省几分钟下载新链的时间。

那个旧的别动！旧一点更好。它到多少号了？60000 到 74000 之间都行。你已经挂了一段时间的那个经过了验证，是最好的选择。

先别更新提供下载的区块链文件。使用别人提供的区块链文件时，不要选已经更新到最新区块的版本。稍微旧一点的更好，这样它才能下载并校验最近的区块。

tcatm 的 4 路 SSE2 SHA-256 在 sha256.cpp 里，几个修订之前就上传了。

我刚上传了 rev 134，修改了 makefile.unix，使 Linux 上的构建可以包含这部分代码。现在在 Linux 上构建 rev 134 就会得到 -4way 开关。

如果你因此构建出问题，就编辑 makefile.unix 然后：

• 去掉 -DFOURWAYSSE2
• 从下面这些行末尾去掉 obj/sha256.o：

bitcoin: $(OBJS) obj/ui.o obj/uibase.o obj/sha256.o

bitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha256.o

我构建的 0.3.10 Linux 版会带 -4way 选项。

Windows 补丁下载在这里：

http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe

http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip

SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe

SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip

步骤：

1) 关闭客户端。

2) 下载 knightmb 的 blk 文件，替换你的 blk0001.dat 和 blkindex.dat 文件。

http://knightmb.dyndns.org/files/bitcoin/blocks/

http://rapidshare.com/files/413168038/BitcoinBlocks.torrent

3) 升级到 0.3.10。

4) 启动时应该少于 74000 个区块，让它重新下载剩下的。

或者，如果你不想折腾下载 blk 文件，直接这样做：

1) 关闭客户端。

2) 删除（或移走）blk*.dat

3) 升级到 0.3.10。

4) 它会重新下载全部区块，大概要一个小时。

补丁已上传到 SVN rev 132！

目前推荐的步骤：

1) 关闭客户端。

2) 下载 knightmb 的 blk 文件。（替换你的 blk0001.dat 和 blkindex.dat 文件）

3) 升级。

4) 启动时应该少于 74000 个区块。让它把剩下的重新下载。

如果你不想用 knightmb 的文件，也可以直接删掉 blk*.dat，但如果所有人同时下载整个区块索引，网络压力会很大。

我马上构建发布版。

有了更新之后，你可以下载 knightmb 的区块链。要挑一个足够旧的，结尾早于区块 74000，这样最近设置的安全检查点才能校验它。有人能找一下链接吗？

如果大家停止挖矿会很有帮助。我们很可能需要重新生成一条分支，绕过当前链，你们挖出的区块越少，这一步完成得越快。

第一个补丁会进 SVN rev 132。还没上传。我要先把其他一些杂项改动提交掉，然后再上传这个补丁。

这是初步的改动。看起来对吗？我还有更多要改的，这不全。稍后提交到 SVN。

bool CheckTransaction() const
    {
        // Basic checks that don't depend on any context
        if (vin.empty() || vout.empty())
            return error("CTransaction::CheckTransaction() : vin or vout empty");

        // Check for negative and overflow values
        int64 nTotal = 0;
        foreach(const CTxOut& txout, vout)
        {
            if (txout.nValue < 0)
                return error("CTransaction::CheckTransaction() : txout.nValue negative");
            if (txout.nValue > 21000000 * COIN)
                return error("CTransaction::CheckTransaction() : txout.nValue too high");
            nTotal += txout.nValue;
            if (nTotal > 21000000 * COIN)
                return error("CTransaction::CheckTransaction() : txout total too high");
        }

        if (IsCoinBase())
        {
            if (vin[0].scriptSig.size() < 2 || vin[0].scriptSig.size() > 100)
                return error("CTransaction::CheckTransaction() : coinbase script size");
        }
        else
        {
            foreach(const CTxIn& txin, vin)
                if (txin.prevout.IsNull())
                    return error("CTransaction::CheckTransaction() : prevout is null");
        }

        return true;
    }

别把主题设为置顶，没人会往上看。到时自然会有足够的回帖把它顶起来。

请尽快升级到 0.3.6，以获取一项重要错误修复。

下载链接见 bitcoin.org 首页。

请尽快升级到 0.3.6，以获得一项重要的错误修复。

下载链接见 bitcoin.org 首页。

自动附加的广告与页脚邮件列表系统来源 ↗

---

Palm PDK Hot Apps 计划面向使用 Plug-In Development Kit 把 C/C++ 应用移植到 Palm 的开发者，提供分享 100 万美元现金或 HP 产品的机会。详情请访问： http://p.sf.net/sfu/dev2dev-palm

---

bitcoin-list 邮件列表
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list

其实，直接给我发 PM 就很管用。负责修的就是我。如果你发现安全漏洞，我非常希望你在它公开之前私下告诉我，好先把它修掉。

SVN 已更新到 0.3.6 版本。

正在把 0.3.6 的 Windows 构建传到 Sourceforge，接下来重编 linux。

还没来得及更新 SVN。等 0.3.6，我正在编。这期间你可以先把节点关掉。

请尽快升级到 0.3.6！我们修复了一个实现 bug：此前伪造交易有可能被显示为已接受。在你升级到 0.3.6 版本之前，不要接受 Bitcoin 交易作为付款！

如果无法立刻升级到 0.3.6，最好先关掉你的 Bitcoin 节点，直到升级完成。

0.3.6 还有更快的哈希：

• midstate 缓存优化，归功 tcatm
• Crypto++ ASM SHA-256，归功 BlackEye

总生成速度达到原来的 2.4 倍。

下载：

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.6/

Windows 和 Linux 用户：如果你装的是 0.3.5，仍然需要升级到 0.3.6。

DoS 方面还有很多工作要做，但我先把目前手上的东西快速构建一版以防万一，然后再去琢磨更复杂的想法。这一版的版本号是 0.3.19。

• 增加了一些 DoS 防控

正如 Gavin 和我之前明确说过的，这个软件对 DoS 攻击毫无抵抗力。这是其中一项改进，但仍有数不清的攻击途径。

我暂时保留了 -limitfreerelay 开关，有需要时可以使用。

• 移除「安全模式」警报

「安全模式」警报是 0.3.9 溢出漏洞之后的一项临时措施。我们尽管可以说用户运行时加 "-disablesafemode" 就行，但从外界观感来看，最好还是干脆去掉它。它从来就不是一项长期特性。看到一条更长（累计工作量更大）的无效区块链时，安全模式仍会触发。

构建：

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/

其他参与者原话neliskyAugust 25, 2010原帖 ↗

那么管理员用 bitcoind 会收到什么形式的警告？debug.log 里有什么可以 grep 的东西吗？还是 rpc 调用会抛出某种特定错误？有没有办法在本地强制触发它，好对服务做单元测试？

getinfo 有一个新字段，显示任何警报消息或其他本会显示在状态栏上的错误。

rpc 方法返回一个 json-rpc 错误，错误描述为 "Safe mode: " 加上警报指定的附加文本。

我为你加了 "-testsafemode" 开关。SVN rev 145。

这些东西很新，仍可能变动。

其他参与者原话mizerydeariaAugust 25, 2010原帖 ↗

我刚发现 http://www.bitcoin.org/wiki/doku.php?id=man_page，上面没有 -disablesafemode 的条目。也许该加上！另外其他几个比如 -4way 也应该加上。

很多开关是故意不写文档的，比如功能还在开发中、名字还没定，或者只是不打算随版本发布的测试代码。

-4way 最终应该被自动检测取代。

其他参与者原话jimbobwayAugust 25, 2010原帖 ↗

给中本聪几个反问：

你能扛得住水刑吗？

你能扛得住电刑吗？

一切形式的酷刑？

最后，你该不会是 Jack Bauer 吧？认真的。

至于警报系统，谁在乎呢？那把私钥最多也就是暂时禁用六个 json-rpc 命令，直到站长们加上 -disablesafemode 开关或者升级。所有节点继续运行、继续挖矿，网络照常。如果联系不上我，任何脚本小子都能想明白怎么加上两个字符、出一个禁用警报系统的新版本。那只是一时的不便。

其他参与者原话BioMikeAugust 23, 2010原帖 ↗

那么，理论上这是一种初步的控制机制：<某个政府> 可以逮捕中本聪，要求

他交出私钥（或者从他的电脑里拿到），从而关停整个网络？

这正是让我觉得反对者不了解状况的地方。它「关停不了整个网络」。

我把开关名字改成了 -disablesafemode。

它无法远程执行任意操作。也许你们有些人是在回应其他发帖者——是他们建议警报系统应该做更多事？

如果有警报，以下 json-rpc 方法会返回错误：

sendtoaddress

getbalance

getreceivedbyaddress

getreceivedbylabel

listreceivedbyaddress

listreceivedbylabel

其余 14 个方法照常工作。

我认为更安全的选项应该默认启用。如果你想让你的服务器继续交易、无视「它收到的钱可能像溢出 bug 那笔钱」的警报，你可以用开关，赔了钱也别怪别人。

让警报开着的最坏情况，是你的网站停止交易，直到你升级或加上 -disablesafemode 开关。

如果你的节点继续运行就会面临风险，那么因临时停机而吃一惊，总比发现小偷把全部库存偷光了要好。

将来等我们很久没发现新 bug、也经过彻底的安全审查、没有发现任何问题时，就可以放宽这些限制。我不是说这就是永远的常态。它还是 beta 软件。

这已经在 SVN rev 142 里，作为 0.3.11 版本。

如果你偏执到为这事歇斯底里，那你肯定也偏执到：一旦状态栏显示警告消息，你就会去查看网站和论坛。

我认为，如果再出现类似溢出 bug 的问题，让自动化网站暂停交易，直到管理员查清状况并决定对策，这一点很重要。如果你判定是虚惊一场、想赌一把，可以用 "-disablesafemode" 开关。

我一直在写警报系统。警报通过网络广播，适用于一定范围内的版本。警报消息用私钥签名，私钥只有我有。

节点可以对警报做两件事：

• 在状态栏显示警告消息。
• 让 json-rpc 接口的资金处理方法返回错误。

在诸如溢出 bug 或分叉这类用户可能无法信任所收支付的情形下，警报应该能让旧版本在升级前基本安全。手动操作客户端的用户在查看收款时会注意到状态栏警告，而 json-rpc 安全模式会阻止自动化网站在升级前继续交易。

警报期间返回错误的 json-rpc 方法是：

sendtoaddress

getbalance

getreceivedbyaddress

getreceivedbylabel

listreceivedbyaddress

listreceivedbylabel

0.3.8 版本加入了一个重要的安全改进。所有人都应升级以获得这项变更。

新的安全特性会在状态栏显示警告信息，并在检测到可能需要升级的问题时锁定 RPC。

如果它看到一条更长的链但无法处理，它就知道出问题了。它会显示 "WARNING: Displayed transactions may not be correct! You may need to upgrade." 并让多数 RPC 命令返回错误。它仍照常挖矿，这是网络稳定所必需的。

之前的版本也有重要安全更新，如果你最近没升级过，现在升级就极其重要了！

另外，别忘了，我们最近把挖矿速度提高到了原来的 2.4 倍——归功于 tcatm 的 mid-state 缓存优化，以及 BlackEye 帮忙让 ASM SHA-256 跑了起来。

下载：

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/