网络与共识

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

Satoshi，我算了一下，我这台新式 core 2 duo 大约要连续不停工作 20 小时才能生成 ฿50.00！老电脑就更没指望了。人们喜欢尽快"拥有"点什么的感受，有没有办法让生成更可分割？比如，不是每 20 小时生成 ฿50，而是每 2 小时生成 ฿5？

我考虑过，但没有切实可行的办法做更小的增量。区块生成频率，是在"尽快确认交易"与"网络延迟"之间的平衡。

算法的目标是平均每小时 6 个区块。如果改成每个区块奖励 5 个比特币、每小时生成 60 个区块，区块数量会多出 10 倍，初始区块下载也要花 10 倍时间。反正也行不通：那样区块平均间隔仅剩 1 分钟，网络变大后就太接近广播延迟了。

对我来说，第二个版本将是巨大的开发和维护麻烦。在升级网络的同时保持向后兼容已经够难了，再来一个版本把事情锁死就更难。如果第二个版本搞砸了，用户体验会让两者都蒙羞，尽管它至少能让用户更明白紧跟官方版本的重要性。如果有人准备分叉出第二个版本，我不得不大张旗鼓地声明使用少数派版本的种种风险。这个设计的规则是：一旦有分歧，多数派版本获胜——这对少数派版本可能相当难看，我不想展开，而且只要只有一个版本，我就不必面对它。

我知道，大多数开发者都不喜欢自己的软件被分叉，但在这个案例里我有实实在在的技术理由。

其他参与者原话gavinandresenJune 17, 2010原帖 ↗

我欣赏交易内置脚本的灵活性，但我那邪恶的小脑瓜立刻开始想滥用它的办法。我可以在 TxOut 脚本里编码各种有趣的信息，如果未被 hack 的客户端验证后忽略这些交易，它就成了一个有用的隐蔽广播通信信道。

在它流行起来、有人觉得"把最新的 Lady Gaga 视频用上百万笔交易灌进支付网络发给所有朋友"很好玩之前，这确实是个很酷的特性……

这正是手续费存在的原因之一。必要的话我们还有别的办法。

其他参与者原话laszloJune 17, 2010原帖 ↗

Satoshi，这个设计你做了多久了？它看起来深思熟虑，不是那种没经过大量头脑风暴和讨论、坐下来就写代码的东西。每个人都在用显而易见的问题找它的漏洞，但它一直站得住脚。

从 2007 年开始。某一刻我确信存在一种完全不需要信任的做法，从此欲罢不能地一直想下去。工作量里设计远多于编码。

幸运的是，到目前为止被提出的问题，都是我以前考虑过并做了规划的。

很难想象互联网会被分割得密不透风。那得是一个国家刻意地、彻底地把自己与世界其他地方隔绝开来。

任何能同时接入两侧的节点都会自动把区块链流过去，比如有人用拨号调制解调器或卫星电话绕过封锁。只需要一个节点就能做到。任何想继续做生意的人都有动力这么做。

如果网络被分割后又重新合并，较短分叉里那些不在较长分叉中的交易会被重新放回交易池，有资格进入未来的区块。它们的确认数将从头开始。

如果有人利用网络分裂进行双重支出，让同一笔钱在两边分别被花掉，那么较短分叉上的那笔交易会失效，回到“0 次确认／未确认”状态，并一直保持在那里。

想利用分割来双重支出并不容易。如果一侧无法与另一侧通信，你要怎么把花费分别放到两侧？如果有办法，那很可能别人也在用同样的办法把区块链流过去。

你通常能知道自己是不是在较小的一侧。比如，如果你的国家把自己与世界隔绝，世界其他地方就是较大的一侧。如果你在较小的一侧，就应假设什么都没有被确认。

下载链接已在 bitcoin.org 上。所有人都应升级到这个版本。

• 新增一个简单的安全防护，把区块链锁定到当前时点。
• 精简了 addr 消息以节省带宽，现在有充足的节点可连。
• 西班牙语翻译，作者 milkiway。
• 法语翻译，作者 aidos。

有了这个安全防护，即使有人真的掌握了全网 50% 以上的 CPU 算力，也无法试图回退、重做昨天之前的区块链。（前提是你装了这个更新）

从现在起我大概会在每个版本里放一个检查点。一旦软件已经确认了被广泛接受的区块链是什么样，就没有必要留下「几个月后翻案」这种人们不需要的非零可能性。

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

