今週のニュースレターでは、schnorrおよびtaprootの提案に関する議論の説明、以前はOP_CHECKOUTPUTSHASHVERIFYおよびOP_SECURETHEBAGとして知られていた提案の更新の解説、LNのWatchtowerを標準化する提案へのリンク、Bitcoinインフラストラクチャー・プロジェクトの注目すべき変更点をお送りします。

Action items

今週は特になし。

News

  • ● Continued schnorr/taproot discussion: 今週、Russell O’ConnorはBitcoin-Devメーリングリストでスレッドを開始し、オペコードの位置に署名をコミットすることについて前の議論を続けました。それは署名（例 オペコードOP_CHECKSIG、OP_CHECKSIGVERIFYやtapscript’sでの新しいオペコードOP_CHECKSIGADD）を評価することが期待されています。O’Connorは、このコミットメントにより、複数のユーザーからの署名を使用してさまざまな方法でスクリプトを満たすような、複数ブランチのスクリプトを使用する人々にさらなる保護を提供できると主張しています。この保護がなければ、MalloryがブランチBでその署名を実際に使用するときに、MalloryがブランチAに署名するようにボブに依頼することができかねません。既存のオペコードであるOP_CODESEPARATORはそのような状況に対処するのに役立ちますが、よく知られていません。よって本問題に直接対処することで安全性が向上し、tapscriptにOP_CODESEPARATORを含める必要がなくなる可能性があります。

    いくつかの参加者によるIRCの議論に続いて、Anthony Townsは提案された代替案に対して返信しました。それは、この問題の影響を受けやすいスクリプトは、そのブランチを、コードブランチを１つだけ持つような複数のtaprootリーフに分離する必要がある、という内容です。Tapscriptの署名は、実行中のスクリプトに既にコミットされているため、1つのスクリプトに有効な署名を別のスクリプトで使用することはできません。Townsはまた、その位置だけにコミットすることは、再配置された署名に対する保護を保証できない理由を説明しました。彼は優れた保護を提供できると考えている方法を説明しましたが、tapscriptにOP_CODESEPARATORを保持することと比較して、それは特に有用ではないと考えています。

    schnorr関連の別のトピックで、ZmnSCPxjはMuSig署名集約プロトコルをサブグループで安全に使用するという課題について投稿しました。たとえば、ZmnSCPxjのnodelets提案は、アリスとボブが、キーの集約（A、B）を使用して、単一のLNノードを通じて共同で資金を制御できることを示唆しています。それらの共同ノードは、チャーリーのノードへのチャネルを、ここでもMuSig集約((A, B), C) を使用して、開くことができます。ただし、ZmnSCPxjは、先週のニュースレターで説明されているように、Wargnerのアルゴリズムを考えると、これが安全ではない理由を説明しています。また、問題を回避しようとするいくつかの代替スキームも説明しています。

  • ● OP_CHECKTEMPLATEVERIFY (CTV): Newsletter#48で説明されている OP_CHECKOUTPUTSHASHVERIFY（COSHV）とNewsletter#49で言及されているOP_SECURETHEBAGの後継です。Jeremy Rubinにより提案された新しいopcodeは、スクリプトによりファンドが特定の子トランザクションでのみ使用できるようにします。名称変更に加えて、Rubinは提案済みのBIPに詳細を加えて、2020年初にレビューワークショップを開催する予定です（参加を希望する方はこのフォームに記入してください）。

    メーリングリストで、Russell O’Connorは、ビットコイン・スクリプトにて特殊な順序でスタックからデータを引き出すCTVに関する懸念を再表明しました。 これは、再帰的なcovenantsの作成を防ぐためにRubinによって追加されたものです。再帰的なcovenantsとは有限の子孫トランザクションだけに適用されるのではなく、特定のスクリプトから派生したすべての支払に永久に適用されるスクリプト条件のことです。例えば、支払者は、一連のコインの将来の受取人を3つのアドレスのみに制限できます。他のアドレスに対するいかなる支払いも禁止されます。O’Connorの懸念は、ビットコイン・スクリプトのセマンティクスのモデル化を難しくするというCTVの特殊な挙動にフォーカスしているようです。これはO’Connorが以前に取り組んでいたもので、彼が継続的に取り組んでいるSimplicityスクリプト言語に関連があります。

    IRCで、Gregory MaxwellとJeremy RubinはCTVの複数の観点について議論しており、特に提案されたOpcodeが、提案されている簡易なcongestion controlled transactionsとpayment poolsとの利用を困難にすることなく、高度なデザインにより容易に利用できるようにする点にフォーカスしています。また彼らは、Maxwellにより開始された2013年のスレッドの会話の中で暗示された、再帰的Covenentsを使用する不適切な方法に関して、再帰的なCovenantsを作成できないようにすることが本当に必要か、議論しました。

  • ● Proposed watchtower BOLT: Sergi Delgado Seguraは、Lightning-Devメーリングリストに、彼とPatrick McCorryが取り組んでいるBOLTドラフトを投稿しました。Watchtowersは、オフラインになっている可能性のあるLNノードに代わってペナルティ・トランザクションをブロードキャストするサービスです。提案された仕様の目標は、すべてのLN実装に異なるWatchtowerがあるのではなく、すべてのLN実装が任意のWatchtowerと相互運用できるようにすることです。

Notable code and documentation changes

今週のBitcoin Core、C-Lightning、Eclair、LND、 libsecp256k1、ビットコイン改善提案（BIP）、およびLightning BOLTsの注目すべき変更点。

  • ● C-Lightning #3259は、マルチパス支払いを有効にする一環としてBOLTs #643で提案されているpayment secretの実験的サポートを追加します。payment secretは受信者によって生成され、その受信者のBOLT11インボイスに含まれます。支払い者は、暗号化された支払いの一部にこの秘密を含めます。受信者は、秘密が含まれている場合にのみインボイスの入金を受け入れます。こうすることで他のノードが受信者を調べて、以前に使用した支払いハッシュへの追加の支払いを期待しているかどうかを確認することを防ぎます。

  • ● C-Lightning #3268は、デフォルトのネットワークをビットコインテストネットからビットコインメインネットに変更します。また、指定されたファイルで提供される設定ディレクティブを読み込む新しい設定オプションincludeを追加します。