今週のニュースレターでは、頻繁にオフラインになるLNノードへの支払いに関するスドレッドや、 特定の攻撃をより高価にするめにLNの支払い経路の正確な調査のコストを下げる提案、 signetやtestnetでTaprootトランザクションを作成する際に役立つ方法のリンクを掲載しています。 また、クライアントやサービスの最近の変更や、新しいリリースおよびリリース候補、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点などの恒例のセクションも含まれています。

ニュース

  • ● オフラインのLNノードへの支払い: Matt Coralloは、頻繁にオフラインになるLNノード（モバイルデバイスなど）が、 カストディ型ソリューションを必要とせず、 また長期間チャネルの流動性をロックすることなく支払いを受け取れるようにする方法についてのブレインストーミングを Lightning-Devメーリングリスト上のスレッドで開始しました。 Coralloは、LNがPTLCをサポートするようアップグレードされれば、 信頼できない第三者を含む合理的なソリューションがあると考えていますが、 PTLCのサポートが追加される前でも展開可能な代替ソリューションの提案も求めています。

  • ● 正確な調査のコストを下げ、攻撃をより高価にする: 数週間にわたって、開発者のZmnSCPxjとJoost Jagerはそれぞれ、 支払い経路を調査するために資本をロックアップする必要をなくすという、 実質的に同様の提案をしました。 どちらの提案も、支払いの試行が失敗しても送信者にお金がかかる、 前払いのルーティング手数料をネットワークに追加するための最初のステップとしてこれを提案しています。 前払い手数料は、チャネル・ジャミング攻撃の緩和策の1つとして提案されています。

    現在、LNノードは支払い経路を調査するために必ず失敗する支払いを送信することができます。 例えば、アリスは誰も知らないプリイメージへ支払うHTLCを生成したとしましょう。 彼女はその支払いをボブとチャーリーを介してゼッドにルーティングします。 ゼッドはプリイメージを知らないため、最終的な受信者が自分であることを示しているにも関わらず、 支払いを拒否せざるを得ません。アリスはゼッドのノードから拒否のメッセージを受信した場合、 ボブとチャーリーがゼッドへの支払いを可能にするだけの資金を持っていることを知ることができるので、 高い確率で成功する実際の支払いを送信することでゼッドの拒否にすぐに反応できます（流動性に関連する失敗の唯一の理由は、 ボブもしくはチャーリーの残高がその間に変更された場合です）。 必ず失敗する支払いから開始するアリスのメリットは、複数の経路を並行して調査し、 最初に成功した経路を使用することで、全体的な支払い時間が短縮できます。 主なデメリットは、各支払いの調査で、アリスとボブやチャーリーのような中間ノードが保持する資金を一時的にロックすることです。 アリスが複数の長い経路を並行して調査している場合、彼女は支払額の100倍以上をロックしている可能性があります。 2つめのデメリットは、この種の支払い経路の調査により、不必要な一方的なチャネル閉鎖と、 その結果生じるオンチェーン手数料です。

    ZmnSCPxjとJagerは、HTLCの使用やビットコインの一時的なロック、 チャネル障害のリスクを必要としない特別な調査メッセージの送信を可能にすることを提案しています。 ZmnSCPxjの提案は、サービス拒否のFlood攻撃を避けるためのいくつかの緩和策を提案していますが、 メッセージは基本的に無料で送信できます。

    無料の調査により、支払いノードが高い割合で信頼できる経路を見つけることが実際にできるようになれば、 ZmnSCPxjとJagerは、開発者とユーザーは、 支払いが失敗する稀なケースでは、ユーザーのコストになる前払い手数料の支払いへの抵抗は少なくなるはずだと主張しています。 誠実なユーザーにとっては稀に発生する小さなコストが、大規模なジャミング攻撃を実行する不正なノードにとっては大きな保証コストとなり、 そのような攻撃が発生するリスクを低減することができます（また、持続的な攻撃が発生した場合に、 ネットワークを改善するために資本を投入するルーティングノードのオペレーターに補償することができます）。

    この記事の執筆時点では、このアイディアは緩やかに議論が行われています。

  • ● Taprootのテスト: Bitcoin-Devメーリングリストでのリクエストに応えて、 Anthony Townsは、signetまたはtestnetで、Bitcoin Coreでのテスト用に bech32mアドレスを作成するためのステップ・バイ・ステップの手順を提供しました。 この手順は、Taprootをテストする開発者にとって、Optechが以前提供したものよりも使いやすいかもしれません。

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

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

  • ● ZeusウォレットがLN機能を追加: モバイルのBitcoinおよびLightningウォレットアプリケーションであるZeusは、 v0.6.0-alpha3のリリースで、 Atomic Multipath Payment (AMP)、Lightning Addresses、 コインコントロール機能のサポートを追加しました。

  • ● Sparrowがcoinjoinをサポート: Sparrow 1.5.0は、SamouraiのWhirlpoolとの統合によりcoinjoin機能を追加しました。

  • ● JoinMarketがメイカーにとっての致命的なバグを修正し、RBFをサポート: JoinMarket 0.9.3では、メイカーにとっての致命的なバグが修正されました。 すべてのメイカーにアップグレードをお勧めします。またバージョン0.9.2では、 UIでFidelity bondをデフォルトで使用し、 非coinjoinトランザクションではreplace by fee (RBF)をサポートしています。

  • ● Coldcardがdescriptorベースのウォレットをサポート: Coldcard 4.1.3は、Bitcoin Coreでimportdescriptorsをサポートし、 Bitcoin CoreでdescriptorウォレットとPSBTワークフローを可能にします。

  • ● Simple Bitcoin WalletがCPFP、RBF、Holdインボイスを追加: 以前Bitcoin Lightning Walletとして知られていたSimple Bitcoin Walletは、 バージョン2.2.14で、child pays for parent (CPFP)と RBF (手数料の引き上げとキャンセル) 機能を追加し、2.2.15ではHoldインボイスを追加しました。

  • ● Electrs 0.9.0リリース: Electrs 0.9.0は、ディスクやJSON RPCからブロックを読み取るのではなく、 BitcoinのP2Pプロトコルを使用するようになりました。 アップグレードの詳細については、アップグレードガイドをご覧ください。