不过，很重要的一点是别把锁一直上到最新的区块。否则，攻击者可以在你恰好上锁之前生成假区块（或几个），那样他的攻击会比没有区块锁定时容易得多。

我往前锁了约 200 个区块。区块链当时是一条干净的直线，没有分叉，被锁的区块只有一个人尽都知的版本。

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

另外，我理解区块锁定意味着区块也会随客户端预打包发布。是这样吗？

抱歉，还没有，但我确实想让初始区块下载更快。

你看错代码了。适用的是这段：

bool CBlock::CheckBlock() const
{
...
    // Check timestamp
    if (nTime > GetAdjustedTime() + 2 * 60 * 60)
        return error("CheckBlock() : block timestamp too far in the future");
...

bool CBlock::AcceptBlock()
{
   ...
    // Check timestamp against prev
    if (nTime <= pindexPrev->GetMedianTimePast())
        return error("AcceptBlock() : block's timestamp is too early");

时间戳最多允许到未来 2 小时。它可以早于前一个区块，但必须大于最近 11 个区块的中位数。这样做的原因是：如果前一个区块的时间戳超前太多，就像刚才发生的那样，时间可以在下一个区块被纠正回来。

creighto：我同意这个想法。几个小时之后，客户端应该有可能察觉到区块流量衰减得超出偶然范畴。它能知道自己是不是再也听不到世界的嗡嗡声了。

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

有意思的信息。也就是说，除了一些双重支出问题，只要区块链分离不超过 100 个区块左右（或 16 小时以上），

实际上，分割很可能极不对称。把世界从正中间劈开很难。更可能的情形是一个国家对世界其他地方，比方说 1:10 的分割。那样的话，少数派分叉要花 10 倍的时间生成 100 个区块，约 7 天。而且客户端会非常容易地察觉自己听到的区块太少了、一定出了问题。

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

分割延迟有没有硬编码的上限？意思是，如果我有一个从公共网络分离出去的小网络，在里面花了些币，几天后回来同步到公共网络（除了碰巧发生的币生成），交易应该都没问题？

没有时间限制。只要你没有花少数派分叉里生成的币、没有花你收到的别人的双重支出，你的交易随时可以在之后进入另一条链。

一旦你离开「每个节点的影响力与其 CPU 算力成正比」的体系，那你又用什么来判定谁是（大致上的）一个人？

没错，可能还有人在用拨号调制解调器或卫星锅上网。更罕见的是同时拥有这两样和那条断了的有线网络的人，但只要这一群体大到值得在意，一百万人里总会有一个多线接入的极客。

ISP 断网只是你的局部地区。如果你和周边其他地区的通信还在，那大概只有世界的 1/1000 或更少。这一小片里的区块生成会变成每几个小时一个区块。

我支持那个监控方案：监测收到的区块频率是否衰减得过低。它能覆盖很大范围的可能性。

那是个麻烦的办法。

我们需要触发一次重组，把无效链断开。

这段代码几乎不会被测试到，而且相当繁复精巧，所以简单安全的做法最好。

我的想法是这样。（还没测试过）它检查主链上的所有区块。发现坏的，就把那条链的 bnChainWork 全部置 0，让它再也赢不了最佳链，并把最佳链工作量降到分叉点级别，这样分叉点之后的任何新区块都会触发重组。（不真正做一次重组，它改不了 pindexBest）

这还不完善。它仍需要收到一个有效区块来触发重组。

也许可以在检查之后主动发起 AddToBlockIndex 或 Reorganize，但那需要更细致的推敲。我大概应该把 AddToBlockIndex 里设置新区块最佳的部分拆出来。我最后很可能用那个做法，而非下面的代码。

bool CTxDB::LoadBlockIndex()
{
    ...

    // Verify blocks in the main chain
    vector<CBlockIndex*> vChain;
    for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)
    {
        vChain.push_back(pindex);
        CBlock block;
        if (!block.ReadFromDisk(pindex))
            return error("LoadBlockIndex() : block.ReadFromDisk failed");
        if (!block.CheckBlock())
        {
            bnBestChainWork = pindex->pprev->bnChainWork;
            foreach(CBlockIndex* pindex2, vChain)
                pindex2->bnChainWork = 0;
        }
    }

    return true;
}

中本聪原话中本聪August 16, 2010原帖 ↗

也许可以在检查之后主动发起 AddToBlockIndex 或 Reorganize，但那需要更细致的推敲。我大概应该把 AddToBlockIndex 里设置新区块最佳的部分拆出来。我最后很可能用那个做法，而非下面的代码。

这就是我最后在 SVN rev 139 里做的。

我没有删坏链，而是给 ConnectBlock 加了一个额外的 CheckBlock，这样坏区块一旦被踢出去就回不到最佳链了。

软件没有办法自动判断一条链比另一条好，唯一的判据就是工作证明最大。按这个设计，不管要回退多远，它都必须切到更长的链上。

唯一的例外是我加的手动检查点。要不是有它们，它可以把重组一路做到第一个区块。

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

链的强度是怎么计算的？

总工作证明。

只要连接数不少于 1，挖矿速度就一样。

更多的连接，只是增加冗余而已。如果你只有一条连接，而那个节点又慢又忙、或者只与你一人相连，那该如何是好？多几条连接，能让你更确信自己与网络保持着良好的连通。实践中，这从没成为过问题，网络的连接非常充分。有 2、3 条连接，你就没有问题。

有命令行选项：

bitcoin -addnode=1.2.3.4 告诉 bitcoin 要连接的一个节点

bitcoin -connect=1.2.3.4 只连接指定节点

这些选项可以叠加使用，比如

bitcoin -connect=(先试这个) -connect=(下一个) ...

-connect 可以指定不可路由的 IP，比如 192.168.x.x，所以如果你有一个服务器集群，想让一台连接外部世界、其余都连到那一台，也能做到。

特别是，如果你打算一直通过 TOR 连接，就需要 -addnode，因为 IRC 服务器封禁所有 TOR 出口节点。通过 TOR 连接可以用：

bitcoin -proxy=127.0.0.1:9050 -addnode=212.159.72.216

目前还没有实现这个功能的端口设置。这是尚未实现的功能。你只能把 NAT 的端口转发设到其中一台计算机。（我之前说过 NAT 端口转换什么的，但那行不通，其他节点不知道要连到那个端口）

如果愿意，作为一个小优化，你可以让其余计算机这样运行：

bitcoin -connect=<第一台计算机的 IP>

这样它们的全部网络通信都经由第一台计算机，而不必各自单独连到网上取同样的信息。这能节省带宽，不过一开始带宽占用就不大，故除非你有海量计算机，否则影响不大。

为了在第一台宕机时保有冗余，可以让两台向外连接、其余连接到这两台。头两台正常运行，其余这样运行：

bitcoin -connect= -connect=

节点一旦有 15 条连接就不再主动发起连接。如果你能接受入站连接，那么从连向你的节点那里可以收到远超此数的连接，否则你就封顶在 15。

我不知道有什么理由要 15 条连接。也许应该是 10。

由于只能向外连接的节点现在大部分时间都在 15 条上下，你应该会稳定到一个均衡。45 意味着每 1 个接受入站的节点对应 3 个只出不进的节点。

连接数不再是衡量网络规模的好指标了。应该有人定期通过 IRC 连到 chat.freenode.net 的 bitcoin 频道数一数用户数。那给出的是网络节点总数（TOR 节点除外）。

区块生成又一次跑在了节奏前面。大约 5 天后的下次调整，难度又要上一个台阶。

感谢 soultcer 与 Freenode 的工作人员沟通。很高兴知道当前规模没问题，而且他们现在知道我们是谁了。他们对 TOR 这样的项目都很支持，所以希望他们对我们大概也会友好。我们不想赖着不走。等我们规模太大时，同样地，我们也大到不再需要 IRC，到时我们会离开。

我们需要 IRC 只是因为没有人有静态 IP。早期有一些稳定的支持者，但他们的 IP 都是地址池分配的，每隔几天就变。IRC 本来就只是临时方案。Bitcoin 内建的 addr 系统才是主要方案。

Bitcoin 可以从任何 bitcoin 节点获取 IP 列表。在这个意义上，每个节点都是一台目录服务器。

当静态 IP 节点多到"当前版本寿终正寝之前至少还有一个仍在运行"有较大把握时，我们就可以预编一份种子列表。

你觉得种子列表该怎么编？从已经稳定了一段时间的当前连接 IP 里挑选，可以吗？

顺便说一句，如果我们想靠部署独立的目录服务器软件来补充，我建议用 IRC 行吗？IRC 是个很好的目录服务器（我听说它还有别的用途），有成熟的 IRC 服务器实现，谁都能运行。Bitcoin 的 IRC 客户端实现也已经过彻底测试。

目前，它总是假定入站端口是 8333，所以就算你从别的端口号转发的，它也会让其他 bitcoin 节点去连 router:8333。

我不急着修这个，因为我想不出多个入站连接端口能带来什么好处。你提供了一个入站端口，就已经为网络尽了一份力。同一个人开两个入站端口，对冗余毫无帮助。

如果你有很多台计算机，更合理的做法是在大部分机器上用 -connect 开关在本地互联。

Bitcoin 有自己的分布式地址目录，用的是 "addr" 消息。是时候把当前长期运行的静态节点编成种子列表写进代码了。我可以加一段代码，让新节点不优先保持与种子节点的连接——连上、取列表、就走，这样不会给它们添负担。

你们怎么看，我该继续把种子加进去吗？

它仍会先试 IRC。IRC 的优点是列出当前在线的节点——它们必须保持连接才能留在列表上——缺点是单点故障。"addr" 系统没有单点故障，但只能告诉你最近见过哪些节点，所以连接会慢一点，因为你试的一些节点已经下线。两者结合让我们两全其美、总体更稳健。

有人愿意志愿运行一台 IRC 服务器，以防 freenode 哪天厌倦了我们吗？

3) 按比特币地址发送的话，没什么。

