中本聪谈手续费

……的 readlink 编译警告 用 sys/param.h 和 BSD define 替代 __BSD__ -paytxfee 开关，譬如 -paytxfee=0.01

不，不是这么回事。 -paytxfee 允许你在交易里附带交易费。倘若交易确认变慢了，你可以用 "-paytxfee=0.01" 来获得优先。你发出的每笔交易都会多花 0.01。没有理由设得比 0.01 更高。 它只是放在那里以防万一。多半用不上，真用上了再细说也不迟。

另一个选项是降低每个区块允许的免费交易数量，超过之后才要求手续费。节点每个区块仅仅接受一定 KB 的免费交易，超过后就开始要求至少 0.01 交易费。 这个门槛理应比现在更低。 我认为门槛永远不该是 0。我们理应始终允许至少一些免费交易。

目前，付不付手续费由 -paytxfee 开关手动控制。让软件自动检查最近区块的大小、判断是否该付手续费，相当容易。我们离触及门槛尚且远得很，暂时不需要。而且先看看手动控制的效果如何，本来就是个好主意。 就算到了门槛也没什么大不了。免费交易不过是要花更久才进区块。 我粗略统计了 74000-78000 附近的 4000 个区块。这不包括区块奖励交易： 平均每区块 2 笔交易、每小时 17 笔、每天 400 笔。 平均每区块交易字节 428 字节，即每笔交易 214 字节。 现……

……什么操作系统？ 你是用 IP 发的还是用 Bitcoin 地址发的？ 你发 49.99 时，它有没有提示你付 0.01 手续费？ GetMinFee 有过一个改动，然而我看不出它怎么会导致这个。它仅仅在区块变得巨大时才开始生效。 区块数不同的原因，是 0.3.11 里把显示数字减了 1，因那样更合理。

……易。它里面很可能带了一笔低于 0.01 的交易费。 有人一直在付 0.00000010 的交易费。我觉得用 -paytxfee 你连这个都设不出来，得改代码才行。你生成的区块价值 50.00000010，因而当你试图把整笔发出去时，只剩 0.00000010 当找零，这就触发了灰尘垃圾的 0.01 交易费。 除了这个边角案例它通常无害。我理应给 CreateTransaction 加个特例来处理这种情况。

……00 多倍。 我已在 SVN rev 157 里实现了这个改动。 我之前把门槛定得那么高，是为了允许相当大的交易不触发手续费。对于用 50 BTC 生成币构成的交易，门槛折合约 26,000 BTC。尽管当时的铸币难度比现在低 100 倍，那个水平下也只有极少数人碰到过手续费。新门槛把发送生成币的门槛放到了约 11,000 BTC。它基本只有用生成币时才会触及。倘若你是买来的比特币，它们以更大的交易计价，离手续费上限远得很——除非你是用几百笔独立交易买的。就算你真的触及手续……

它随区块填满逐步抬高手续费要求： 这是典型的定价机制。前 50KB 卖完后，价格涨到 0.01。250KB 卖完后，涨到 0.02。到了某个价格，只要你愿意出价比其他客户高，你几乎总能挤进去。 仅仅附上最低的 0.01 就已然大有帮助。

