这次
@LukeDashjr 对于比特币协议栈涉及 Ordinals 的部份的更新内容的讨论中,我觉得有一些误解和容易混淆的概念,顺便翻了下源代码,聊聊几点:
1. 「比特币核心开发者」 是最容易被误解的说法,让人以为是某种「官方」团队,但更推荐的说法是「Bitcoin Core 客户端开发者」,因为 Core 在这里不是形容词(注意是大写,并且 Luke 的推文和 Profile 都用的大写 Core),这里的 Bitcoin Core 就特指这个客户端而已。
2. Bitcoin Knots 是比特币协议的另一个客户端,Luke 虽然同时给 Core 和 Knots 提交代码,但从近期的提交次数看,他主要在维护 Knots(但维护者也远不止他一个人)。特别是这次 Bitcoin Knots 25.1 的更新文档也主要是他写的。
3. Luke 本人是 OCEAN 矿池的 CTO,Ocean Mining 会用这个客户端,也是最近刚拿到 Jack Dorsey 支持的矿池。
(由
@fishkiller 提供的信息)
-----------------
关于源代码中相关的部份,我目前翻到了一部分,供参考:
在 Bitcoin Core v0.13.0 隔离见证升级时,增加了一个常量限制脚本大小为 10000 字节
> static const int MAX_SCRIPT_SIZE = 10000
来源:
github.com/bitcoin/bitcoin/b…
在这里的逻辑会判断:
> if (script.size() > MAX_SCRIPT_SIZE)
> return set_error(serror, SCRIPT_ERR_SCRIPT_SIZE);
来源:
github.com/bitcoin/bitcoin/b…
然后在 Taproot (Bitcoin Core v0.21.0)升级时,这个常量 MAX_SCRIPT_SIZE 并没有更新,而是在判断时增加了逻辑,如果是 Taproot (Segwit V1)就会绕开这个限制,而对于老的脚本还是有这个限制。
> if ((sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) && script.size() > MAX_SCRIPT_SIZE) { return set_error(serror, SCRIPT_ERR_SCRIPT_SIZE); }
来源:
github.com/bitcoin/bitcoin/b…
而 Luke 在推特提到的「-datacarriersize」、「-datacarriercost」和「-maxscriptsize」是客户端可以设置的几个参数。
相比Bitcoin Core 的 26.0 版本,Bitcoin Knots 的 25.1 版本修改了 -datacarriersize 的描述,并且将默认值从 83 改为了42;新增的 -datacarriercost、-datacarrierfullcount 和 -maxscriptsize 则可以进一步控制携带数据的规模。那对于矿工来说,就有自由选择的空间了。
来源1:
github.com/bitcoin/bitcoin/b…
来源2:
github.com/bitcoinknots/bitc…