5) 它是去中心化的。第一次连上网络之后，你就不再需要 IRC 了。

SVN 版本现在先用 IRC，失败则回退到一份硬编码的种子节点列表。现在种子节点已经够多，到下个发布时其中许多应该还在运行。它只短暂连上一个种子节点取回地址列表就断开，所以你的连接数会有一阵掉回零。那时请耐心点。只有第一次连接才慢。

这意味着 TOR 用户不再需要 -addnode，它会自动连上。

我们需要更多关于出了什么事的细节，MadHatter。

0.2 和 0.3 都有不靠 IRC 的备用连接方式，只是连得慢一些。

0.2 只要曾经连接过，不用 IRC 也能找到其他节点，但全新安装不靠 IRC 就无法第一次发现网络。

0.3 不靠 IRC 也能引导种子。必要时它可以完全不依赖 IRC 运转，但有 IRC 作冗余更好。

其他参与者原话laszloJune 14, 2010原帖 ↗

我运行着一台 IRC 服务器，你们可以用，它相当稳定，但没挂在冗余线路上什么的。现在只有两台服务器，不过我们从不折腾它，它就那么跑着。

我的机器是一台专用 irc 服务器：

2:28PM up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08

你可以用 irc.lfnet.org 连接。

这看起来是个好主意。

