英文原文 翻译：DeepL， Google Translate 校对：李林 ZK rollups在比特币中是没有意义的，因为没有 “廉价的calldata”。 所有的数据都已经是廉价昂贵的calldata。 也许会有一个允许简洁签名的链上zk验证，但永远不会有滚动。 可能的情况是：你可以有一个包含多个余额的UTXO，在每个交易中，你可以重新创建该UTXO，但使用zk改变其状态，以压缩所有发生的内部交易。 区块链必须了解所有这些新事物，所以它绝不是 “L2”。 你必须有一个实体负责UTXO，并负责变化状态和ZK证明。 但在比特币上，你也必须把重建证明所需的数据保存在其他地方，我不确定负责该UTXO的第三方如何能确保这一点。 我认为这样的结构类似于信用卡公司：每个人都依赖一个中心方，与外部实体的互操作性为零，每个供应商都必须在每个信用卡公司上有一个账户才能向客户收费，因此，不清楚这样的东西是否比像Lightning这样真正开放和可互操作的解决方案更可取，后者可能有其缺陷，但至少促进了一个更好的环境，将不同的冲突方、保管人、任何人都聚集在一起。

英文原文 翻译：DeepL，Google Translate，校对：李林 (考虑到zksync.io的例子）（另外，不要相信我说的这些。） 是侧链。 通过把token存到以太坊主网的合约上实现把token存到这个侧链上。然后你在侧链上就有信用额度了。 在侧链上对交易签名然后发给一个中心化运营商，就实现了支付。 这个中心化运营商汇集了一批交易，计算新的侧链资产平衡表然后把当前状态的摘要发布到以太坊合约上。 思路就是以太坊链上的一个交易代表了侧链上的一批交易。 这个运营商也会把侧链上的交易的简要列表发布到以太坊合约上。这里的技巧是把所有的签名浓缩到一个零知识证明里面，这个证明就可以验证从上一个状态到新状态的切换是好的。 显然，他们可以在一个主链交易中容纳500个侧链交易（每个是12字节）。因此，我相信可以说所有这些zk-rollup的花样都可以转化为 “一个聚合交易的系统”. 我不明白零知识证明是如何运作的，但在这种情况下，它是一个需要可信设置的SNARK，我想与这个1类似。 这个文档已经被作者标记为废弃了。 ↩︎

英文原文 翻译：DeepL，Google Translate 校对：李林 在Anthony Towns的2021年的比特币博文中，他列出了一些可以用来攻击比特币的策略，而这些策略看起来不像是攻击: 大公司对其进行集中资助。例如，如果像Square这样的大公司支付大部分开发工作的费用，它就几乎可以控制项目的重点，以及哪些公关将被优先考虑，哪些将被排斥（他们甚至可以让它看起来像多个公司在做，而实际上所有的钱和权力都来自一个公司）。 攻击者 “愿意投入时间将自己打造成比特币贡献者”，这是一些个人可能正在做的努力，而像Square这样的大公司可以资助。 创造一些看起来能改善事情但最终却没有必要的变化，并在那里引入故意的漏洞。所有这些漏洞，即使是最有经验的审查员也很难发现。 创造越来越多的变化，并使它们都是原始的、正确的，耗尽审查员的所有耐心，只是为了在中间某个地方引入一个微妙的错误。发生的变化越多，需要审查的人就越多。如果每10个人中就有6或7个是由同一个攻击者实体资助的，只是为了产生更多的噪音，而故意把审查工作留给其他没有报酬的诚实的贡献者，情况就会变得更糟。 为了模块化而移动代码，使攻击者有机会在没有人注意到的情况下改变一些小东西，因为审查人员在看这些变化时，会认为它们只是被移到其他地方的同样的旧代码，而不是被改变的。这更难发现。 另一个获得存储库和开发过程控制权的方法是贿赂掉诚实的开发者去做其他的事情，这样他们就会为恶意的开发者打开空间。例如，如果像Square这样的公司开始给比特币核心开发者提供补助，让他们放松一下，开始做他们自己选择的更酷的项目，同时得到更多的报酬，他们很可能会接受的。 还有一种方式是让一些诚实的贡献者的经历非常痛苦和烦人，或者排斥他们。他引用了今天可能发生在LukeDashjr身上的事情，他是最重要和最有能力的比特币核心开发者之一，他没有从任何人那里得到任何资金，尽管他希望得到资金并签署了资助项目。

英文原文 翻译：DeepL，Google Translate 校对：李林 有多个策展人团队，对比特币有不同的审核过程和发布时间表，比单一的策展人团队要好。 “更多的人关注代码”，“为Core做贡献”，“每个人都应该审计代码”。 在发现比特币核心开发者将一个变量名称从 “黑名单 “合并为 “封锁名单 “的那天，所有这些观点一再重复，落到了地球上，甚至没有讨论或承认那个由虚假账户打开的无辜拉动请求是一个社会攻击的事实。 在一大批人在Twitter和GitHub上表现出对该事件的不满后，大多数Core的开发者根本无视大家的担忧，甚至对抱怨的人进行人身攻击。 该事件表明: 比特币核心最终由几个维护者负责，他们决定GitHub存储库1和二进制版本的内容，将由成千上万的人下载; 比特币核心区容易受到社会攻击的影响; “更多的人关注代码"并不重要，因为这些额外的人被忽视和驳回。 解决方案：比特币节点程序去中心化 如果有10种不同的比特币节点口味，比特币网络对单一团队的社会攻击的抵抗力会更强. 这与有多个不同的比特币节点实现是否更好的问题无关，因为这里我们基本上是在谈论同一个软件。 多个团队，每个团队都有自己的发布流程，自己的标志，一些微妙的变化，或者也许根本没有变化，只是为他们的比特币节点口味起了不同的名字，仅此而已。 每一天、每一周、每一个月、每一年，每一种风格都会在自己的分叉上合并所有来自比特币核心的变化。如果有任何可疑的或太左的东西（或者也许是太右的，如果有一个左派的比特币分支），也许他们会发现它而不合并。 这样我们就能保持两个世界的最佳状态：所有的软件开发、错误修复、改进都在Bitcoin Core上进行，其他版本只是复制。如果有一些非共识的变化，其效果是值得商榷的，其中一个口味将合并在他们的分叉和测试，后来其他的–包括核心–也可以复制。另外，我们可以抵御攻击：如果比特币核心区受到攻击，只有10%的网络会被破坏，其他类型的网络是安全的。 运行Bitcoin Knots 第一个紧跟比特币核心的比特币软件的例子是Bitcoin Knots，它是由廉洁的Luke DashJr维护的，增加了一些小变化，但有独立的审核和发布过程。 下次你决定运行bitcoind时，请运行Bitcoin Knots，为bitcoind的去中心化做出贡献! 扩展阅读: Anthony Towns 讨论如何攻击比特币

英文原文 翻译:DeepL, Google Translate; 校对：李林 回顾CTV和ANYPREVOUT之间的关系： 众所周知，尽管CTV和ANYPREVOUT提案的主要应用（CTV的拥堵控制和ANYPREVOUT的eltoo闪电通道）非常不同，但它们的应用有很大程度的重叠。特别是，ANYPREVOUT可以实现CTV的大部分应用，尽管成本更高。CTV的主要功能是允许scriptPubKey对其支出交易的哈希做出承诺，而输入的TXID不在哈希中。这种排除是必要的，因为scriptPubKey被散列到输入的TXID中，包括TXID会导致散列承诺的循环，这是不可能构建的。另一方面，ANYPREVOUT定义了一种签名哈希模式，它同样排除了输入的TXID，以达到其可重新绑定签名的目的。 这意味着ANYPREVOUT可以通过在scriptPubKey里面提交公钥以及ANYPREVOUT签名来模仿CTV的大部分特性。事实上，比特币今天没有契约的唯一原因是由于scriptPubKeys和TXIDs之间的这种循环，这种循环发生在所有sighash模式中。 通过ANYPREVOUT模拟CTV与实际的 CTV提案的主要区别是(1): 模拟CTV的成本。 在CTV中，支出 事务是用32字节的哈希值来提交的，而用ANYPREVOUT来模拟则需要64字节的哈希值。 ANYPREVOUT要求签名有64个字节，有些公钥要32个字节的，有些标志位需要多一些字节，就可以模拟CTV。 通过使用内部公钥（1字节表示）可以减少一些成本，而且，如果我们有CAT，也许可以通过可重用的片段来组装签名（即把签名的nonce设置为等于公钥）。 另一个主要区别是。(2) CTV的交易哈希值包括如交易中的输入数量和它们的序列号。ANYPREVOUT并不包括这些。 CTV的哈希值包含足够的信息，因此当与缺失的TXID结合时，你可以计算出支出交易的TXID。花费交易的TXID。 特别是如果输入的数量被承诺为承诺为1，一旦scriptpubkey的交易ID被知道并提交到到区块链上，其支出交易的TXID是可以推导出来的。 而且如果该交易的输出有CTV承诺，你可以反过来推断它们的支出TXID。 虽然这是一个很好的功能。ANYPREVOUT不能模仿的东西，它的主要应用是它的主要应用被列为使用拥堵控制来资助闪电通道，在它们的TXIDs在它们被放置在链上之前。 然而，如果ANYPREVOUT被用来模仿CTV，那么很可能是eltoo通道会被资助，而且没有必要事先知道eltoo通道的TXIDs来使用它们。为了使用它们，没有必要事先知道eltoo频道的TXID。 另一个提议： 鉴于CTV和ANYPREVOUT之间的功能重叠，我认为将它们的操作分解成各自的组成部分并以编程方式重新组合它们的行为是有意义的。为了这个目的，我提出OP_TXHASH和OP_CHECKSIGFROMSTACKVERIFY。 OP_TXHASH将从堆栈中弹出一个txhash标志，并根据该标志计算出一个（有标签的）txhash，并将得到的hash推到堆栈中。OP_CHECKSIGFROMSTACKVERIFY将从堆栈中弹出一个pubkey、消息和签名，如果签名没有在该消息上验证，则失败。 CTV和TXHASH的功能大致相当。 CTV DROP “可以通过”<ctv_style_flag> TXHASH EQUALVERIFY “来模拟。 反过来也是如此，'<ctv_style_flag> TXHASH’可以通过以下方式被CTV模拟 CTV'，然而，正如你所看到的，从CTV模拟TXHASH要比其他方式昂贵得多，因为产生的32字节哈希结果必须作为见证栈的一部分。 CHECKSIGVERIFY可以通过'<apo_style_flag> TXHASH CHECKSIGFROMSTACKVERIFY’来模拟。 这里我们看到了 将哈希值推到堆栈中。 APO可以被模拟，而不需要在见证数据中包括一份所产生的TXHASH的副本。 除了CTV和ANYPREVOUT应用外，用CHECKSIGFROMSTACKVERIFY，我们可以验证由预言机应用的预言机签名的任意消息的签名。 这就是我们看到将操作分解成原始片段的好处。 通过让用户能够从组件中编程自己的用例，我们可以用更少的操作代码获得更多的应用 一个备选建议：。 注意事项:: 首先，我承认复制CTV和ANYPREVOUT的行为确实比使用定制的目的性建议本身多花了几个字节。 这是我们选择从碎片中编程解决方案的能力时要付出的代价。 但是，我们可以从这些碎片中获得能够建立更多应用的好处。 与CTV不同的是，TXHASH不是NOP兼容的，只能在tapscript中实现。 特别是，在这个建议中，裸露的CTV是不可能的。然而，这个建议并不排除将CTV添加到传统脚本中，同时将TXHASH添加到tapscript中的可能性。 由于类似的原因，TXHASH不适合在以后扩展txflags的集合。 理论上，当遇到未知的标志集时，我们可以让TXHASH中止-成功。 然而，这将使分析tapscript更加困难。这样一来，tapscripts就可以根据脚本片段的组装和执行顺序，以成功或失败的方式中止，而顺序不正确将是灾难性的。 这种行为与目前的一批OP_SUCCESS操作码明显不同，无论它们是否会被执行，只要存在就会成功中止。 我相信升级TXHASH的困难可以通过从一开始就设计一套强大的TXHASH标志来缓解。 例如，有一些位来控制：（1）版本是否被覆盖；（2）锁定时间是否被覆盖；（3）txids是否被覆盖；（4）序列号是否被覆盖；（5）输入量是否被覆盖；（6）输入scriptpubkeys是否被覆盖；（7）输入的数量是否被覆盖；（8）输出量是否被覆盖；（9）输出scriptpubkeys是否被覆盖；（10）输出的数量是否被覆盖。(11) tapbranch被覆盖；(12) tapleaf被覆盖；(13) opseparator值被覆盖；(14) 是否覆盖所有、一个或没有输入；(15) 是否覆盖所有、一个或没有输出；(16) 是否覆盖一个输入位置；(17) 是否覆盖一个输出位置；(18) 是否覆盖sighash标志（注意。注意：是否覆盖了sighash标志，其本身必须被覆盖）。 可能会指定在单一情况下覆盖哪个输入或输出位置，以及该位置是相对于输入的位置还是绝对位置。 综上所述，即使将来需要其他TXHASH标志模式，增加TXHASH2始终是一个选择。 与未来潜在操作码的互动:: 我们应该考虑这些操作码如何与未来的操作码（如CAT、滚动SHA256操作码）互动，或者如何与其他公约操作码对接，这些操作码可能会做一些事情，比如为计算目的直接将输入或输出量推入堆栈，这些操作码已经被添加到Elements项目中。 通过CAT和/或滚动SHA256操作码和/或现有的SHA256操作码，CHECKSIGFROMSTACKVERIFY可以验证以编程方式组装的信息的签名。 另外，结合对TXHASH的多次调用，可以用来创建对交易数据的复杂子集进行承诺的签名。

英文原文 翻译：DeepL，Google Translate，校对: 李林 本周的新闻通讯描述了对提议的OP_CHECKTEMPLATEVERIFY（CTV）操作码对离散日志合约的影响的分析，并总结了对tapscript的替代性修改以实现CTV和SIGHASH_PANYREVOUT的讨论。此外，还包括我们的常规部分，宣布新版本和流行的比特币基础设施软件的显著变化。 新闻 通过改变脚本提高DLC效率。Lloyd Fournier在DLC-Dev和Bitcoin-Dev邮件列表中发布了提议的OP_CHECKTEMPLATEVERIFY (CTV)操作码可以从根本上减少创建某些Discreet Log合约（DLC）所需的签名数量，以及减少其他一些操作的次数 简而言之，对于合同的每个可能的终端状态–例如，Alice得到1个BTC，Bob得到2个BTC–DLC目前需要为该状态创建一个单独的签名适配器。许多合同定义了大量可能的终端状态，比如关于比特币未来价格的合同，它指定了四舍五入的价格，即使是相对短期的合同，也需要覆盖价值几千美元的价格范围。这需要参与者创建、交换和存储成千上万的部分签名。 相反，Fournier建议在一个tapleaf中使用CTV创建数以千计的可能状态，并承诺将输出放在链上。CTV使用哈希值对输出进行承诺，因此各方可以自己快速和按需计算所有可能的状态哈希值，最大限度地减少计算、数据交换和数据存储。仍然需要一些签名，但数量大大减少。在使用多个预言机情况下（例如，汇率合同有多个价格数据提供者），会进一步简化和减少所需的数据量。 Jonas Nick指出，使用提议的SIGHASH_ANYPREVOUT签名哈希模式也可以进行类似的优化（我们会注意到，使用以下新闻中描述的替代方案也可以进行同样的优化）。 CTV和APO的可替代方案：Russell O’Connor 发布到Bitcoin-Dev邮件列表，提出了一个软分叉的想法，为比特币的Tapscript语言添加两个新的操作码。一个tapscript可以使用新的OP_TXHASH操作码来指定一个支出交易的哪些部分应该被序列化和散列，散列的摘要被放在评估堆栈中供以后的操作码使用。一个新的OP_CHECKSIGFROMSTACK(CSFS)操作码（如之前提议的）将允许tapscript指定一个公钥，并要求对堆栈上的特定数据进行相应的签名–比如由OP_TXHASH创建的交易的计算摘要。 O’Connor解释了这两个操作码如何允许仿真两个早期的软分叉提案，SIGHASH_ANYPREVOUT（APO，在BIP118中指定）和OP_CHECKTEMPLATEVERIFY（CTV，在BIP119中指定）。对于某些目的来说，这种模拟可能比直接使用CTV或APO的效率要低，但OP_TXHASH和OP_CSFS会使Tapscript语言更加简单，并为未来的脚本编写者提供更多的灵活性，特别是如果与其他简单的tapscript添加内容相结合，如OP_CAT。 在回复中，Anthony Towns建议使用其他替代操作码的类似方法。 在撰写本摘要时，这些想法仍在积极讨论之中。我们期望在未来的通讯中重新讨论这个话题。 版本和候选版本 BTCPay服务器1.4.2是新的1.4.x系列的最新版本，其中包括登录验证的改进和一些用户界面的改进。 BDK 0.16.0是一个版本，包括一些错误的修复和小的改进。 Eclair 0.7.0是一个新的主要版本，增加了对锚点输出的支持，转发洋葱信息，以及在生产中使用PostgreSQL数据库。 LND 0.14.2-beta.rc1是维护版的候选版本，包括几个bug的修复和一些小的改进。 值得注意的代码和文档变化 本周值得注意的代码变化 Bitcoin Core, C-Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface HWI, Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), 和 Lightning BOLTs. Bitcoin Core #23201提高了钱包用户用外部输入为交易提供资金的能力（之前在通讯#170中提到），允许他们指定最大权重而不是解决数据。这使得应用程序能够使用 fundrawtransaction、send 和 walletfundpsbt RPCs 来对具有非标准输出的收费提升交易，如 HTLCs （在 Newsletter #184 中描述的 LN 客户端的要求）。

