安全、攻击与钱包

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而

公钥 654321 也生成哈希 ABCD

我手里仍然没有私钥。

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

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

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

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

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

引用 · 发言者未注明

这里有一篇论文声称能在 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 只是充当一轮密钥加强而已。

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

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

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

你可以移动或备份钱包文件，但它只能有一条"血脉"，同一时间只能在一处使用。一旦把钱转出去，就不能再使用任何先前的副本。

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

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

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

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

想试用的话，把你的邮箱私信或邮件给我，我以附件方式发送，并注明操作系统（win、linux 32 位、linux 64 位）。

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

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

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

database/log.* 文件只包含临时数据库数据。如果你上次是正常退出 bitcoin 的——不是被强杀或崩溃——那么 database/log.* 文件通常可以安全删除。它们只在这种情况有用：当数据库正处于一笔交易中途时计算机崩溃、或程序被杀或崩溃，它可以无数据丢失地恢复。

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

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

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

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

我们应该在钱包里预生成一批备用地址，需要新地址时取用。它们不大，多存一些也无妨。这样还能更一般地覆盖另一种情况：某人做了备份，之后请求了一个新地址并用它收了一大笔款。也许应该分设几个队列，免得一种地址需求把别的需求饿死。

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

区块加载代码里有某种重新扫描机制，本来是用来修复有人复制了 wallet.dat 的情形。我需要确认这个重新扫描能处理「在已收到的区块里重新发现收到的付款，但因为钱包被恢复而曾经被遗忘」的情况。

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

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

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

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

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

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

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

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

等等，我又糊涂了。我一直以为那个「惊喜」的要害是：Bitcoin 被编程为在*每一笔*交易时「清空你的钱包」。

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

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

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

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

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

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

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

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

该叫什么名字？也许：

backupwallet

rpc backupwallet 已进 SVN rev 147。

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

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

恢复那一侧我尚未处理。如果你真的恢复了一个旧的 wallet.dat，我想你恐怕得删掉 blk*.dat，让重新下载时找回自己的交易。

我只做过中等程度的测试。在它经过更多测试之前，网站服务器恐怕不该用它。

引用 · 发言者未注明

它会自动同步吗？

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

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

新的演示版 CPU 矿工已发布：

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

这个钱包之前是配合什么用的？早期的账户补丁还是 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

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

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

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

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

一个更普遍的伞形部分解法是实现那个想法：检测收到的区块频率出现不太可能的骤降。这样攻击者仍需要掌握网络算力的相当部分，才能从 DoS 攻击中获益。

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

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

说了。

+1

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

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

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

就怕你找得到一个把它打开的人。它默认是关闭的。

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

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

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

请尽快升级到 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。

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

SVN 已更新到 0.3.6 版本。

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

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

这是初步的改动。看起来对吗？我还有更多要改的，这不全。稍后提交到 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;
    }

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

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

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

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

补丁已上传到 SVN rev 132！

目前推荐的步骤：

1) 关闭客户端。

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

3) 升级。

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

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

我马上构建发布版。

先别更新区块链下载。用别人的区块链下载时，不要拿最新到头的。稍微旧一点的更好，这样它才能下载并校验最近的区块。

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) 它会重新下载全部区块，大概要一个小时。

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

[编辑] 刚看到你的帖子，那我就做一个截止到 74000 以下的，至少能帮你们这些技术人员省几分钟下载新链的时间。

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

从 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

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 了。好链已经反超坏链，直接升级就行，它会自动重组掉坏区块链。

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

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

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

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

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

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

就我能看到的，我（升级后的）发送方客户端钱包显示扣款金额还在。

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

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

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

其他参与者原话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

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

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

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

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

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

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

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

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

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

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

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

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

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

感谢大家的快速响应！

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

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

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

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

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

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

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

Bitcoin 客户端真的不该允许挖矿，直到你拥有到最后一个区块检查点为止的全部区块。

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

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/

我一直在写警报系统。警报通过网络广播，作用于一个版本号区间。警报消息用私钥签名，私钥只有我有。

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

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

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

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

sendtoaddress

getbalance

getreceivedbyaddress

getreceivedbylabel

listreceivedbyaddress

listreceivedbylabel

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

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

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

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

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

sendtoaddress

getbalance

getreceivedbyaddress

getreceivedbylabel

listreceivedbyaddress

listreceivedbylabel

其余 14 个方法照常工作。

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

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

在你的节点本该处于风险中时被临时停机吓一跳，好过被小偷偷光全部库存时吓一跳。

将来等我们很久没发现新 bug、也做过彻底的安全审查而一无所获时，可以把它放宽。我不是说这就是永远的常态。它还是 beta 软件。

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

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

给中本聪几个反问：

你能扛得住水刑吗？

你能扛得住电刑吗？

一切形式的酷刑？

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

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

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

那么，理论上这是一个第一代控制系统：<某个政府> 可以逮捕中本聪，要求

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

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

其他参与者原话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 最终应该被自动检测取代。

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

• 增加了一些 DoS 防控

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

-limitfreerelay 部分暂时保留为开关，需要的话就在那里。

• 移除「安全模式」警报

「安全模式」警报是 0.3.9 溢出漏洞之后的一项临时措施。我们尽管可以说用户运行时加 "-disablesafemode" 就行，但为了体面起见，不如干脆不要有它。它从来就不是一项长期特性。看到一条更长（总工作证明更多）的无效区块链时，安全模式仍会触发。

构建：

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