大家怎么看，0.3 版要做这个切换吗？

我们试试改用 Laszlo 的 irc.lfnet.org 而不是 freenode。这是 RC2，里面唯一的改动就是这个：

（下载链接见下方）

Freenode 太显眼了，正处在所有那些用户和版主聚集的正中央。Laszlo 的方案对我们合适得多。

我发布了改用 irc.lfnet.org 而非 freenode 的 0.3.0.RC2，如果你想开始切换的话：

http://bitcointalk.org/index.php?topic=199.msg1787#msg1787

感谢就此的反馈。

我们可以做的一件事是把对外连接数从 15 降到 10，甚至 5。当初选 15 很随意。它只需要足够支撑冗余和消息的快速指数传播。10 仍然绰绰有余。5 应该也行。10 是个好看的整数，用户能看出这是有意为之。

实现 UPnP 会有帮助，这样接受入站的节点会更多。你的连接数 = 接受入站节点数与只出不进节点数之比 × 15。我们需要鼓励更多人接受入站连接。

我会实现一个功能：达到一定数量后停止接受入站连接。

你运行的是哪个版本？

有人知道 BitTorrent 这类典型 P2P 软件能到多少连接吗？

我在 RC4 里把最大对外连接数从 15 降到了 8。

15 远超冗余所需。8 仍然有充足的冗余。

随着节点升级到这个版本，接受入站连接的节点获得的连接数会减半。

如果有人想要 8 条以上连接，可以在防火墙上开放 8333 端口。

每个人都必须连到同一个 IRC 服务器和频道，才能彼此找到。

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