英文原文 翻译：DeepL，Google Translate，校对：李林 这篇关于P2SH在比特币上实施的历史的文章有两个宝贵的教训，说明了bitcoind 去中心化的好处: 多个代码库的好处。Russell O’Connor在他的替代比特币软件实现中发现了OP_EVAL的错误。 有限用户管理单一主仓库的危险。Gavin Andresen首先提交了一个破损的OP_EVAL的代码，然后推送了一个邪恶的矿工激活信号机制，默认为他个人喜欢的P2SH版本（要发出相反的信号，矿工就必须编辑代码并重新编译），并在与一个更好、更理智的方法（Luke Jr的OP_CHECKHASHVERIFY）的竞争中，仅靠惯性的力量就赢得了胜利：代码已经合并，而且还在运行所以没有人愿意为一个看似不重要的改进而战斗，但后来被证明是大大的好. 第二个教训实际上可以分成4个不同的教训: 维护者提交了一个bug，但没有人注意到它。 维护者提交了一个邪恶的激活机制。 人都从众，因为很难公开反对一个人人都爱的中心，而且现状是偏见存在，而且很强烈。 现在看起来很好的事情以后可能会变得很糟糕，反之亦然，无论多少专家的 “代码之眼 “都无法解决这个问题。

英文原文 本翻译稿 Github repo 翻译：DeepL，Google Translate 校对： 李林 “推迟两个月。OP_EVAL还没好。” 这正是Gavin Andresen长久努力要避免的判决。随着发自Russell O’Connor键盘的一声斥责，历时数月的比特币升级工作–创始人中本聪退出后的第一次升级–在实施前突然停滞。 正如O’Connor所揭示的，拟议的命令–被Andresen誉为通往更安全的比特币钱包的 “最快路径”–可以被利用来创建交易，使软件在试图验证它们时进入一个无限循环。 简而言之，OP_EVAL可以被滥用，使比特币节点崩溃，从而使比特币网络崩溃。 O’Connor写道：“我花了70分钟的时间才找到这个错误，“他谴责了这个流程：将坏代码合并–并几乎将其推入正在运作的软件。“你们需要停手，真正去了解比特币。” 这是该项目新任负责人Andresen的第一个严重挫折，他迅速提出抗议。在他看来，放弃OP_EVAL不仅会浪费几个月的编码和审查，而且会让用户没有工具来保护他们的数字钱包免受木马和病毒的侵害。 这是OP_EVAL吸引人的核心–简单的多签钱包将允许用户恢复比特币，即使是在备份丢失的情况下；可以建立服务来发送类似银行的警报，阻止欺诈和盗窃；更好的是，这一切都可以在交易中实现，其外观和行为与用户所知道和理解的一样。 但O’Connor的警告之词对那些看到他们对不断升级的发展速度的担忧得到验证的人来说已经足够了。 “我想提醒大家，我们正在搞一个价值2000多万美元的东西，“开发者Alan Reiner会写道。“这不仅仅是一个软件的问题–无论什么东西都需要像钻石一样坚硬。” OP_EVAL的失败还将产生更大的影响。中本聪确实推出了世界上第一个去中心化的数字货币，但它的承诺远未实现。在2011年底，很少有人理解它的代码，更少有人拥有保护它的技能和熟悉程度。 这些开发者应该如何组织？他们对用户有什么责任？在不清楚谁–如果有的话–应该有最终决定权的情况下，他们将如何进行变革？ 这样的问题很快就会在比特币软件的第一场大战中被推到前台。 非正统的继承 自由和开源代码码项目通常由创始人领导，而他们又必须与他们的工作所依赖的贡献者保持一致。不过，在出现方向性争议的时候，他们被赋予了一种天然的权威，作为他们创作的决策人。 比特币，在早期也不例外。在比特币存在的头两年，中本聪扮演着主要开发者和仁慈的独裁者的角色。作为比特币无可争议的领导者，他颁布了多达八项协议变更，而没有形成更广泛的讨论[1]。也就是说，直到他逐渐退出这个项目。 到2010年底，中本聪将把他们的假名从Bitcoin.org网站上抹去，留下资深的三维图形开发人员Gavin Andresen作为项目的 “事实上的领导者”[2]。 Andresen选择的措辞是恰当的，因为围绕这一过渡的情况是不寻常的，相当于一个简短的公共信息，一个私下的职责传递和交换一个允许用户发送全系统警报信息的密钥。 不过，在当时，这对比特币的小规模但不断增长的程序员群体来说没有什么困难。大多数人都关心关键的修复问题，而Andresen，一位终身教授的配偶，有时间和热情来领导这项工作[3]。 的确，有许多迫切的需求–更快的同步，更好的测试–但 “越来越多的钱包被盗报告"和盗贼提交的"烂补丁"迅速成为首要关注的问题。 有一段时间，这是比特币的新贡献者们似乎都同意的目标[4]。 纯多签 幸运的是，中本聪已经提供了一个解决方案的蓝图。正如Andresen所了解的，比特币的代码已经使用户能够创建安全的交易，这些交易只有在用多个私钥签名时才能使用[5]。 有了多重签名，或简称多签，私钥可以存储在多个设备上，在世界的两端，或在一个用户和一个钱包服务之间共享，这意味着黑客必须破坏多个目标才能窃取钱币。 Andresen对这一想法非常着迷，他将成为这一想法的第一个拥护者，在邮件列表中写下了慷慨激昂的请求，以激励贡献者采取行动。 “我最担心的是我们会说，‘当然，只需要几天时间就能就如何做好它达成一致’，而六个月后仍然没有共识，“他写道[6]。“而人们的钱包[[将]继续丢失或被盗。” 这些担忧并不是没有道理的–正如中本聪所实现的那样，多签有很大的缺点。其中最紧迫的是，交易与比特币的标准地址格式不兼容，而需要更长的地址。 正因为如此，为多签钱包提供资金的交易更大，需要更多的费用。更重要的是，这些费用不是由使用多签钱包接收比特币的人支付，而是由向他们发送比特币的人支付。 由于这些次优特性，多签交易在软件中被指定为 “非标准”，意味着它们不一定会传播到网络上的节点。如果一个节点确实收到了多义词交易，它将简单地忽略它。同样，也不能保证矿工会将这些交易纳入区块。 如果它们被包括在内，节点会接受它们（多签交易最终是有效的）。但在实践中，这种指定使得这些交易几乎不可能得到确认。 进入 OP_EVAL 为了释放他所看到的潜力，Andresen将继续倡导一种新的 “操作码”，一种节点可以用来决定新类型的交易是否有效以及何时有效的命令。 OP_EVAL的设计是为了适应更高级的交易，如多签，它在很大程度上依赖于哈希，这种加密技巧可以确定地扰乱和压缩数据，但不可逆地变成一串独特的数字。 假名开发者ByteCoin首先提议，其基本想法是用户可以通过在交易中加入哈希值，来详细说明比特币以后可以花费的条件（包括进出多义词钱包）。币本质上会被发送到一个哈希值。 只有在 “从 “哈希值中花费比特币时，才会显示出后来花费比特币所需的条件。多重签名的用户在花费比特币时将为增加的交易规模付费，而所需的额外数据对网络造成的负担较小。 由于该提案得到了积极的反馈，Andresen没有浪费任何时间，他更倾向于让OP_EVAL尽早部署，而不是拖延。 他写道[7]：“安全问题真的是优先考虑的问题；我希望在一年内看到人们的论坛签名中有安全的比特币地址。 然而，并不是每个人都认同安德烈森的紧迫感。OP_EVAL将是对一个已经具有数百万美元价值的实时系统的一次重大升级。在大洋彼岸，一位年轻的Amir Taaki建议开发人员花时间审查该提案。 “乍一看似乎不错，“Taaki写道[8]。“但快速将其纳入区块链可能不是一个明智的想法……比特币明天不会爆炸，所以在像这样的重大变化上暂缓不会有大的损失。” 使问题更加复杂的是，开发者认为在协议中加入OP_EVAL会带来巨大的协调挑战。从本质上讲，颁布它需要冒区块链的风险，区块链是所有比特币交易的最终记录，由其软件规则的共享共识执行，可能会分裂成不兼容的网络。 这意味着一旦OP_EVAL上线，每个用户都必须切换到一个新的软件版本和一个新的区块链，即所谓的 “硬分叉 “升级。 如果不能统一升级，矿工可能会在不知情的情况下产生 “无效 “区块。更糟糕的是，用户可能在不知情的情况下接受 “无效 “交易。 一种新型的软分叉 然而，很快，Andresen意识到有可能安抚诋毁他的人。

