en | ja | es | cs | hi | zh | de | fr

Bitcoin Optech Newsletter #290

Feb 21, 2024

今週のニュースレターでは、DNSベースの人が読めるBitcoin支払い指示を提供するための提案と、 mempoolのインセンティブ互換性に関するアイディアを含む投稿の要約、 Cashuおよびecashシステムの設計について議論するスレッドのリンク、 Bitcoinスクリプトの64-bit演算に関する継続的な議論（以前提案されたopcodeの仕様を含む）、改良された再現可能なASMapの作成プロセスの概要を掲載しています。また、クライアントとサービスのアップデートや、新しいリリースとリリース候補、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など恒例のセクションも含まれています。

ニュース

● DNSベースの人が読めるBitcoin支払いの指示: 以前の議論（ニュースレター #278参照）に続き、 Matt Coralloは、example@example.comのような文字列をexample.user._bitcoin-payment.example.com のようなDNSアドレスに解決できるようにするドラフトBIPをDelving Bitcoinに投稿しました。これは、bitcoin:bc1qexampleaddress0123456のようなBIP21 URIを含むDNSSEC署名付きのTXTレコードを返します。 BIP21 URIは、複数のプロトコルをサポートするよう拡張することができます（ BIP70ペイメントプロトコルを参照）。たとえば、以下のTXTレコードは、単純なオンチェーンウォレットがフォールバックとして使用するbech32mアドレス、サイレントペイメントプロトコルをサポートするオンチェーンウォレットで使用するサイレントペイメントアドレス、 LN対応ウォレットで使用するLNオファーを示すことができます:
```
bitcoin:bc1qexampleaddress0123456?sp=sp1qexampleaddressforsilentpayments0123456&b12=lno1qexampleblindedpathforanoffer...
```
サポートされているさまざまなペイメントプロトコルの詳細は、ドラフトBIPでは定義されていません。 Coralloは他にLNノードに関連する詳細を記述するための2つのドラフトを作成しており、 1つはBOLTで、もう1つはBLIPです。 BOLTでは、ドメインの所有者がomlookup（onion messageルックアップ）のパラメーターと特定のLNノードへのブラインドパスを含むBIP21 URIを解決する *.user._bitcoin-payment.example.comのようなワイルドカードレコードを設定できるようにします。 example@example.comにオファーを作成したい支払人は、マルチユーザーノードが正しく支払いを処理できるように、受信者の部分（example）をそのLNノードに渡します。 BLIPでは、任意のLNノードがLNの通信プロトコルを介して他のノードへの支払い指示を安全に解決できるようにするオプションについて記述しています。

この記事の執筆時点では、この提案に関する議論の大半はBIPリポジトリのPRで確認できました。 1つの提案は多くのWeb開発者にとってアクセスしやすいHTTPSソリューションを使用することでしたが、追加の依存関係が必要になります。Coralloは、仕様のこの部分は変更しないと述べましたが、 Web開発者向けにすべての作業を行うデモWebサイトを備えた小さなライブラリを作成しました。もう1つの提案は、Electrumなどの一部のBitcoinソフトウェアで既にサポートされている既存の OpenAlias DNSベースの支払いアドレス解決システムを使用するというものでした。 3つめに多く議論されたトピックは、アドレスをどのように表示するかということでした。たとえば、example@example.com、@example@example.com、example$example.comなど。
● mempoolのインセンティブ互換性について考える: Suhas Daftuarは、フルノードがどのトランザクションを自分のmempoolに受け入れ、他のノードにリレーし、最大の収益を得るためにマイニングするかを選択するために使用できる基準に関するいくつかの洞察を Delving Bitcoinに投稿しました。投稿は、最初に原則から始まり、Bitcoin Coreのトランザクションリレーポリシーの設計に興味がある人なら誰でも理解しやすい親しみやすい記述で、現在の研究の最先端へと進んでいます。私たちが最も興味深いと感じた洞察は、次のようなものです:
- ● 手数料率による純粋な置き換えは、インセンティブの互換性を保証するものではない: 手数料率の低いトランザクションを手数料率の高いトランザクションに置き換えることは、マイナーにとって厳密な勝利のように思われます。 Daftuarは、必ずしもそうではない理由を示す簡単な例を示しています。手数料率による純粋な置換に関するこれまでに議論については、ニュースレター #288をご覧ください。
- ● 異なるハッシュレートを持つマイナーの優先順位は異なる: ネットワークの総ハッシュレートの1%を持つマイナーが、ブロックテンプレートに特定のトランザクションを含めることを見送り、次のブロックを見つけることができても、そのトランザクションを含む可能性のあるすぐ後続のブロックをマイニングできる確率は1%のみです。このため、小規模のマイナーは、将来のブロックのマイナー（自分の可能性もある）が得られる手数料の額が大幅に減少することになるとしても、今できる限り多くの手数料を集めることが強く奨励されます。
  
  それと比較して、ネットワークの総ハッシュレートの25%を持つマイナーが、次のブロックにトランザクションを含めるのを見送った場合、そのトランザクションを含む直後の後続ブロックをマイニングする確率は25%になります。この大規模なマイナーは、将来的に得られる手数料が大幅に増加する可能性がある場合、今すぐに一部の手数料を徴収することを回避するインセンティブが働きます。
  
  Daftuarは、2つの競合するトランザクションの例を示しています。小さなトランザクションでは高手数料率の手数料を支払い、大きなトランザクションは支払われる金額がより高くなっています。大きなトランザクションの手数料率に近いトランザクションがmempoolにあまり無い場合、（手数料率がより高い）小さなトランザクションを含むブロックよりも、大きなトランザクションを含むブロックがより多くの手数料をマイナーに支払うことになります。しかし、大きなトランザクションと同様の手数料率のトランザクションがmempoolに多数ある場合、ネットワークの総ハッシュレートに占める割合が小さいマイナーは、（手数料率の高い）小さい方をマイニングして今すぐ多くの手数料を得ようとし、総ハッシュレートに占める割合が大きいマイナーは、（手数料率の低い）大きなトランザクションをマイニングして利益がでるまで（または、支払人が待つのにうんざりしてより手数料率の高いバージョンを作成するまで）待とうとするかもしれません。マイナーごとにインセンティブが異なるということは、インセンティブの互換性に関する普遍的なポリシーがないことを意味している可能性があります。