你或许可以把 Freenode 留作备用服务器——如果他的服务器不行，就换 Freenode 的。

如果我们突然带一大堆用户涌入 freenode，可能不太妥当。

备用方案是我们自己的种子系统。

irc.lfnet.org 相当老牌，运行时间记录很可观。我觉得它没问题。

如果想拿掉 IRC，以后随时可以，但我宁愿渐进过渡，目前先把自己的种子系统当作备用方案来测试。我真的很喜欢这两套不同系统互补冗余的特性。

好问题。如果你要让超过 8 个局域网节点连到一个网关节点，那最好把网关节点配置成可以接受入站连接。否则，网关节点已有 8 个或更多连接时，就不会再尝试增加出站连接。当它连着的外部节点来来去去时，它不会建立新的出站连接去补位。如果你能接受入站连接就没问题，那会有很多别的节点来连你。

其他参与者原话NewLibertyStandardJuly 17, 2010原帖 ↗

0.3 版本本应把没做端口转发的客户端的出站连接数从 15 降到 8，但我不觉得它真的发生了。我不确定是否这样，说错了纠正我。

在 0.3.0 里，改到 8 这个变更只进了 Windows 版，其他版本仍是 15。

请升级到 0.3.2，现在已经发布。

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

有两个版本：一个用原始代码构建，另一个改过、最多可接受 1,000 个节点（所以叫 super node）

我希望你最好不要放出 1000 节点连接版的构建。跑这个的人不用太多，我们就得再发一个专门限制入站连接数的版本。

SVN rev 125：

• 即使已有 8 条入站连接，也始终维持 8 条出站连接
• 出站连接限制为每个 a.b.?.? 段一条
• 新增 -maxconnections=# 开关

我加了（目前未写进文档的）开关 -maxconnections=#。除非你的路由器撑不住大量连接，否则不要用它；需要的话试试 -maxconnections=30。

-maxconnections 我没怎么测过，有人能帮忙测测吗？

引用 · 发言者未注明

但到时就没有 IRC 服务器可以用来引导入网了。

这无关紧要，因为你也同样连不上 sourceforge 去下载软件。

如果你之前连接过网络，就不再需要 IRC 来引导了。就算没连接过，你也可以从种子节点引导。从 0.3.0 起 IRC 就完全是多余的了。

你在连接自己。全部 21 次连接尝试都是对版本 31300（0.3.13）的节点。并非每个人都有 0.3.13。

IRC 看起来在正常工作。它应该尚有别的节点可试。

恐怕有什么我需要做的，确保它在断开后不会立刻再次尝试连接自己。不过我看不出这是怎么发生的，它应该重置 nLastTry、把自己排到队列末尾，但日志里没有体现。

你能把 addr.dat 移走试试。也许它里面有什么不对。

你在用 -addnode 吗？

也许你只是运气不好，摊上一个没有反向解析的出口节点。

IRC 服务器的响应看起来并不像是为此把你断开。它本该在那之后输出 IRC SENDING: NICK，但它并未，于是超时了。

我看到问题了。IRC 代码在等一些特定短语来判断服务器何时准备好接收你的 NICK，但它并未在找那一条特定的短语。我会修。

我不确定是否真的必须等服务器查完主机名才能发 nick。

第一次用 TOR，还得靠种子节点，花了多久才连上？

好，如果重新下载真的过不了区块 1698，那我们就进入更陌生的领域了。

是，恐怕他的杀毒软件、甚至路由器或防火墙在对某个字节序列做模式匹配并审查它。

拿到 knightmb 的 blk*.dat 试试能否让他跨过那个点，会很有启发。

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

. 也许与我连接的高延迟（平均 2000ms 以上）有关

双向各 2 秒的延迟，对你的生成成功率的影响应该小于 1%。

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

和/或高丢包率（有时高达 10%）？

大概没问题，但我不确定。协议设计为重新同步到下一条消息，消息会向你连接的所有其他节点重新请求，直到收到。如果错过一个区块，每当有新区块进来、它发现有空缺时，也会继续请求。在最初发布之前，我做过一个测试：在高负载下随机丢弃 1/4 的消息，直到能整夜运行、没有任何节点卡住。

它实际上一次下载 500 个区块，然后计数器随着区块的验证一块一块地累加。

