中本聪谈手续费

不是 SATONAMO 写一篇长文,而是他本人的原话。以下 45 条记录按时间排序,每一条都可以回到完整上下文。

2008 年 11 月 10 日 · 密码学邮件列表 · 比特币点对点电子现金论文 · SN-10013
如果你对通货膨胀这一点有顾虑,很容易把它调整为通过手续费支付。办法很简单:让任何一笔交易的输出金额都比输入金额少 1 分钱。客户端软件可以自动生成金额比预定付款金额多 1 分钱的交易,或者也可以从收款方扣除。当节点找到一个区块的工作量证明时,其奖励金额可以是该区块内手续费的总和。Satoshi Nakamoto
查看原文与上下文 →
2008 年 11 月 10 日 · 密码学邮件列表 · 比特币点对点电子现金论文 · SN-10014
借助我最近发布的基于手续费的激励系统,节点就有动力纳入收到的所有付费交易。Satoshi Nakamoto
查看原文与上下文 →
2008 年 11 月 15 日 · 密码学邮件列表 · 比特币点对点电子现金论文 · SN-10017
系统会有手续费,因此节点有动力尽可能接收并纳入所有交易。当生成的币总量达到预定上限时,节点最终将只靠手续费获得报酬。对。每笔交易都是这样的。见第 9 节,金额的合并与拆分。Satoshi Nakamoto
查看原文与上下文 →
2009 年 1 月 8 日 · 密码学邮件列表 · 比特币 v0.1 发布 · SN-10021
这些币发完后,系统可以在需要时支持手续费。这基于公开的市场竞争,而且很可能始终会有节点愿意免费处理交易。Satoshi Nakamoto
查看原文与上下文 →
2009 年 1 月 12 日 · Bitcoin 邮件列表 · [bitcoin-list] 比特币 v0.1 Alpha 发布说明 · SN-10027
这些币发完后,系统可以在需要时支持手续费。这基于公开的市场竞争,而且很可能始终会有节点愿意免费处理交易。Satoshi Nakamoto
查看原文与上下文 →
2009 年 2 月 4 日 · Bitcoin 邮件列表 · [bitcoin-list] 比特币 v0.1.5 发布 · SN-10041
为少于 1 分的交易设定最低手续费隐藏了只有一个选项的交易类型选择框稍微整理了 ParseMoney将消息文本的格式整理得稍微清晰一些更改了交易详情对话框的字体在生成币的交易详情中添加了一些说明文字改写了通过比特币地址收到的交易的描述Satoshi Nakamotohttp://www.bitcoin.org
查看原文与上下文 →
2009 年 2 月 13 日 · P2P Research 邮件列表 · [p2p-research] 比特币点对点电子货币 v0.1 发布 · SN-10046
这些币发完后,系统可以在需要时支持手续费。这基于公开的市场竞争,而且很可能始终会有节点愿意免费处理交易。Satoshi Nakamotohttp://www.bitcoin.org
查看原文与上下文 →
2009 年 4 月 12 日 · Mike Hearn 通信 · Satoshi 致 Mike Hearn:比特币的扩展能力(2009年4月12日) · SN-10050
我预计近期不需要手续费,但如果运行节点的负担变得过重,就可以运行一种只处理附带手续费的交易的节点。节点所有者自行决定能接受的最低手续费。目前,这样的节点什么也赚不到,因为没人附带手续费;但如果足够多的节点这么做,用户附带手续费就会更快得到接受,不附带则会更慢。市场最终确定的手续费应该很低。如果一个节点要求更高手续费,就会放弃所有手续费更低的交易。尽可能处理更多付费交易,它就能增加业务量,也可能赚得更多。
查看原文与上下文 →
2009 年 5 月 3 日 · Martti Malmi 通信 · 回复:Bitcoin · SN-10059
我预计近期不需要手续费,但如果运行节点的负担变得过重,就可以运行一种只处理附带手续费的交易的节点。节点所有者自行决定能接受的最低手续费。目前,这样的节点什么也赚不到,因为没人附带手续费;但如果足够多的节点这么做,用户附带手续费就会更快得到接受,不附带则会更慢。市场最终确定的手续费应该很低。如果一个节点要求更高手续费,就会放弃所有手续费更低的交易。尽可能处理更多付费交易,它就能增加业务量,也可能赚得更多。
查看原文与上下文 →
2009 年 10 月 16 日 · Martti Malmi 通信 · 回复:安装、自启动、v0.1.6 · SN-10071
我准备隐藏手续费设置,它完全没有必要,只会让人困惑。它原本只是用于测试和演示一个技术细节,这个细节即使会用到,也只是很遥远的未来才需要;但必须从一开始实现,才能让以后成为可能。启动文件夹中的快捷方式出了什么问题?如果你能发来代码,我想再看看,能不能找出问题。注册表代码中的第一个 strcat 应该是 strcpy,否则会间歇性失败。如果快捷方式那部分也用了同样的代码,也许问题就在这里。看到更多人产生兴趣,比如那个 NewLibertyStandard 网站,让人受到鼓舞。
查看原文与上下文 →
2009 年 10 月 21 日 · Martti Malmi 通信 · 回复:安装、自启动、v0.1.6 · SN-10074
禁用手续费选项把最小化到托盘选项做得类似 Firefox 的 MinimizeToTray自 0.1.5 发布以来的其他许多杂项改动我让程序不再显示未接受的生成币。生成的币至少有一个确认(后面接上一个区块)才会显示,所以通常根本不会看到未接受的币。偶尔,已经显示的生成币可能会消失,因为后来变成了未接受。我想,如果我们不在界面上特意指出,人们不会注意到偶尔发生的未接受。有人告诉我,这些条目永久显示在交易记录中,看着很烦。我还有更多测试要做。
查看原文与上下文 →
2009 年 12 月 2 日 · Martti Malmi 通信 · 回复:Bitcoin.org · SN-10126
数据体积过大的交易,超过首个 1KB 的部分,每 KB 收取 0.01 手续费。首个 1KB 免费,体积较小的交易通常为 250 字节。双击那笔交易看看。可以把它想成按重量收取邮费。解决办法是在发送时额外弹出一个对话框,例如:“这笔交易的数据体积较大,需要支付 0.20bc 的手续费。可以吗?”(这段文字够好吗,还是需要改进?)代码已经有了,我会加进去。这样就不用解释那笔 10,000.20bc 的交易了,不过可能仍需要解释手续费归谁。
查看原文与上下文 →
2009 年 12 月 4 日 · Martti Malmi 通信 · 回复:Bitcoin.org · SN-10127
免手续费交易的数据体积上限将是 60KB,如果由 50bc 的输入构成,大约相当于 27,000bc。我希望这个上限足够高,使手续费很少出现。v0.2 节点会接收免费交易,直到区块大小超过 200K,并优先处理数据体积较小的交易。最好不要公开谈这些手续费的事。它是用来控制洪泛的。我们不想给任何人出主意。你发现了 CreateTransaction 中一个不常见的错误。它生成的交易金额是 10000.20,手续费为 0.22。
查看原文与上下文 →
2010 年 2 月 12 日 · Bitcointalk · 这次奇怪的挖矿产出是怎么回事? · SN-0290
数据体积很大的交易需要支付一笔小额手续费。生成包含该交易的区块的节点会得到这笔费用。同一笔钱之后再次转出时,不会再次产生这笔费用。如果你的钱包里全是挖矿所得,又想一次全部转出,就必须在一笔数据体积很大的交易中,合并数百份每份 50 个比特币的挖矿奖励。完成这次合并后,以后再转出这笔资金时,交易里只需要一个输入项。
查看原文与上下文 →
2010 年 2 月 14 日 · Bitcointalk · 这次奇怪的挖矿产出是怎么回事? · SN-0294
只有发送数据体积特别大的交易时才会收取手续费,即便这样,算下来也大约只有金额的 0.002%。这并非从系统里抽走的钱,它只是流向其他节点。如果你为付这笔费而难过,你随时可以反客为主自己运行一个节点,说不定哪天你自己就捞到一笔 0.44 的费用。
查看原文与上下文 →
2010 年 2 月 14 日 · Bitcointalk · 这次奇怪的挖矿产出是怎么回事? · SN-0296
几十年后当回报变得太小,手续费将成为节点的主要补偿。我相信 20 年后,要么交易量非常大,要么就没有交易量。
查看原文与上下文 →
2010 年 5 月 26 日 · Bitcointalk · 挖出的比特币数量有些奇怪 · SN-0541
在 SVN 版本里,如果一笔交易需要手续费,它会显示:"这笔交易超过了数据体积限制。你仍可支付 # 的费用发送,费用将付给处理你的交易的节点,有助于支持网络。你愿意支付这笔费用吗?"如果加上费用后你的钱不够,它会显示:"计入 # 手续费后,总额超出你的余额 "
查看原文与上下文 →
2010 年 6 月 18 日 · Bitcointalk · 交易与脚本:DUP HASH160 ... EQUALVERIFY CHECKSIG · SN-0760
这正是手续费存在的原因之一。必要的话我们还有别的办法。从 2007 年开始。某一刻我确信存在一种完全不需要信任的做法,从此欲罢不能地一直想下去。工作量里设计远多于编码。幸运的是,到目前为止被提出的问题,都是我以前考虑过并做了规划的。
查看原文与上下文 →
2010 年 8 月 5 日 · Bitcointalk · 0.00000001 BC 洪泛攻击 · SN-0998
如果有人开始通过大量来回转账的垃圾交易对我们发动 DoS 攻击,你就需要开始支付 0.01 的最低手续费了。0.1.5 其实有过设置它的选项,但我为了减少困惑把它拿掉了。免费交易是件好事,只要大家不滥用,我们可以一直这样。这就引出一个问题:如果每笔交易有 0.01 的最低手续费,如果只是最低的 0.01,我们要不要自动加上?每次都问一遍会烦死人。如果你有 50.00、发送 10.00,收款方得到 10.00,你剩 39.99。我认为应该自动加上。
查看原文与上下文 →
2010 年 8 月 5 日 · Bitcointalk · 0.00000001 BC 洪泛攻击 · SN-1001
给区块创建者的手续费用了一个特殊技巧,让手续费不占任何额外空间。如果每笔手续费都是一笔交易,那么支付手续费的交易本身所需的手续费,又该怎么办?
查看原文与上下文 →
2010 年 8 月 5 日 · Bitcointalk · 交易过载的解决方案 · SN-2101
所有手续费都会是额外的交易。那么支付手续费的交易本身所需的手续费,又该怎么办?
查看原文与上下文 →
2010 年 8 月 5 日 · Bitcointalk · 0.00000001 BC 洪泛攻击 · SN-1004
哦,你是说给每个节点发一个不同变体、把手续费写成给他们的?现在的规矩是:谁打出区块谁拿走。真需要的话,我们可以搞一个 BitTorrent 式的以牙还牙机制来做交易广播:向我转发付费交易,否则我也不向你转发。不过这多半不会成为真问题。只要有一个节点按规矩转发,就能抵消另外 7 个贪心地不转发的节点。
查看原文与上下文 →
2010 年 8 月 11 日 · Bitcointalk · 专门讨论 Bitcoin 可能存在的弱点的独立讨论区在哪里? · SN-2286
我想过很多次给交易加 PoW,但通常想来想去,觉得 0.01 手续费本质上与之相似且更好。0.01 基本就是一份工作量证明,但不是浪费。不过如果问题出在验证大量交易上,那 PoW 的验证可以更快。一种能缓解多类问题的办法,是实现前面提到的想法:检测收到区块的频率是否出现了不太可能由偶然因素造成的骤降。这样攻击者仍需要掌握网络算力的相当部分,才能从 DoS 攻击中获益。+1此刻任何演示性测试都只能证明我们已知的东西,还会把开发时间从强化系统挪去救火。
查看原文与上下文 →
2010 年 8 月 11 日 · Bitcointalk · 0.00000001 BC 洪泛攻击 · SN-1013
手续费还有工作要做。万一发生洪水攻击,你仍然可以通过支付 0.01 手续费插队,把自己的交易送进下一个区块。不过我还没来得及在界面上加这个选项。无论规模大小,测试网的反应方式都一样,只是浪费的带宽和造成的困扰少得多。
查看原文与上下文 →
2010 年 8 月 12 日 · Bitcointalk · SVN rev 130 中的错误修复 · SN-2291
-paytxfee 开关,比如 -paytxfee=0.01
查看原文与上下文 →
2010 年 8 月 13 日 · Bitcointalk · SVN rev 130 中的错误修复 · SN-2294
-paytxfee 允许你在交易里附带手续费。如果交易确认变慢了,你可以用 "-paytxfee=0.01" 来获得优先。你发出的每笔交易都会多花 0.01。没有理由设得比 0.01 更高。它只是放在那里以防万一。多半用不上,真用上了再细说也不迟。
查看原文与上下文 →
2010 年 9 月 7 日 · Bitcointalk · 总是支付手续费? · SN-2710
另一个选项是降低每个区块允许的免费交易数量,超过之后才要求手续费。节点每个区块只接受一定 KB 的免费交易,超过后就开始要求至少 0.01 手续费。这个门槛应该比现在更低。我认为门槛永远不该是 0。我们应该始终允许至少一些免费交易。
查看原文与上下文 →
2010 年 9 月 8 日 · Bitcointalk · 总是支付手续费? · SN-2714
目前,付不付手续费由 -paytxfee 开关手动控制。让软件自动检查最近区块的大小、判断是否该付手续费,相当容易。我们离触及门槛还远得很,暂时不需要。而且先看看手动控制的效果如何,本来就是个好主意。就算到了门槛也没什么大不了。免费交易只是要花更久才进区块。我粗略统计了 74000-78000 附近的 4000 个区块。这不包括区块奖励交易:平均每区块 2 笔交易、每小时 17 笔、每天 400 笔。平均每个区块中的交易数据共 428 字节,即每笔交易 214 字节。
查看原文与上下文 →
2010 年 9 月 10 日 · Bitcointalk · 因为需要手续费,就不让我发送比特币? · SN-2731
你发 49.99 时,它有没有提示你付 0.01 手续费?GetMinFee 有过一个改动,但我看不出它怎么会导致这个。它只在区块变得巨大时才开始生效。区块数不同的原因,是 0.3.11 里把显示数字减了 1,因那样更合理。
查看原文与上下文 →
2010 年 9 月 10 日 · Bitcointalk · 因为需要手续费,就不让我发送比特币? · SN-2732
它里面很可能带了一笔低于 0.01 的手续费。有人一直在付 0.00000010 的手续费。我觉得用 -paytxfee 你连这个都设不出来,得改代码才行。你生成的区块价值 50.00000010,因此当你试图把整笔发出去时,只剩 0.00000010 当找零,这就触发了针对粉尘垃圾交易的 0.01 手续费。除了这个边界情况,它通常不会造成问题。我应该给 CreateTransaction 加个特例来处理这种情况。
查看原文与上下文 →
2010 年 9 月 23 日 · Bitcointalk · 总是支付手续费? · SN-2715
我之前把门槛设得那么高,是为了让数据量很大的交易也不必支付手续费。对于由一笔笔 50 BTC 挖矿奖励组成的交易,这个门槛大约相当于 26,000 BTC。尽管当时挖矿比现在容易 100 倍,也只有极少数人达到过这个手续费门槛。新门槛下,转出挖矿所得时大约到 11,000 BTC 才会触发手续费,而且主要只有挖矿所得才容易遇到这种情况。如果你的比特币是买来的,它们通常来自金额更大的交易,离手续费门槛还很远,除非你分几百笔交易买入。
查看原文与上下文 →
2010 年 9 月 30 日 · Bitcointalk · 交易优先级与手续费 · SN-2851
随着区块逐渐填满,它会逐步提高手续费要求:<50KB 免费50KB 0.01250KB 0.02333KB 0.03375KB 0.04以此类推。这是典型的定价机制。前 50KB 卖完后,价格涨到 0.01。250KB 卖完后,涨到 0.02。到了某个价格,只要你愿意出价比其他客户高,你几乎总能挤进去。只附上最低的 0.01 就已经大有帮助。
查看原文与上下文 →
2010 年 10 月 3 日 · Bitcointalk · 0.3.13 版,请升级 · SN-2872
// Transaction fee based on block size int64 nMinFee = tx.GetMinFee(nBlockSize);+ //////// temporary code+ if (nBlockSize mapTestPoolTmp(mapTestPool);
查看原文与上下文 →
2010 年 10 月 3 日 · Bitcointalk · 0.3.13 版,请升级 · SN-2875
如果免手续费的区块已经生成、却没起作用,那我需要看看哪里出了问题。这是一段很少被用到的代码。只要某人的钱包中有交易依赖这些前序交易,这些前序交易就应该也保存在他的钱包中。叹气……为什么要删除钱包,而不是把它移到一边、留个旧副本以防万一?永远不要删除钱包。收集重新广播的交易可能需要一段时间。如果你能接受入站连接会更有帮助,这样就能收到更多节点的消息。就算你 3 小时内出了块,也请至少连续跑上几天。
查看原文与上下文 →
2010 年 11 月 13 日 · Bitcointalk · 我在测试网上做的一些测试及发现 · SN-3198
手续费仍然优先于优先级,而优先级决定同一费率层内的处理顺序。为支持优先级功能,SelectCoins 只在万不得已、只剩下你自己的 0 确认交易时才使用它们。这样可以避免你过于频繁地周转自己的币,除非你确实在快速周转全部持币,强行让程序这样做。
查看原文与上下文 →
2010 年 11 月 13 日 · Bitcointalk · 0.3.15 版 · SN-3349
- paytxfee 开关现在按 KB 计,因此会为数据量较大的交易附上正确的手续费- 发送时尽可能避免使用确认数少于 6 的币- BitcoinMiner 按依赖交易年龄的优先级顺序处理交易- 确保区块 74000 下载完成之前不启动挖矿- Dean Gores 的若干错误修复- getinfo 新增 testnet、keypoololdest 和 paytxfee
查看原文与上下文 →
2010 年 11 月 14 日 · Bitcointalk · 我在测试网上做的一些测试及发现 · SN-3200
一旦确认有洪水攻击,你能加上 -paytxfee=0.01。希望有了优先级机制,你在此之前发出的交易最坏也只是慢,而不是卡死。
查看原文与上下文 →
2010 年 11 月 19 日 · Bitcointalk · 正在发生的交易/垃圾交易洪泛攻击 · SN-3633
我认为这是在把默认手续费设为 0.01 之外的一个好折中。要求通过免费交易周转比特币时,频率不能过高,并不算过分。你用免费交易,就是在接受施舍,而同一批币能多频繁地享受这种施舍,总得有个上限。我们一直说免费交易可能会处理得慢一些。加上 -paytxfee=0.01 能帮你确保交易快速通过。
查看原文与上下文 →
2010 年 11 月 25 日 · Bitcointalk · 0.3.17 版 · SN-3689
- UI 选项菜单中新增交易手续费设置- 免费交易限额- sendtoaddress 返回交易 ID 而不是 "sent"- getaccountaddress 在 UI 中加入交易手续费设置很容易,因为它从 0.1.5 起就一直保留着,我只需重新启用。基于账户的命令:move、sendfrom 和 getbalance 将在下一版发布。在那之前我们还有一些改动要做。下载:
查看原文与上下文 →
2010 年 12 月 9 日 · Bitcointalk · 0.3.18 版 · SN-3801
fee: 0.01如果真有像 BitDNS 这样的应用准备开始插入哈希,我们随时能为时间戳加一个专门的交易模板。我喜欢 Hal Finney 那个用户友好的时间戳构想。把文件的哈希转换成一个比特币地址,然后向它发送 0.01:
查看原文与上下文 →
2010 年 12 月 9 日 · Bitcointalk · 关于 BitDNS 手续费的疑惑 · SN-3810
用同样的输入和输出再写一遍,但这次带上手续费。当你的双重支付进入区块时,第一笔支出就失效了。收款方其实不会察觉,因在新交易生效的那一刻,旧交易就失效了,新交易直接取而代之。说起来容易,实现起来难。要写出一个能正确构造双重支付的客户端、在钱包里管理两个版本直到其中之一被选中、处理好所有边角情况,工作量不小。现有代码里的每一个假设都是「你不会试图写双重支付」。比特币矿工侧也需要一些改动,让交易池有可能接受双重支付,但只严格限于输入输出匹配且手续费更高的情况。
查看原文与上下文 →
2010 年 12 月 10 日 · Bitcointalk · BitDNS 与比特币的通用化 · SN-3610
如果你能自由使用所需的空间、不必为比特币链里的昂贵空间付手续费,事情会容易得多。有这么几种交易:更改 IP 记录。改名。一个域名对象能让你持有一个域名,并且能随意把它改成任何未被占用的名字。这会鼓励用户释放不再想要的域名。生成的域名起初是空白的,由矿工卖给某个人,由他改成自己想要的名字。续期。可以免费,也可以考虑要求消耗另一个域名对象。在后者情况下,域名对象(域名币?)能代表持有一个域名一年的权利。花掉的金额会作为下一区块的手续费归矿工。
查看原文与上下文 →
2010 年 12 月 10 日 · Bitcointalk · BitDNS 与比特币的通用化 · SN-3613
所有交易——IP 更改、续期等等——都应该带一笔归矿工的手续费。你能考虑用一定量的工作来生成一个域名,而不是固定总量发行。每个域名所需的工作量可以按照摩尔定律逐步增加。这样域名的数量会随需求和用户数的增长而增长。
查看原文与上下文 →
2011 年 3 月 9 日 · Mike Hearn 通信 · Satoshi 致 Mike Hearn:关于比特币合约、序列号与高频交易(2011 年 3 月 9 日) · SN-10213
它对提高手续费没有帮助。交易从 nLockTime 开始有效。让一笔交易在某个时间失效,是行不通的;一笔交易一旦变得有效,就必须永久保持有效。参见这些主题:http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729这是为合约准备的。
查看原文与上下文 →
2011 年 3 月 9 日 · Mike Hearn 通信 · Satoshi 致 Mike Hearn:关于合并挖矿、放弃的内置市场与独立链(2011 年 3 月 9 日) · SN-10214
上面的一个链接里,我考虑过发送一笔诚实的双重支付交易,以提高手续费。工作量很大,但可以做到。我认为目前不值得做。目前的系统运作得足够好:节点确保按当前状况附上足够的手续费,而网络确保所有交易最终都得到处理。节点在创建自己的交易时没有检查优先级,这是一个疏漏,Gavin 正在修复。如果用户仍然担心处理速度的不确定性,应该把它看作添加手续费的理由。我当时试图实现一个内置于客户端的 eBay 式市场。发布/订阅机制用来广播商品报价和评分/评价。你发表的评价会按你生成的区块加权。
查看原文与上下文 →
想看更多,可到档案中搜索「手续费」。

阅读字号

选择适合你的字号,之后阅读会继续使用。