- ● DoS攻撃に抵抗できないインセンティブ互換動作を見つけることは有用: Daftuarは、Bitcoin Coreプロジェクトがインセンティブ互換性があり、 DoS（Denial-of-Service）攻撃に耐性のあるポリシーをどのように実装しようとしているか説明しています。しかし、彼は次のように述べています。「興味深く価値のある研究分野は、ネットワーク全体に展開するのにDoS耐性がないインセンティブ互換性のある動作があるかどうかを判断すること（そして、存在する場合はその特性を明らかにすること）です。もし、そのような動作があれば、それはユーザーがマイナーと直接繋がるインセンティブを導入する可能性があり、それらの当事者にとっては相互に有益である可能性がありますが、ネットワーク全体でのマイニングの分散化には有害である可能性があります。[…] これらのシナリオを理解することは、DoS耐性のあるインセンティブ互換性のあるプロトコルを設計しようとする際にも役立つ可能性があるため、可能性の境界がどこにあるのかを知ることができます。」
● Cashuおよびその他のecashシステム設計の議論: 数週間前、開発者のThunderbiscuitは、残高をsatoshiで表示しBitcoinとLNを使用して資金を送受信できる Cashuで使用されているChaumian ecashシステムの背後にあるブラインド署名スキームの説明をDelving Bitcoinに投稿しました。開発者のMoonsettlerとZmnscpxjは今週、ブラインド署名の簡易版のいくつかの制約と、代替プロトコルがどのように追加の利点を提供できる可能性があるかについて話しました。この議論は完全に理論的なものでしたが、ecashスタイルのシステムに興味がある人にとっては興味深い内容だと思います。
● 64-bit演算とOP_INOUT_AMOUNT opcodeの継続的な議論: Bitcoinに64-bit演算を追加する将来のソフトフォーク（ニュースレター #285参照）の可能性について、複数の開発者が議論を続けています。私たちが以前言及して以来、ほとんどの議論は、スクリプトで64-bitの値をエンコードする方法にフォーカスし続けており、主な違いは、オンチェーンデータを最小化する形式を使用するか、プログラムで操作するのが最も簡単な形式を使用するかの違いです。また、符号付き整数を使用するか、符号なし整数のみを許可するかについても議論されました（知らない方のために説明すると、自称高度なBitcoinイノベーターも含まれるようですが、符号付き整数は使用する符号を示し（正の符号か負の符号か）、符号なし整数はゼロと正数のみを表現できます）。さらに、最大4,160 bit（現在のBitcoinのスタック要素のサイズ制限である520 byteと一致）までの、より大きな数値の操作を許可するかどうかについても検討されました。