Taprootの準備 #18: トリビア

ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズです。

  • ● Taprootとは？ ウィキペディアによると、 「Taprootとは、大きく、中央にあり、そこから他の根が横方向に発芽する主要な根です。 一般的には、やや直線的で非常に太く、先細りの形状をしており、真下に向かって伸びています。 人参などの一部の植物では、Taprootは非常によく発達した貯蔵器官であるため、野菜として栽培されます。」

    これはBitcoinにどう当てはまるでしょう？

    • 「名前の由来は’taps into the Merkle root’だと思っていましたが、 Gregory Maxwellの考えがどうだったかは実は知りません。」 —Pieter Wuille (出典)

    • 「”私はもともと言葉を調べる必要がありました。しかし、 key pathが’taproot’になるのは、それが人参スープを作る美味しいものであるためで、 マークル化されたScriptは、無視したいと願う他の少ない根だろうと受け取りました。」 —Anthony Towns (出典)

    • 「名前の由来は、タンポポの根っこのような太い中心部を持つ木を視覚化したものです。 この技術は、高確率のパスが１つあり、残りはファジーなはぐれ者であるという仮定から、 ほとんどの場合役に立ちます。そして、 根っこに隠されたコミットメントを利用してscript-pathの支払いを検証するという面白い事実も良いと考えました。

      […]残念ながら、ソートされた内部ノードを持つハッシュツリーを’Myrtle tree’と呼んでも流行りませんでした。 （ハッシュルートが等しいポリシーのセットは、T-functionで定義できる順列によって順序の異なるものであるため、 Myrtle treeです。そして、Myrtleとは、お茶の木であるメラレウカを含む科であること、 そして’merkle’に聞こえることからきてます。:p）」 —Gregory Maxwell (出典)

  • ● Schnorr署名はECDSAより前から存在: Schnorr署名について、さまざまな暗号トリックの実装が簡単になるため、 Bitcoinの元のECDSA署名のアップグレードとして説明していますが、 Schnorr署名のアルゴリズムはECDSAのベースであるDSAアルゴリズムよりも前からあったものです。 実際、DSAはClaus Peter SchnorrのSchnorr署名の特許を回避するために作られたものですが、 Schnorrはそれでも「[私の]特許は、その種の離散対数署名のさまざまな実装に適用されており、 したがって、これらの事例であるNyberg-RueppelおよびDSA署名の使用をカバーしている。」と主張しています。 Schnorrの主張を支持した裁判所は知られておらず、彼の特許は2011年に失効しました。

  • ● どんな名前を使用するか: うまくいきまんせんでしたが、Schnorr署名をBitcoinに適用する開発の初期段階で、 Claus Peter Schnorrの名前を署名に関連して使うべきではないという提案がありました。 これは、彼の特許が20年以上にわたって貴重な暗号技術の普及を妨げていたためです。 Pieter Wuilleは、「BIP340を’Discrete Logarithm Signatures’から’DLS’と呼ぶことを検討したが、 Schnorrという名前がすでに話題になっていたため、最終的にそうならなかった」と書いています。

  • ● ツイストEdwards曲線のSchnorr署名: 楕円曲線を使用したSchnorr署名のアプリケーションが2011年に公開されました。 スキームEdDSAは、現在いくつかの標準の基礎となっています。 Bitcoinのコンセンサスでは使用されていませんが、他のシステムのコンテキストでの参照は、 Optechが追跡している多くのBitcoinリポジトリで見られます。

  • ● Pay to contract: Ilja GerhardtとTimo Hankeは、支払いがその契約のハッシュにコミットすることを可能する、 2013年のSan JoseのBitcoinカンファレンスでHankeによって紹介されたプロトコルを作成しました。 契約のコピーと、特定の攻撃を回避するために使用されるnonceを持っている人であればコミットメントを検証できますが、 それ以外の人にとってはその支払いは他のBitcoinの支払いと同じように見えます。

    このpay-to-contract (P2C)プロトコルを少し改良したものが、 サイドチェーンに関する2014年の論文に含まれており、 コミットメントには支払いのための元の公開鍵も含まれるようになっています。 Taprootはこれと同じ構造を採用していますが、オフチェーン契約の条項にコミットする代わりに、 アウトプットの作成者は、受信したビットコインをオンチェーンで使用する方法について、 受信者が選んだコンセンサス適用条件にコミットします。

  • ● A Good Morning: P2Cを利用することで、Scriptへの支払いが公開鍵への支払いとチェーン上で同一に見えるようにするアイディアは、 2018年1月22日にカリフォルニア州ロス・アルトスのダイナー「A Good Morning」で考案されました。 Pieter Wuilleは、このアイディアは「私が短時間テーブルを離れている間に… !$%@」[sic] Andrew PoelstraとGregory Maxwellによって開発されたと書いています。

  • ● 2.5年を1.5日で: bech32mに最適な定数を選択するのには、 約2.5年のCPU時間が必要でしたが、 Gregory Maxwellが所有するCPUクラスタを使用してわずか1.5日で実行されました。

