比特币技术周刊丨为什么不推荐使用RFC6979生成Schnorr签名随机数？

写在前面：在本期《比特币技术周刊》中，我们首先讨论有关比特币的最小允许交易规模的问题，然后讨论一些新的技术问题和答案，例如主根输入大小，Mempool 300 MB限制和Schnorr最终产生的问题是问题，最终是比特币软件基础架构上的一些重大更新。

1.关于最小比特币交易规模的讨论

2.从比特币StackExchange中选择问答

问题1.单根签名和三对二签名的taproot输入大小是多少？

通常有两种使用taproot的方法。默认方法是使用密钥路径（pay-to-taproot）使用输出，其行为与p2pk输出类似，不同之处在于它使用schnorr签名和使用bech32编码的相应地址。另一种方法是多重签名。实际上，2-of-3多重签名的使用条件分为三个2-of-2条件：

{{A，B，C}中的2个} =（A AMPLAMPL B）|| （A AMPLAMPL C）|| （B AMPLAMPL C）

假定其中两个密钥是热键，第三个是用于恢复的备份密钥。使用这两个热键的默认设置是使用MuSig聚合到根路径pubkey中。使用备份密钥的其他成本条件存储在树的子叶中。当前有两种变体：一种是备用密钥可以参与MuSig签名，另一种是返回到一种更简单的多签名方案，其中签名是非交互的。

问题2：当比特币交易存储池（内存池）超过300 MB时会发生什么？

每个节点维护一个单独的事务存储池（内存池）。尽管默认值为300 MB，但是每个节点操作员都可以设置自己的值。 mempool限制不适用于序列化数据（这是写入块的内容，您可以在mempool监视器上看到其列表），但与节点上反序列化事务数据的实际存储使用情况有关，并且此存储使用情况取决于平台。当达到节点的minMempoolFeeRate限制时，它将放弃**费率的交易并增加其minMempoolFeeRate 。它将把新的minMempoolFeeRate给对等节点，基本上告诉对方暂时不要转发低于此费用率的交易。请注意，每个节点分别执行此操作，因此具有更大内存池或不同体系结构的节点可能会在不同时间丢弃事务。节点将保留与其自己的钱包相关的交易副本。即使所有其他节点都放弃了交易，交易的发送者和接收者也会保留副本。发送方可以强制其节点丢弃原始事务并发送另一个有冲突的事务以对其进行更新，或者发送方的节点将继续尝试广播该事务，以便最终在拥塞发生后再次在网络上中继该事务。拥塞发生并经历一些延迟之后，该节点将减少其minmempoolferate并开始接受以前拒绝的那些事务。

问题3：为什么不使用RFC6979生成由schnorr签名的随机数？

“有很多原因。首先，RFC6979并不便宜，而且相当复杂。它需要对SHA256压缩函数进行22次调用来计算单个候选随机数。散列速度很快，但实际上相当于对1400个字节进行散列secp256k1具有一个有趣的特性，它的组顺序可以是，它的作用是实例化一个众所周知的PRNG来生成候选随机数随机数，但这对我们来说太昂贵了。非常接近2 ^ 256，因此完全不需要PRNG，单个哈希就足够了，因此复杂度较低，并且时间也恒定。Ed25519使用了一个更简单的替代方法，其中生成了单个SHA512调用A 512位数字。我们的结构不同，但是受此启发，一些变化是：

1. 我们不需要512位哈希和模数缩减，因为曲线阶数接近2 ^ 256，因此我们可以直接使用256位哈希而无需缩减；
2. 我们担心签名者的公钥来自不受信任的输入实现（大多数签名API似乎无法避免这种情况，因为从私钥重新创建公钥会降低性能）。格雷格·麦克斯韦（Greg Maxwell）在密码学邮件列表中讨论了此问题：https://moderncrypto.org/mail-archie/cures/2020/001012.html，并收到DJB和其他人的回复。我们通过在现时生成中包含公钥来解决此问题。
3. 我们正在尝试通过鼓励合成随机数（包括可用的实际随机性）来防御虚假攻击和差分功率分析（DPA）攻击。 RFC6979也具有支持此功能的变体，但是由于我们使用线性派生的私钥（通过BIP32和Taproot） ，因此DPA攻击更难以预防，因此标准解决方案可能不适用 。请在此处查看开发人员讨论帖子：https://lists.linuxfoundation.org/pipermail/bitcoin-de/2020-March/017711.html

（我同意OP的观点，即我们的某些设计选择未在BIP中得到很好的解释）”

3.比特币主要基础设施的更新

1. Bitcoin Core 0.20.0rc2是下一版Bitcoin Core软件的**候选版本。
2. LND 0.10.1-beta.rc2是下一个LND维护版本软件的**候选版本；

1. Bitcoin Core＃18956在要求Windows 7或更高版本的Windows系统上使用API。自2018年10月Bitcoin Core 0.17发行以来，所有版本的发行说明都明确提到使用Windows系统运行核心节点至少是Windows 7或更高版本。
2. 比特币核心编号18861阻止节点响应P2P协议getdata请求，该请求尚未向发出请求的对等方宣布。这可以防止监视节点绕过Bitcoin Core现有的隐私增强行为，即在向每个对等节点（或对等节点组）宣布新交易之前要等待一会儿，从而使每个交易使用不同的’S路径传播跨网络。
3. 比特币核心＃17681允许钱包为BIP32 HD钱包种子获取新地址，即使该种子不再是钱包的活动种子。这样，即使节点正在执行初始sETHdseed下载（例如在新启动的节点上还原钱包备份时），也可以使用sETHdseed （设置HD种子）RPC切换到新的HD种子。更新的代码确保钱包可以从先前从旧HD种子获得的地址中看到任何付款。
4. 比特币核心编号18895使用unbroadcast字段来更新和返回有关unbroadcast个人交易数据的RPC（例如getrawmempool和getmempoolentry ）。此字段指示本地节点的任何对等方是否已请求事务副本（有关广播跟踪的摘要，请参阅第96页，每周报告）。此外，将使用unboadcastcount字段更新getmempoolinfo RPC。为了保护隐私，仅当交易由节点的钱包或sendrawtransaction RPC提交时，才会跟踪交易的广播状态。
5. Bitcoin Core＃18677添加了一个新的--enable-multiprocess generation配置选项，它将在现有bitcoind和bitcoin-qt二进制文件存在时生成其他二进制文件。当前，新二进制文件和旧二进制文件之间的唯一区别是它们的名称。但是，如果PR＃10102被合并，新的二进制文件会将节点，钱包和GUI的功能拆分为单独的可执行文件，并在必要时相互通信。默认情况下，build选项当前处于禁用状态。有关多流程子项目的**文章，请参阅第39周报告。
6. Bitcoin Core＃18594允许bitcoin-cli -getinfo输出以多钱包模式加载的每个钱包的余额。
7. C-Lightning＃3738利用了libwal的PT支持，并为BIP174部分签署的比特币交易（PT）添加了初始支持。用户唯一看到的变化是txprepare RPC返回了交易的PT形式，但是PR在GitHub上进行了标记，目的是为新渠道提供双倍的资金（有关使用PT进行交互式融资交易的讨论，请参见每周第83期）。
8. LND＃4227从各种程序包中删除了原始私钥处理，为硬件钱包签名支持铺平了道路。