让 bitcoin 下载并验证区块的好处是：你不必信任你下载它们的来源。如果你从某个网站下载 blk*.dat 文件，你就得信任那个网站，因为你在未亲自验证的情况下接受了数据。如果是从你自己的另一台电脑上拷贝 blk*.dat，那没问题。

你的初始区块下载要花多久？

这错误我头一回见。

你有多少个区块？（看状态栏）

你应该把 blk*.dat 文件（在 ~/.bitcoin）移到另一个目录，让它重新开始下载区块链。方便的话，能不能把旧的 blk*.dat 文件留一阵子，万一我需要看？

其他参与者原话singpolymaJuly 17, 2010原帖 ↗

我的币不见了，但我猜等追到最新就会回来？

对，下载完全部区块它们就会重新出现。

通过对数据库设置做一些调整，我把初始区块下载提速了约 5 倍。现在下载只要约 30 分钟。

数据库默认把每个区块同步写盘，这没有必要。我改了设置，让它把变更缓存在内存里、批量写出。区块仍然是事务性写入的，变更要么完整发生、要么完全不发生，无论哪种情况数据都处于有效状态。

我只在初始区块下载期间启用这个变更。当你离最新区块还剩 2000 个区块时，这些变更会关闭，速度回到老样子。

我编了个测试版，想提前用的话：

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

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

这些二进制也包含 Gavin Andresen 的 JSON-RPC HTTP 认证功能，以及 0.3.2 的其他重要安全改进。

过去 24 小时我跑了一个测试：在初始区块下载期间每 2-60 秒随机杀死并重启它（可怜的家伙），一切正常。

wallet.dat 的处理方式没有任何变化。这个变更只影响 blk*.dat 和不关键的 addr.dat。blk*.dat 万一坏了，随时可以删掉重新下载。

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

在最后 2000 个区块停下来有什么安全上的原因吗？能不能调整成比如剩 500 个区块时停？

没什么特别原因。下次我改成 1000。

SVN rev 139 会在加载后对区块链做一次基本检查。

有了它，我们本不需要删 blk*.dat，它会自动重组回分叉点。当时没时间把这个功能做扎实。

它可能比我们想要的慢，因为要把所有区块都加载一遍。如果太慢，可以让它只回溯到某个区块号为止。

下一个 SVN 修订里，我会让它只回溯到区块 74000 的最后一个检查点。将来如果要再修问题，随时可以让它至少回溯到问题所在之处。另外，我正在加校验区块索引的代码，也就是说会对工作证明链做校验。

不过，系统对你的 blk*.dat 文件仍然不是完全安全的。用别人 blk 文件的副本，就是在信任那个人。

花时间的不是下载，而是验证和建立索引。

从带宽上说，它比下载一个压缩包更高效。比特币只下载 blk0001.dat 里的数据，目前是 55MB，从而自己构建 blkindex.dat，为 47MB。构建 blkindex.dat 才是全部磁盘活动的来源。

在区块下载期间，它每 500 个区块才把数据库刷一次盘。你可能会看到区块计数在 ??499 和 ??999 处停顿。那就是在刷盘。

自己做验证和建索引，是确保索引数据安全的唯一办法。如果从一个不受信任的来源复制 blk0001.dat 和 blkindex.dat，就无法知道里面的全部内容是否可信。

也许 Berkeley DB 有一些可调的开关，能启用或加大缓存内存。

我在一块慢速的 7 年老硬盘上测过，带宽和 CPU 显然不是瓶颈。初始下载用了 1 小时 20 分钟。

如果远超这个时间——当然 24 小时肯定算远超——那一定是从很慢的节点下载，或者你的连接比每秒约 15KB（120kbps）慢得多，或者有别的地方出了问题。出现那种情况时，最好能知道瓶颈看起来在哪里。

约莫每 10 分钟最新区块送达时，它都有机会切换到更快的节点。最新区块广播时，它会向其他节点请求接下来的 500 个区块，并从发送最快的一个继续下载。至少，它本该这样工作。

其他参与者原话jgarzikNovember 26, 2010原帖 ↗

下载期间你需要 ACID 的哪些性质？

也许只需要更多的读缓存。它必须随机地读遍 blk0001.dat 和 blkindex.dat 来建索引。它不能假设文件比内存小，虽然目前仍是这样。缓存会相当有效，因大多数依赖都是新近的。