英文原文 翻译：DeepL，Google Translate，校对: 李林 本周的新闻通讯描述了一个扩展PSBT字段的建议，用来花费那些用向合约付款协议构建的输出；并包括我们的常规部分，其中有来自Bitcoin Stack Exchange的顶级帖子的摘要和流行的比特币基础设施项目的显著变化。 新闻 P2C字段的PSBT扩展：Maxim Orlovsky提出了一个新的BIP，为PSBT增加可选的字段，用于花费使用向合约付款（P2C）协议创建的输出，正如之前在Newsletter #37中提到的。P2C允许支出方和接收方就合约文本（或其他任何东西）达成一致，然后创建一个承诺该文本的公钥。付款人随后可以证明，付款人承诺了该文本，并且如果没有接收人的合作，该承诺根本算不出来。简而言之，花钱的人可以向法院或公众证明他们所支付的东西。 然而，为了让接收者随后构建一个签名能花费他们收到的资金，除了他们使用的密钥（该密钥通常是分层确定性密钥串的一部分）之外，他们还需要合同的哈希值。Orlovsky的提议允许将该哈希值添加到PSBT中，以便签名钱包或硬件设备能够产生有效的签名。 Bitcoin Stack Exchange的精选问答 Bitcoin Stack Exchange是Optech贡献者寻找答案的首选，在这上面我们也会花空闲时间来帮助好奇或困惑的用户。在这个月度专题中，我们将重点介绍一些自上次更新以来被投票最多的问题和答案。 是否有办法把一个taproot地址转换成原生隔离见证地址？在一个交易所由于不支持taproot将用户的P2TR（native segwit v1）taproot提款地址改为P2WSH（native segwit v0）地址后，用户问是否有办法要求得到由此产生的v0输出中的比特币。Pieter Wuille指出，这些比特币是无法收回的，因为用户需要找到一个脚本来哈希到P2TR地址中的公钥，这是一个计算上不可行的操作。 Bitcoin 0.3.7 是一个硬分叉？用户BA20D731B5806B1D想知道是什么导致比特币的0.3.7版本被归类为硬分叉。Antoine Poinsot给出了scriptPubKey和scriptSig值的例子，说明在0.3.7对scriptSig+scriptPubKey分开评估的bug修复后，以前无效的签名可以有效。 什么是签名研磨？Murch解释说，ECDSA签名研磨是一个反复签名的过程，直到你得到一个r值在下半区的签名，根据比特币用于ECSDA的序列化格式，会产生一个少1个字节的签名（32字节对33字节）。这种更小的签名带来更低的费用，而且当签名长度是熟知的32字节时，能够更准确的估算费用。 如何避免的链之间的网络冲突默奇解释了节点如何使用P2P消息结构中规定的魔数，以识别它们是否连接到同一网络（主网、测试网、信号网）上的节点。 2021年标准客户端采用了多少BIP？Pieter Wuille链接到Bitcoin Core的BIPs文档，记录了在Bitcoin Core中实现的BIPs。 值得注意的代码和文档变化 本周值得注意的代码变化 Bitcoin Core, C-Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface HWI, Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), 和 Lightning BOLTs. Eclair #2134 默认支持 anchor outputs, 当一笔交易手续费过低时，允许提高手续费费用. 因为anchor outputs-style 需要通过CPFP来实现提高手续费, 用户必须在他们自己的bitcoind钱包里面保存UTXO.

英文原文 翻译：DeepL，Google translate，校对：李林 如果驱动链没有被比特币支持，那么人们的其他选择是: 山寨币。那些想要超级权力（隐私、智能合约、低手续费）的人把他们的份额转移到狗屎币。这没有什么意义，因为即使山寨币有技术，他们也没有基础资金来运用该技术，但这仍然是一个选择。 完全托管和信任的系统。人们可以使用安全性更低的中心化服务，而不是将他们的钱转移到由Drivechain担保的侧链上，并面临各种监管以及被黑客和政府拿下。 联合侧链，与托管系统相同，但有分布式信任，政府的参与可能更少，也可能更多. 不太安全的类似侧链的结构，比如一组固定的实名实体的多签保护的侧链比特币，或者其他区块链中的以持续归零的狗屎币计价的抵押物担保的BTC代币。 企业接管。大银行和巨头公司开始购买所有的币，并通过他们的封闭系统将其中的一部分暴露给普通人。现在所有有意义的活动都发生在这些从一开始就被卖给政府的传统邪恶实体内，而不是像大家所期望的那样有一个开放的网络和自由市场 每当有人反对驱动链而提不出比上面的东西更好的方案时，他们就一直用上面的方案之一或者部分来惩罚比特币玩家。