/ home / newsletters /
Bitcoin Optech Newsletter #174
今週のニュースレターでは、Discreet Log ContractをLNチャネルに統合する方法についての投稿と、 最近開催されたLN開発者カンファレンスの詳細な要約へのリンク、 Compact Block Filterの追加検証を行うためのアイディアを掲載しています。 また、Bitcoin Core PR Review Clubミーティングのまとめや、 Taprootのアクティベーションの準備についての最後のコラム、 新しいリリースとリリース候補の説明、 人気のあるインフラストラクチャソフトウェアの注目すべき変更点などの恒例のセクションも含まれています。
ニュース
-
● LNを介したDLC: Thibaut Le Guillyは、 DLC-DevメーリングリストでDiscreet Log ContractのLNとの統合に関するスレッドを立ち上げました。 最初の投稿では、(共同でチャネルを運営するアリスとボブのような) 2つの直接のLNピア間のトランザクションにDLCを含めるためのいくつかの可能な構成について説明しています。 また、LNネットワークを介してルーティングされるDLCを作成する際のいくつかの課題についても説明しています。
-
● LN summit 2021のメモ: Olaoluwa Osuntokunは、 最近チューリッヒで開催されたリモートおよび対面式のLN開発者会議の広範な要約を投稿しました。 この要約には、PTLCやマルチシグ用のMuSig2、 eltooなどLNでのTaprootの使用や、 仕様に関する議論をIRCからビデオチャットに移行すること、 現在のBOLT仕様モデルへの変更、オニオンメッセージとOffer、 スタックレスペイメント(ニュースレター #53参照)、 チャネルジャミング攻撃とその様々な緩和策および、 トランポリンルーティングに関するメモが含まれています。
-
● Compact Block Filterの追加検証: Neutrino軽量版には、Compact Block Filterが正しいデータを含まない可能性を検出するヒューリスティックが含まれており、 このヒューリスティックは、Taprootトランザクションを含むtestnetのブロックに対して正しく生成されたフィルターに対して誤ってエラーを報告していました。 この問題について、Neutrinoのソースコードには既にパッチがあてられており、 他のCompact Block Filterの実装には影響はありませんが、 Olaoluwa Osuntokunは問題と次のようなCompact Block Filterの将来の改善の可能性について、 Bitcoin-DevメーリングリストとLND-Devメーリングリストにスレットを立ち上げました:
-
● 新しいフィルター: 軽量クライアントが他のタイプのデータを検索できるように、オプションのフィルター・タイプを追加で作成する。
-
● 新しいP2Pプロトコルメッセージ: ブロックのundoデータを取得するための新しいP2Pプロトコルメッセージを追加する。 ブロックのundoデータには、ブロックで使用された各インプットが参照する以前のアウトプットが含まれており、 これをブロックと組み合わせることで、そのデータからフィルターが作成されたことを完全に検証することができます。 undoデータ自体は、ピア間で不一致が合った場合に、検証することができます。
-
● マルチブロック・フィルター: これにより軽量クライアントがダウンロードする必要のあるデータがさらに削減できます。
-
● コミットされたブロック・フィルター: マイナーに自分のブロックのフィルターにコミットするよう要求することで、 異なるピアによって提供されるフィルターの不一致を監視するためにダウンロードする必要のあるデータ量を削減できます。
-
Bitcoin Core PR Review Club
この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、 重要な質問と回答のいくつかに焦点を当てます。 以下の質問をクリックしてミーティングでの回答の要約を確認してください。
Add ChainstateManager::ProcessTransaction
は、
John NewberyによるPRで、mempoolへの候補としてトランザクションを処理し、
mempoolの一貫性チェックを実行する責務を持つ新しいChainstateManager::ProcessTransaction()
インターフェース関数を追加するものです。
Review Clubでは、mempoolにトランザクションを追加するための現在のインターフェースについて議論しました。
-
cs_main
とは何ですか?なぜcs_main
と呼ばれているのですか?cs_main
は、マルチスレッドでバリデーションステートへのアクセスを同期させるためのmutexです。 実際には、P2Pロジックで使用されるデータなど、非バリデーションデータも保護しています。 複数のコントリビューターがcs_main
の使用を最小限にしたいと考えています。 この変数は、バリデーション機能がmain.cppファイルに格納されていた時に名付けられました。 プレフィックスのcs
はcritical sectionの略です。 ➚ -
現在
AcceptToMemoryPool
を呼び出しているコンポーネントは何ですか? ATMP呼び出しのうち、外部クライアントコードからのものと、内部バリデーションからのものはどれですか?テストからの呼び出しを除くと、4つの呼び出しサイトがあります:
- ノードが起動すると、mempool.datからトランザクションをロードし、 ATMPを呼び出してトランザクションを再検証し、mempoolの内容を復元します。 これは内部のバリデーション呼び出しです。
- P2Pネットワーク上のピアから受信したトランザクションは、ATMPを通して検証され、mempoolに送信されます。 この呼び出しは、バリデーションの外部コンポーネントから発生します。
- 再編成の際、切断されたブロックには存在するものの、新しいチェーンの先頭には含まれていないトランザクションは、 ATMPを使用してmempoolに再送信されます。これは、内部のバリデーション呼び出しです。
- RPC (例:
sendrawtransaction
)やウォレット(例:sendtoaddress
)などのクライアントは、 ATMPを呼び出すBroadcastTransaction()
を使用して、ノードにトランザクションを送信します。testmempoolaccept
RPCは、test_accept
をtrue
にセットしてATMPを呼び出します。 これらはバリデーションの外部のコンポーネントからの呼び出しの例です。 ➚
-
CTxMemPool::check()
は何をするものですか?また、その関数呼び出すのは誰の責務ですか?CTxMemPool::check()
は、すべてのトランザクションのインプットが利用可能なUTXOに対応することをチェックし、 mempool全体の内部的な一貫性チェックを実行します。例えば、キャッシュされたancestorsize
やancestorcount
、descendantsize
、descendantcount
の値が正確か確認するために、 各mempoolエントリーの祖先と子孫の数を数えます。現在、ATMPの呼び出し側は、 その後でcheck()
を呼び出す責任があります。しかし、参加者の間では、ChainstateManager
が責任を持って自身で内部的な一貫性チェックを行うべきだと議論されました。 ➚ -
bypass_limits
引数は何をするものですか?これがtrueにセットされた状態でATMPが呼び出されるのはどんな状況ですか?bypass_limits
がtrueの場合、mempoolの最大サイズと最小手数料率は適用されません。 例えば、mempoolがいっぱいで、mempoolの動的な最小手数料率が3 sat/vBの場合、 手数料率が1 sat/vBの個々のトランザクションも受け入れられるでしょう。 ATMPは、再編成中にbypass_limits
を使って呼び出されます。 これらのトランザクションは個々の手数料率が低くても、子孫の手数料率が高い場合があります。 mempoolに再追加するトランザクションの合計サイズは、MAX_DISCONNECTED_TX_POOL_SIZE
または20MBに制限されています。 ➚
Taprootの準備 #21: ありがとう!
ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズの最終回をお届けします。
Taprootは、このコラムが公開されてから数日後になると思われるブロック709,632でアクティベートされます。 このシリーズの最終回として、Taprootの開発とアクティベートに協力してくださった多くの方々に、 そして間もなく適用を開始する方々に感謝します。 以下に記載されていない多くの方々にも感謝の意を表したいと思いますが、 記載漏れがあったらお詫びします。
Bitcoin-devメーリングリストでの議論
Taprootの背後にある重要なアイディアは、2019年1月22日の朝、数人の暗号学者による会議で誕生しました。 それは同じ日のうちにBitcoin-Devメーリングリストに投稿されました。 以下の人々は、”taproot”という名前を含むスレッドに貢献しました。
Adam Back, Andrea Barontini, Andreas Schildbach, Andrew Chow, Andrew Poelstra, Anthony Towns, Antoine Riard, Ariel Lorenzo-Luaces, Aymeric Vitte, Ben Carman, Ben Woosley, Billy Tetrud, BitcoinMechanic, Bryan Bishop, Carlo Spiller, Chris Belcher, Christopher Allen, Clark Moody, Claus Ehrenberg, Craig Raw, Damian Mee, Daniel Edgecumbe, David A. Harding, DA Williamson, Elichai Turkel, Emil Pfeffer, Eoin McQuinn, Eric Voskuil, Erik Aronesty, Felipe Micaroni Lalli, Giacomo Caironi, Gregory Maxwell, Greg Sanders, Jay Berg, Jeremy Rubin, John Newbery, Johnson Lau, Jonas Nick, Karl-Johan Alm, Keagan McClelland, Lloyd Fournier, Luke Dashjr, Luke Kenneth Casson Leighton, Mark Friedenbach, Martin Schwarz, Matt Corallo, Matt Hill, Michael Folkson, Natanael, Oleg Andreev, Pavol Rusnak, Pieter Wuille, Prayank, R E Broadley, Riccardo Casatta, Robert Spigler, Ruben Somsen, Russell O’Connor, Rusty Russell, Ryan Grant, Salvatore Ingala, Samson Mow, Sjors Provoost, Steve Lee, Tamas Blummer, Thomas Hartman, Tim Ruffing, Vincent Truong, vjudeu, yancy, yanmaani—, and ZmnSCPxj.
しかし、Schnorr署名やMASTなどTaprootに含まれているアイディアの多くは、 Taprootより何年も何十年も前から存在しています。これらのアイディアに貢献した多くの人々を列挙することはできませんが、 それでも私たちは彼らに感謝しています。
Taproot BIPのレビュー
2019年11月から、多くのユーザーと開発者がTaprootと関連する開発の組織的なレビューに参加しました。
achow101, afk11, aj, alec, amiti, _andrewtoth, andytoshi, ariard, arik, b10c, belcher, bjarnem, BlueMatt, bsm1175321, cdecker, chm-diederichs, Chris_Stewart_5, cle1408, CubicEarth, Day, ddustin, devrandom, digi_james, dr-orlovsky, dustinwinski, elichai2, evoskuil, fanquake, felixweis, fjahr, ghost43, ghosthell, gmaxwell, harding, hebasto, instagibbs, jeremyrubin, jnewbery, jonatack, justinmoon, kabaum, kanzure, luke-jr, maaku, mattleon, michaelfolkson, midnight, mol, Moller40, moneyball, murch, nickler, nothingmuch, orfeas, pinheadmz, pizzafrank13, potatoe_face, pyskell, pyskl, queip, r251d, raj_149, real_or_random, robert_spigler, roconnor, sanket1729, schmidty, sipa, soju, sosthene, stortz, taky, t-bast, theStack, Tibo, waxwing, xoyi-, and ZmnSCPxj.
GitHubのプルリクエスト
Bitcoin CoreにおけるTaprootの主な実装は、レビューのため2020年1月に2つの プルリクエストが提出されました。 それらのPRにGithubでレビューを残したのは以下の方々です。
Andrew Chow (achow101), Anthony Towns (ajtowns), Antoine Riard (ariard), Ben Carman (benthecarman), Ben Woosley (Empact), Bram (brmdbr), Cory Fields (theuni), Dmitry Petukhov (dgpv), Elichai Turkel (elichai), Fabian Jahr (fjahr), Andreas Flack (flack), Gregory Maxwell (gmaxwell), Gregory Sanders (instagibbs), James O’Beirne (jamesob), Janus Troelsen (ysangkok), Jeremy Rubin (JeremyRubin), João Barbosa (promag), John Newbery (jnewbery), Jon Atack (jonatack), Jonathan Underwood (junderw), Kalle Alm (kallewoof), Kanon (decryp2kanon), kiminuo, Luke Dashjr (luke-jr), Marco Falke (MarcoFalke), Martin Habovštiak (Kixunil), Matthew Zipkin (pinheadmz), Max Hillebrand (MaxHillebrand), Michael Folkson (michaelfolkson), Michael Ford (fanquake), Adam Ficsor (nopara73), Pieter Wuille (sipa) Sjors Provoost (Sjors), Steve Huguenin-Elie (StEvUgnIn), Tim Ruffing (real-or-random), and Yan Pritzker (skwp).
これには、Bitcoin Coreに関連するいくつかのPRや、(Bitcoin Coreで使用される) libsecp256k1のSchnorrサポートや代替ノードソフトウェアなど、他のソフトウェアのTaprootの実装作業は含まれていません。
Taprootアクティベーションの議論
Taprootの実装がBitcoin Coreにマージされてから、それをどのようにアクティベートするかを決めるのはコミュニティの役目でした。 数ヶ月に及ぶ議論が行われましたが、その中で最も活発だったのは、 taproot activation IRCチャンネルでの以下のユーザー、開発者およびマイナー間の会話でした:
6102bitcoin, AaronvanW, achow101, aj, alec, Alexandre_Chery, Alistair_Mann, amiti, andrewtoth, andytoshi, AnthonyRonning, ariel25, arturogoosnargh, AsILayHodling, averagepleb, bcman, belcher, benthecarman, Billy, bitcoinaire, bitentrepreneur, bitsharp, bjarnem, blk014, BlueMatt, bobazY, brg444, btcactivator, btcbb, cato, catwith1hat, cguida, CodeShark__, conman, copumpkin, Crash78, criley, CriptoLuis, CubicEarth, darbsllim, darosior, Day, DeanGuss, DeanWeen, debit, Decentralizedb, devrandom, DigDug, dome, dr_orlovsky, duringo, dustinwinski, eeb77f71f26eee, eidnrf, elector, elichai2, Emcy, emzy, entropy5000, eoin, epson121, erijon, eris, evankaloudis, faketoshi, fanquake, fedorafan, felixweis, fiach_dubh, fjahr, friendly_arthrop, GeraldineG, gevs, gg34, ghost43, ghosthell, giaki3003, gloved, gmaxwell, graeme1, GreenmanPGI, gr-g, GVac, gwillen, gwj, gz12, gz77, h4shcash, harding, hebasto, hiro8, Hotmetal, hsjoberg, huesal, instagibbs, Ironhelix, IT4Crypto, ja, jaenu, JanB, jeremyrubin, jimmy53, jnewbery, jonatack, jonny100051, jtimon, kallewoof, kanon, kanzure, Kappa, keblek, ksedgwic, landeau, lucasmoten, luke-jr, maaku, Majes, maybehuman, mblackmblack, mcm-mike, Memesan, michaelfolkson, midnight, MikeMarzig, mips, mol, molz, moneyball, mrb07r0, MrHodl, murch, naribia, newNickName, nickler, nikitis, NoDeal, norisgOG, nothingmuch, occupier, OP_NOP, OtahMachi, p0x, pinheadmz, PinkElephant, pox, prayank, prepaid, proofofkeags, provoostenator, prusnak, qubenix, queip, r251d, rabidus, Raincloud, raj, RamiDz94, real_or_random, rgrant, riclas, roasbeef, robert_spigler, rocket_fuel, roconnor, rovdi, rubikputer, RusAlex, rusty, sanket1729, satosaurian, schmidty, sdaftuar, setpill, shesek, shinobiusmonk, snash779, solairis, somethinsomethin, stortz, sturles, sugarpuff, taPrOOteD, TechMiX, TheDiktator, thomasb06, tiagocs, tomados, tonysanak, TristanLamonica, UltrA1, V1Technology, vanity, viaj3ro, Victorsueca, virtu, walletscrutiny, wangchun, warren, waxwing, Whatisthis, whuha, willcl_ark, WilliamSantiago, windsok, wumpus, xxxxbtcking, yanmaani, yevaud, ygrtiugf, Yoghurt11411, zmnscpxj, and zndtoshi.
マイナーのシグナリング
また、ブロック681,408以降、Taprootのルールを適用する用意があることを表明してくれたすべてのマイナーに感謝します。
サイドプロジェクト
Taprootのアクティベーションは始まりに過ぎません。 今後は、開発者やユーザーが利用可能になった新しい機能を使い始めることになります。 MuSigや他のプロジェクトなど、何年も前から準備してきた人もいます。 そのような開発者のリストを入手する便利な方法はありませんが、いずれにしてもすべての開発者に感謝しています。
ノードオペレーター
最も重要なことは、Bitcoin Core 0.21.1以降(または互換性のあるソフトウェア)にアップグレードした 数千のBitcoinの完全な検証ノードのオペレーターに感謝することです。 彼らは、支払いを受け取るためにそのノードを使用し、 ブロック709,632から始まるTaprootのルールに従うブロックのトランザクションのみを受け入れることを保証します。 これにより、他のすべてのBitcoinユーザーにもTaprootに準拠したブロックのみを受け入れるという経済的なインセンティブが働き、 誰もがTaprootの機能を安全に利用できるようになります。
リリースとリリース候補
人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。
-
● BTCPay Server 1.3.3は、 LNノードを共有している共有サーバー上のインスタンスに対する重要なセキュリティパッチを含むリリースです。 また、小さな機能やその他のバグ修正も含まれています。
-
● Rust-Lightning 0.0.103は、いくつかの経路が失敗した際に支払いをリトライする
InvoicePayer
APIを追加したリリースです。 -
● C-Lightning 0.10.2は、経済合理性のないアウトプットのセキュリティ問題の修正、 データベースサイズの縮小、
pay
コマンドの有効性の向上が含まれたリリースです。 -
● LND 0.13.4-betaは、ニュースセクションで説明したNeutrinoのバグを修正したメンテナンスリリースです。 リリースノートには「Neutrinoの本番環境で実行している場合、ノードがチェーンの中で前進することを保証するために、 Taprootのアクティベーション前にこのバージョンにアップデートすることを強く推奨します。」と記載されています。
-
● LND 0.14.0-beta.rc3は、エクリプス攻撃対策の追加 (ニュースレター #164参照)、リモートデータベースのサポート(ニュースレター #157参照)、 経路探索の高速化(ニュースレター #170参照)、 Lightning Poolユーザー向けの改善(ニュースレター #172参照)、 再利用可能なAMPインボイス(ニュースレター #173参照)および、 他の多くの機能やバグ修正が含まれたリリース候補です。
注目すべきコードとドキュメントの変更
今週のBitcoin Core、 C-Lightning、Eclair、LND、 Rust-Lightning、libsecp256k1、 Hardware Wallet Interface (HWI)、 Rust Bitcoin、BTCPay Server、 BDK、Bitcoin Improvement Proposals(BIP)、および Lightning BOLTsの注目すべき変更点。
-
● Rust-Lightning #1078では、BOLTs #880で定義されニュースレター #165で取り上げられた
channel_type
ネゴシエーションを追加しています。この実装では、 BOLTs #906で提案されているfeature bitは現在のところ送信されません。 BOLTs #880はAnchor Channelに必要で、 ゼロ承認チャネルをサポートするのにも必要かもしれません。 -
● Rust-Lightning #1144は、ルートのスコアリングロジックにペナルティの仕組みを追加しました。 このペナルティは、支払いの再試行中に失敗したチャネルに適用され、 経路選択アルゴリズムに潜在的に欠陥のあるチャネルを知らせます。
-
● BIPs #1215は、BIP119のOP_CHECKTEMPLATEVERIFYの提案をいくつか更新しました:
- ソフトフォークはTaprootのアクティベーションと同様に、 Speedy Trialによるアクチベーションを使ってデプロイされることを明記しました。
- 非タグ付きSHA256ハッシュを使用することの根拠を文書化しました。
- OP_CHECKTEMPLATEVERIFYの提案とSIGHASH_ANYPREVOUTの提案の比較を追加しました。
- OP_CHECKTEMPLATEVERIFYと潜在的な他の将来のコンセンサスの変更との間の相互作用を説明しました。