应该有人用不同的 Berkeley DB 设置做实验，看看有没有能让下载显著加快的配置。如果真发现了什么，我们再落实细节。

其他参与者原话jgarzik（续）原帖 ↗

添加 BDB 记录只是向日志文件追加，直到你发出一次检查点。检查点随后更新主数据库文件。

我们每 500 个区块检查点一次。

尽管说了这么多，当前的下一步是：

引用 · 发言者未注明

应该有人用不同的 Berkeley DB 设置做实验，看看有没有能让下载显著加快的配置。如果真发现了什么，我们再落实细节。

具体来说，我怀疑更多的读缓存可能帮大忙。

其他参与者原话jgarzikNovember 28, 2010原帖 ↗

IRC 上又来了一个新用户，这次是 Linux，下载速度是每 4 秒 1 个区块——估计总下载时间要 4 天左右。

那就是出了更具体的问题。那不是正常初始下载时间。没有更多细节就无法诊断。如果是下载慢造成的，10-20 分钟后下一次区块广播本该让它切换到更快的来源，它提速了吗？debug.log 里恐有线索。他们的网络连接有多快？是一直慢，还是只在某处变慢？

其他参与者原话jgarzik（续）原帖 ↗

我们把创世区块到区块 74000 的哈希硬编码（编译）进了比特币，因此没理由不能从任何地方自动下载区块数据库的压缩包，解包、验证、从而开跑。

74000 检查点不足以保护你，而且如果下载已经超过 74000 就毫无作用。-checkblocks 能做更多，但仍然容易被绕过。你终究得信任压缩包的提供者。

如果真有一个「验证」步骤，那耗时和现在正常的初始下载一样长——瓶颈是建索引，不是数据下载。

其他参与者原话jgarzikNovember 28, 2010原帖 ↗

想必某个时候会出现只下载区块头的轻量客户端，但那仍然会有成百上千个……

每个区块头 80 字节，不需要建索引。也许 1 分钟就够。

引用 · 发言者未注明

未压缩的数据，用一个并非为批量数据传输设计的协议（比特币 P2P）。

数据主要是哈希、密钥和签名，不可压缩。

初始下载的速度并不反映协议的批量数据传输速率。真正的制约因素是下载过程中的建索引。

看起来你倾向于把一切都假设成错的，比实际情况还要过头。

写区块索引是轻量工作。构建交易索引才是每个区块都要做更多随机访问的。我怀疑慢就慢在读取所有前序交易输入上。读缓存对此会有帮助。最好由 DB 来做。也许它有设置缓存内存大小的选项。

引用 · 发言者未注明

1) 比特币应该在程序启动时就打开数据库而不只是环境，并在程序关闭时关闭数据库。

它已经这么做了。见 CDB。（比如）CTxDB 对象的生命周期只是为了支持数据库事务，以及关闭时判断数据库是否还有人在用。

引用 · 发言者未注明

而且，比特币还强制做一次数据库检查点，把日志里的全部事务推进主数据库。

如果它真在那么做，会慢得多。它本该只是一分钟一次或 500 区块一次：

if (strFile == "blkindex.dat" && IsInitialBlockDownload() && nBestHeight % 500 != 0)
        nMinutes = 1;
    dbenv.txn_checkpoint(0, nMinutes, 0);

或许应该加上这个：

if (!fReadOnly)

dbenv.txn_checkpoint(0, nMinutes, 0);

引用 · 发言者未注明

2) 对于初始区块下载，事务提交应该每 N 条记录发生一次，而不是每条记录一次。我建议 N=1000。

事务提交意味着刷盘吗？这让我很意外。我以为包在事务里的数据库操作会像其他数据库操作一样被记日志。很多数据库应用几乎每一对操作都得包进事务，比如把钱从一个账户挪到另一个。（借记 a，贷记 b）我无法想象它们还被要求自己把操作攒成批。

在下面两种情况下，情况 1 刷一次盘、情况 2 刷两次吗？

情况 1：

write

write

write

write

checkpoint

情况 2：

begin transaction

write

write

commit transaction

begin transaction

write

write

commit transaction

checkpoint

扭曲我们的数据库用法不会是正确的路子。出路在于 BDB 设置和缓存。

这是个好优化。下次更新 SVN 时我会加上。

更一般地，我们还可以考虑这个：

dbenv.set_lk_max_objects(10000);