……if (!fPrinted) { @@ -2989,6 +2993,17 @@ // Transaction fee based on block size int64 nMinFee = tx.GetMinFee(nBlockSize); + //////// temporary code + if (nBlockSize < MAX_BLOCK_SIZE_GEN / 10 && GetWarnings("statusbar") == "") + { + if……

ArtForz 已然在免手续费运行了，他占全网算力的 20-30%。不过，最初发送这些坏交易的人已然删掉了自己的钱包，网络亦忘掉了这些历史交易，因而基于此的交易无法确认。 在你的节点拥有一条回溯到区块链的交易路径之前，交易不会被接受、亦不会显示为 0/unconfirmed。 你钱包里的任何交易亦都捆绑着抵达区块链所需的全部未记录交易。倘若你有一笔显示为 0/unconfirmed 的交易，那么它依赖的所有先前未记录交易你都有，你重播自己的交易时亦会一并重播它们。 倘若免手……

0.3.15 版现已发布。 变更： - paytxfee 开关现在按 KB 计，因而会给大额交易加上正确的手续费 - 发送时尽可能避免使用确认数少于 6 的币 - BitcoinMiner 按依赖交易年龄的优先级顺序处理交易 - 确保区块 74000 下载完成之前不启动挖矿 - Dean Gores 的若干错误修复 - getinfo 新增 testnet、keypoololdest 和 paytxfee

……们不需要做到这么细。正常用户和攻击者之间的差异足够大。 优先级不必包办一切。一旦确认有洪水攻击，你能够加上 -paytxfee=0.01。希望有了优先级机制，你在此之前发出的交易最坏也不过是慢，而不是卡死。

或许在最近实现的年龄优先级规则之外，还应加一条无手续费交易的最小年龄规则。换句话说，或许能够定一条生成规则：免费交易务必埋深 3 个区块之后才能再次免费转账。如此真实用户在必要时仍可立即花掉新资金，同时仍然能够不计成本地重新调配自己的资金。我认为这会显著抑制目前正在进行的垃圾交易攻击。 我正在做的就是类似的事。优先级就是你描述的这个概念更正式化的版本。 按现状，3.15 有不少免费交易空间，这些空间优先给 [年龄]*[金额]/[大小] 最高的交易，对吧？划出一部分自由空间要……

0.3.17 版现已发布。 变更： - 新的 getwork，感谢 m0mchil - UI 选项菜单中新增交易手续费设置 - 免费交易限额 - sendtoaddress 返回交易 ID 而不是 "sent" - getaccountaddress UI 里的交易手续费设置很容易，因它从 0.1.5 起就留在那里，我只需重新启用。 基于账户的命令：move、sendfrom 和 getbalance 将在下一版发布。在那之前我们还有一些改动要做。 下载： http://s……

……交易的客户端」而就绪。 时间戳哈希现在已然可行： txin: 0.01 txout: 0.00 OP_CHECKSIG fee: 0.01 倘若真有像 BitDNS 这样的应用准备开始插入哈希，我们随时能够为时间戳加一个专门的交易模板。 我喜欢 Hal Finney 那个用户友好的时间戳构想。把文件的哈希转换成一个比特币地址，进而向它发送 0.01： 我想到了一个简单办法来实现上面说的时间戳概念。对想加时间戳的文件跑 sha1sum。把结果转换成一个比特币地址，譬如通过 ht……

不是 locktime。 有一个面向遥远未来的可能设计： 你有意写一笔双重支出。用同样的输入和输出再写一遍，然而这次带上手续费。当你的双重支出进入区块时，第一笔支出就失效了。收款方其实不会察觉，因在新交易生效的那一刻，旧交易就失效了，新交易直接取而代之。 说起来容易，实现起来难。要写出一个能正确构造双重支出的客户端、在钱包里管理两个版本直到其中之一被选中、处理好所有边角情况，工作量不小。现有代码里的每一个假设都是「你不会试图写双重支出」。 比特币矿工侧亦需要一些改动，让交易池……

……的出块间隔更合适。 到目前为止这场讨论里已然需要不少管理数据了。倘若你能自由使用所需的空间、不必为比特币链里的昂贵空间付手续费，事情会容易得多。有这么几种交易： 更改 IP 记录。 改名。一个域名对象能够让你持有一个域名，并且能够随意把它改成任何未被占用的名字。这会鼓励用户释放不再想要的域名。生成的域名起初是空白的，由矿工卖给某个人，由他改成自己想要的名字。 续期。能够免费，或者要求消耗另一个域名对象来续期。在后者情况下，域名对象（域名币？）能够代表持有一个域名一年的权利。花……

我同意。所有交易——IP 更改、续期等等——都理应带一笔归矿工的手续费。 你能够考虑用一定量的工作来生成一个域名，而不是固定总量发行。每个域名的工作量能够按随摩尔定律增长的计划表来安排。如此域名的数量会随需求和用户数的增长而增长。