51 关于洪水攻击的防御
本章提出的关注点相当于比特币网络的拒绝服务（DoS）攻击，由一个实体发出数百万笔交易，每次汇出一小笔钱，例如1聪（0.00000001枚比特币）。这组讨论比其他的更具技术性，且并非讨论中的所有帖子都复制到了这里，这里只有主题相关的以及中本聪本人所关注的问题。
洪水攻击一0.00000001比特币
Mionione发表，2010年7月12日，下午12:04:24
如果有人向数百万个地址同时发送0.00000001枚比特币，会发生什么事？
•所有的网络节点都必须存储所有的交易吗？
•每个0.00000001比特币的所有者/哈希都存储在所有节点的区块里吗？
我不太理解比特币如何处理小额比特币。
回复：洪水攻击一0.00000001比特币
加文•安德森发表，2010年7月12日，下午12:08:45
这是从源代码里摘录出来的：
main.h： //为了限制垃圾支付，对任何小于0.01比特币的转出需要收取0.01比特币费用。
回复：洪水攻击一0.00000001比特币
llama发表，2010年7月12日，下午02:23:46
呃，我没想到里面居然有这个，我真的不喜欢这种方法。
这极大破坏了使用比特币进行真实小额支付的可能性。让客户端忽略垃圾支付发送者的IP不是更好吗？当然，攻击者还是能发出很多，但是到不了百万量级
但是如何区分合法的小额支付处理IP和一个“让比特币耗费的带宽太多，都没人愿意再用它”的垃圾支付IP?
真正的小额支付在我看来是非常麻烦的问题，我认为比特币不应该一下子解决太多过于棘手的问题。
回复：洪水攻击一0.00000001比特币
Insti发表，2010年8月4日，下午02:58:31
0.01枚比特币交易费要解决的“垃圾支付”到底是什么？
在我看来弊大于利，因为这阻碍了像bytemaster所建议的小额支付的实现。 我并没感觉到网络在现有交易量的压力下变得拥堵。
想要进行大量交易可以通过向自己大量发送x枚比特币来实现这一点。
回复：洪水攻击一0.00000001比特币
中本聪发表，2010年8月4日，下午04:25:36
引自：Insti，2010年8月4日，下午02:58:31
在我看来弊大于利，因为这阻碍了像bytemaster所建议的小额支付的实现。
比特币现阶段并不适用于交易额非常小的小额支付。不适用于像单次付费搜索或按页付费浏览这样没有聚合机制的情况，也不适用于支付需求小于0.01比特币的情况。垃圾支付限制是有意阻止这类小额支付的首次尝试。
比特币进行小型交易的可行性超过了现行法定货币。小到可以包括小额支付区间的所谓的顶部。但不会宣称可以进行任意小的小额支付。
回复：洪水攻击一0.00000001比特币
中本聪发表，2010年8月5日，下午04:03:21
忘了加上关于小额支付好的一面。虽然我认为比特币现在不适合做特别小额支付，但最终会随着存储和带宽成本的持续下降而变得可行。如果比特币发展到很大的规模，可能时机就到了。另一种让特别小额支付更为可行的方法是实现纯客户端模式，而且把网络节点的数量合并，形成较少数量的专业服务器集群。这样无论需要什么额度的小额支付，最终都将可行。我认为5到10年内，带宽和存储的成本将显得微不足道。
我并不是说网络可以免受DoS攻击的影响。但我认为大多数P2P网络都会以多种方式受到DoS攻击。（旁注：我了解到唱片公司想对所有的文件共享网络发起DoS攻击，但他们不想触犯反黑客/反滥用法律。）
如果我们开始遭受大量垃圾交易的DoS攻击，那就需要开始支付0.01枚比特币的最低交易费用。0.1.5版实际上就有一个选项做该设置，但我把它去掉了，以降低对用户的困扰。自由交易很美好，如果大家不滥用，可以保持下去。
这就提出了以下问题：如果每笔交易至少有0.01的费用，当费用正好是0.01的时候，是否应该自动把手续费加上？每次都问用户会很烦人。如果有50枚比特币，发出去10枚，接收者会得到10枚，剩下39.99枚比特币。我认为这时就该自动加上手续费。比起很多其他类型服务的自动费用添加，这简直微不足道。
引自：FreeMoney, 2010年8月4日，下午07:30:32
包括降低哈希速率吗？
没有，一点也没有。
回复：洪水攻击一0.00000001比特币
中本聪发表，2010年8月5日，下午04:30:20
引自：bytemaster
通常会提前支付，比如说每次一枚比特币，当断开连接，所有“零钱”会退回来。这条规则使得无法为没有进一步交易的简单“搜索查询”进行支付。
一种替代方案是使用一个汇总系统。例如，每次购买1000页或1000张图或1000次下载或1000次搜索等。当1000页用完了，再购买1000页。如果只要用到1页， 就会剩下999页再也用不上了，但也没什么大不了，因为每千页的花销仍然很小。
或者按天付费。首次访问网站的那一天，支付24小时的访问权限费。
每千页或每天的收费方式对客户来说可能更容易搞清楚。按件计费的方式让人焦虑，如果费用数字跳得太快，客户很难算清楚。24小时无限制使用，他们就会清楚要花多少钱。或者，如果1000次看起来非常多，估计超过了他们可能的使用量，他们也不会担心每次点击都要多花钱。
回复：洪水攻击一0.00000001比特币
中本聪发表，2010年8月5日，下午04:39:58
引自：bytemaster, 2010年8月5日，下午03:39:19
解决这个问题的唯一办法是让交易的广播“不免费”。也就是说，如果想让我收集区块，就得付给我钱。最终结果是，每个客户端需要给其他客户端付钱，甚至那些接收交易的客户端，而不仅仅是把交易收入区块的那个客户端。这样，经济规律起主导作用，没人能在交易广播系统上搭便车了。
我不知道应该如何实现这一点。留给区块创建者的交易费使用了特殊的技巧 ，在不增加额外空间的情况下包含了交易费用。如果每笔交易费也要由交易完成 ，那么发放交易费用的交易又要怎么收取交易费呢？
回复：洪水攻击一0.00000001比特币
中本聪发表，2010年8月5日，下午05:49:43
引自：bytemaster，2010年8月5日，下午04:46:52
现在是交易费地址“空着”不填，由区块生成者填写。这种情况下您想让谁创建区块就要填上他的地址。
如果您想指定一个人来创建这个区块，那可能要花好几天。您的意思是给每 个节点发送不同的交易费用吗？
现在的方式是谁创建区块谁拿钱。
如果有需要，可以为交易广播设计一套与比特流风格相反的机制。要么把支付交易转发给我，要么就不再转发这些交易。不过，在实际中这可能不是个问题 。只需要一个中继节点，就能抵消掉7个不转发的贪婪节点的影响。
回复：洪水攻击一0.00000001比特币
中本聪发表，2010年8月11日，下午11:28:50
最好尽可能长时间保持blk*.dat文件很小。
最终方案将不在意该文件的大小。
但在现阶段，虽然它仍然很小，还是最好继续保持这么小，这样新用户可以更快进入。等最终实现了纯客户端模式，这一点就不那么重要了。
交易费方面还有更多的工作要做。在洪水攻击情况下，仍然可以通过支付0.0 1的交易费用，让交易跳过队列进入下一个区块中。然而，我还没有功夫在用户界面中添加该选项。
不管多大规模，测试网络将以相同方式作出反应，但是浪费的带宽少很多， 也没那么烦人。