dbenv.set_errfile(fopen(strErrorFile.c_str(), "a")); /// debug

dbenv.set_flags(DB_AUTO_COMMIT, 1);

+ dbenv.set_flags(DB_TXN_NOSYNC, 1);

ret = dbenv.open(strDataDir.c_str(),

DB_CREATE |

DB_INIT_LOCK |

DB_INIT_LOG |

之后我们依赖 CDB::Close() 里的 dbenv.txn_checkpoint(0, 0, 0) 在钱包写入后刷盘。

耗时的其实不是下载，而是下载时验证所有区块里的全部签名。

初始区块下载通常要花多久？中途会变慢，还是全程速度差不多？

我想过对链条的大部分做更粗略的检查、只认真验证最后几千个区块。可行，但工作量大，而且还有许多优先级更高的事要做。

简化支付验证（SPV）是为轻量级纯客户端用户准备的：他们只做交易、不生成、不参与节点网络。他们不需要下载区块，只需下载哈希链——目前大约 2MB，验证极快（验证整条链不到一秒）。如果网络变得非常大，比如超过 100,000 个节点，我们就用这个让普通用户不必成为完整节点也能交易。到那个阶段，大多数用户应该开始运行纯客户端软件，只有专业服务器农场继续运行完整网络节点，有点像 usenet 网络的整合方式。

SPV 尚未实现，也要到很远的将来才会实现，但当前的所有实现都是围绕支持它而设计的。

同时，vekja.net 和 www.mybitcoin.com 这类站点一直在试验基于账户的网站。你在网站上创建账户，把比特币存在那里的账户里，转入转出。在网站注册账户比安装、学习使用软件容易得多，对大多数人也是更熟悉的方式。唯一的缺点是你必须信任该站点，但对零钱数额的微支付和杂项开支来说这没问题。这是很好的入门方式，等金额大了再升级到真正的 bitcoin 软件。

设计中勾勒了一个不需要完整区块链的轻量客户端。在设计 PDF 里它叫简化支付验证（Simplified Payment Verification）。轻量客户端可以收发交易，只是不能生成区块。它不需要信任某个节点来验证支付，仍能自行验证。

轻量客户端尚未实现，计划是在需要时实现。目前，每个人都运行完整的网络节点。

我预计节点永远不会超过 10 万个，可能更少。它会达到一个均衡：再多节点加入就不值当了。其余的将是轻量客户端，可能数以百万计。

达到均衡规模后，许多节点将是服务器农场，农场里有一两个网络节点，通过局域网喂给农场其余部分。

每个用户都是一个网络节点的现状，并非大规模阶段的预期形态。那就像每个 Usenet 用户都跑自己的 NNTP 服务器。这个设计支持让用户就只做用户。跑一个节点的负担越重，节点就会越少。那少数节点会是大型服务器农场。其余的是只做交易、不挖矿的客户端节点。

其他参与者原话bytemasterJuly 28, 2010原帖 ↗

再说，10 分钟才确认付款有效太慢了。它得像今天刷信用卡一样快。

看那个零食机主题，我在里面概述了支付处理器如何在 10 秒或更短时间内把支付验证得足够好，实际上相当好（欺诈率远低于信用卡）。如果你不信，或者没看懂，抱歉，我没时间说服你。

http://bitcointalk.org/index.php?topic=423.msg3819#msg3819

最好尽可能让 blk*.dat 文件保持小。

终极方案是不再在乎它有多大。

但目前它还小，最好保持小，好让新用户更快上手。等我最终实现 client-only 模式，这就不太重要了。

手续费还有工作要做。万一发生洪水攻击，你仍然可以通过支付 0.01 手续费插队，把自己的交易送进下一个区块。不过我还没来得及在界面上加这个选项。

无论规模大小，测试网的反应方式都一样，只是浪费的带宽和造成的困扰少得多。

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

应用这个补丁会让你与其他 Bitcoin 客户端不兼容。

+1 theymos。别用这个补丁，它会让你与网络不兼容，损人不利己。

将来如果更接近需要了，我们能分阶段引入变更。

它能分阶段引入，比如：

if (blocknumber > 115000)

maxblocksize = largerlimit

它能提前很多个版本就写进去，这样等到到达那个区块号、真正生效时，没有它的旧版本早已被淘汰。

接近截止区块号时，我能向旧版本发警报，确保它们知道自己务必升级。