今週、Chris Stewartは、当初OP_TAPLEAF_UPDATE_VERIFYの一部として提案されたopcode（ニュースレター #166参照）のドラフトBIPに関する新しい議論のスレッドを作成しました。OP_INOUT_AMOUNTというopcodeは、現在のインプットの値（使用するアウトプットの値）と、このインプットと同じインデックスのトランザクションアウトプットの値をスタックにプッシュします。たとえば、トランザクションの最初のインプットが400万satsで、２つめのインプットが300万sats、最初のアウトプットに200万sats支払い、２つめのアウトプットに100万sats支払う場合、２つめのインプットの評価の一部としてOP_INOUT_AMOUNTが実行されると、 3_000_000 1_000_000がスタックに配置されます（ドラフトBIPを正しく理解していれば、 64-bitのリトルエンディアンの符号なし整数としてエンコードされます。例：0xc0c62d0000000000 0x40420f0000000000）。 opcodeがソフトフォークでBitcoinに追加された場合、コントラクトは、インプットの量とアウトプットの量がコントラクトが期待する範囲内であること検証するのがはるかに簡単になります。たとえば、ユーザーが権利のある金額だけをJoinpoolから引き出すようなことの検証など。
● 再現可能なASMap作成プロセスの改良: Fabian Jahrは、インターネットの大部分のルーティングをそれぞれが制御する自律システムのマップ（ASMap）の作成における進捗について、Delving Bitcoinに投稿しました。 Bitcoin Coreは現在、グローバルなネームスペースの多様なサブセットのコレクションからピアへの接続を維持しようとしているため、攻撃者がノードに対して最も単純なタイプのエクリプス攻撃を実行するためには、各サブネットでIPアドレスを取得する必要があります。ただ、一部のISPやホスティングサービスは、複数のサブネット上のIPアドレスを制御しており、この保護が弱くなっています。 ASMapプロジェクトの目的は、どのISPがどのIPアドレスを管理しているかというおおよその情報を Bitcoin Coreに提供することです（ニュースレター#52および#83参照）。このプロジェクトが直面している大きな課題は、複数のコントリビューターが再現可能な方法でマップを作成し、その内容が作成された時点で正確であったことを独立して検証できるようにすることです。

今週の投稿で、Jahrはツールと手法について説明し、次のように述べています。「5人以上のグループ内では、大多数の参加者が同じ結果を得る可能性が高いことが分かりました。[…] このプロセスは誰でも開始でき、CoreのPRとよく似ています。合致する結果を持つ参加者は、ACKとして解釈される可能性があります。誰かが結果におかしなものを見つけた場合、または単純に合致しなかった場合は、さらに調査するために生データの共有を求めることができます。」

最終的にプロセスが許容できると判断された場合（おそらく追加の改良が加えられた上で）、 Bitcoin Coreの将来のバージョンには、ASMapが搭載され、この機能がデフォルトで有効になり、エクリプス攻撃に対する耐性が向上する可能性があります。

サービスとクライアントソフトウェアの変更

この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。

● マルチパーティ調整プロトコルNWCの発表: Nostr Wallet Connect (NWC)は、複数の参加者が関与する対話型のユースケースでの通信を容易にする調整プロトコルです。 NWCの初期の焦点はライトニングですが、JoinpoolやArk、 DLC、マルチシグスキームなどの対話型のプロトコルが、このプロトコルの恩恵を受ける可能性があります。
● Mutiny Wallet v0.5.7リリース: Mutiny Walletのリリースでは、Payjoinのサポートが追加され、 NWCやLSPの機能が改善されています。
● GroupHugトランザクションバッチサービス: GroupHugは、PSBTを使用する制限のあるバッチサービスです。
● BoltzがTaprootスワップを発表: ノンカストディアルのスワップ取引所Boltzは、TaprootやSchnorr署名、 MuSig2を使用するようアップグレードしたアトミックスワッププロトコルを発表しました。

リリースとリリース候補

人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。

● Core Lightning 24.02rc1は、この人気のLNノードの次期メジャーバージョンのリリース候補です。

注目すべきコードとドキュメントの変更

今週のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIP）、Lightning BOLTs、 Bitcoin InquisitionおよびBINANAsの注目すべき変更点。

● Bitcoin Core #27877は、Bitcoin Coreのウォレットに新しいコイン選択戦略 CoinGrinder（ニュースレター #283参照）を追加しました。この戦略は、推定手数料率が長期的なベースラインと比較して高い場合に使用されることを意図しており、ウォレットが今すぐ小さなトランザクションを作成できるようにします（その結果、後日、手数料率が低くなった時に、より大きなトランザクションを作成する必要が生じる可能性があります）。
● BOLTs #851では、対話型のトランザクション構築プロトコルのサポートと共に、 LNの仕様にデュアルファンディングのサポートを追加しました。対話型の構築により、２つのノードが設定とUTXOの詳細を交換し、ファンディングトランザクションを一緒に構築できるようになります。デュアルファンディングにより、トランザクションにどちらか一方もしくは両者のインプットを含めることができます。たとえば、アリスがボブとチャネルを開きたい場合、この仕様変更の前は、アリスはチャネルの資金をすべて提供する必要がありました。現在は、デュアルファンディングをサポートする実装を使用すると、アリスはチャネルの初期状態にボブがすべての資金を提供したり、両者が資金を提供するチャネルを開くことができます。これは、まだ仕様に追加されていない実験的なLiquidity Adsプロトコルと組み合わせることができます。