このコラムに関連して楽しい会話をしてくださたAnthony Towns、Gregory Maxwell、Jonas Nick、 Pieter WuilleおよびTim Ruffingに感謝します。誤りがあった場合それは筆者の責任です。

リリースとリリース候補

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

  • ● BDK 0.12.0は、Sqliteを使ったデータ保存機能の追加などを行ったリリースです。

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

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

  • ● Bitcoin Core #22863では、P2TRアウトプットにはP2WPKHアウトプットと同じ 294 satの最低アウトプット量（”dust limit”）を使用するという決定がドキュメント化されています。 これは、現時点でdust limitを下げることに反対する開発者がいたため、 P2WPKHアウトプットよりP2TRアウトプットの方が消費コストが低いにも関わらず決定されました。

  • ● Bitcoin Core #23093では、ウォレット内のすべての事前生成されたアドレスに使用済みのマークをつけ、 新しいアドレスのセットが生成されるようにするnewkeypoolRPCが追加されました。 ほとんどのユーザーはこれを使用することはないでしょうが、 古い非BIP32ウォレットからHD鍵生成を使用するようにアップグレードした場合、 この動作はバックグラウンドで使用されます。

  • ● Bitcoin Core #22539では、手数料の見積もりをする際に、ローカルノードで確認された置換トランザクションを考慮します。 これまで置換トランザクションはほとんど発生しないため考慮されていませんでしたが、 現在は全トランザクションの20%が置換可能なBIP125シグナルを送信しており、 通常１日に数千件の置換が発生しています。

  • ● Eclair #1985では、新しいmax-exposure-satoshis設定項目が追加されました。 未解決の経済合理性のない支払いを持つチャネルが強制クローズされる際に、 マイナーへの寄付となる金額の上限を設定できるようにするものです。 詳細は、先週のニュースレターのCVE-2021-41591の記載をご覧ください。

  • ● Rust-Lightning #1124は、get_routeAPIを拡張し、 過去に失敗した経路の再利用を避けるために使用できる追加のパラメーターを渡すことができるようになりました。 今後予定されている変更で、後の結果の品質を向上させるために、過去のルーティングの成功や失敗を簡単に利用できるようになります。

  • ● BOLTs #894は、推奨されるチェックを仕様に追加しています。 これらを実装することで、経済合理性のないルーティング支払いがオンチェーンに展開される際に、 余剰ビットコインをマイナーに寄付するのを防ぐことができます。 これらのチェックがない場合に起こりうる問題の詳細については、 先週のニュースレターをご覧ください。