今週のニュースレターでは、Bitcoinにトランザクションヘリテージ識別子を追加する提案と、 Taprootの準備に関する情報や、新しいリリースおよびリリース候補のリスト、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点をまとめた恒例のセクションを掲載しています。

ニュース

  • ● トランザクションヘリテージ識別子の提案: 匿名の開発者John Lawによる投稿が、 Bitcoin-DevおよびLightning-Devメーリングリストに送信されました。 Lawは、現在のインプットに繋がるトランザクションの祖先のtxidとアウトプットの位置を参照できるようにする Inherited Identifiers (IIDs)を追加するソフトフォークを提案しました。 例えば、0123...cdef:0:1は、現在のトランザクションインプットが、 txid 0123...cdefの最初のアウトプットの２つめの子を使用していることを示します。 これにより、マルチパーティプロトコルの参加者は、 特定のアウトプットを生成するトランザクションのtxidを知ることができない場合でも、 そのアウトプットを支払いに使用するための署名を作成することができます。

    これは、提案中のSIGHASH_ANYPREVOUTソフトフォークによって可能になり、 eltooプロトコルの一部として定義されているフローティング・トランザクションのアプローチと比較されます。 フローティング・トランザクションでは、参加者は特定のアウトプットのScriptの条件を満たしていれば、 そのアウトプットのtxidを知らなくても署名を作成することができます。

    Lawは、eltooおよびChannel Factoriesの代替案を含む拡張論文で、 IIDsによって可能になる4つの異なるプロトコルに加えて、Watchtowerの設計を簡単にするアイディアについて説明しています。 Anthony Townsは、新しい開発であるもののIIDsの機能はanyprevoutを使ってシミュレートできるのではないかと提案しましたが、 Lawは、シミュレーションの可能性については同意しませんでした。

    すべての参加者がメーリングリストの利用を希望している訳ではなかったため、 アイディアの議論は複雑になりました。メーリングリストでの議論が再開された場合は、 今後のニュースレターで注目すべき更新をまとめていきます。

Taprootの準備 #16: アウトプットのリンク

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

Taprootがアクティベートされると、ユーザーはP2TRアウトプットへの支払いを受け入れます。 その後、ユーザーはそのアウトプットを使用します。場合によっては、 P2TR以外のアウトプットに支払いをして、P2TRのお釣り用アウトプットを使って自分自身にお釣りを返すこともあります。

Example transaction P2TR -> {P2WPKH, P2TR}

このようなトランザクションを観察している専門家やアルゴリズムは、 P2TRアウトプットがユーザー自身のお釣り用のアウトプットであり、 もう一方のアウトプットが支払い用のアウトプットであると合理的に推測することができます。 これが真実であるとは限りませんが、最も可能性の高い説明です。

ウォレットがP2TRに移行する間、このように一時的にプライバシーが低下する可能性があるため、 Taprootのプライバシー上の利点を無視すべきだと主張する人もいます。 多くの専門家は、それは不当な過剰反応であるとしています。 私たちもそれに同意し、さらにいくつかの反論をしたいと思います:

  • ● 他のメタデータ: トランザクションには、どのアウトプットがお釣りで、 どのアウトプットが支払いかを明らかにする、その他のメタデータが含まれている場合があります。 最も気になるのは、現在アドレスを再利用しているアウトプットが大きな割合を占めており、 これらのトランザクションに関わる送信者と受信者の両方のプライバシーが著しく低下していることです。 これらの問題が続く限り、ベストプラクティスを実装しているウォレットやサービスのユーザーのプライバシーを 大幅に改善しないのは愚かなことだと思います。

  • ● Output Scriptのマッチング: Bitcoin Coreの内蔵ウォレットでは、 支払いのアウトプットタイプのいずれかがsegwitでもある場合、 デフォルトでsegwitのお釣り用アウトプットを使用します。 それ以外の場合、デフォルトのお釣り用アドレスタイプを使用します。 例えば、P2PKHのアウトプットへの支払い時には、P2PKHのお釣り用アウトプットが使用され、 P2WPKHアウトプットに対しては、P2WPKHのお釣りが使用されます。 ニュースレター #155に記載されているように、Taprootのアクティベート後、 Bitcoin Coreは、同じトランザクション内の他のアウトプットがP2TRである場合、 P2TRのお釣り用アウトプットを機会的に使用し始めます。 これにより、移行期間中のお釣りの識別性の増加を最小限に抑えることができます。

  • ● アップグレードのリクエスト: P2TRの使用は、 セキュリティ要件に関係なく、誰もが同じタイプのOutput Scriptを使用することができ、 また、区別できないインプットを頻繁に使用することで、プライバシーを大幅に向上させることができるという、 Bitcoinの歴史上初めての機会になります。 Bitcoinのプライバシーを有意義に向上させたいのであれば、あなたが支払いをしているユーザーやサービスに、 Taprootのサポートを提供するよう依頼することができます（また、該当する場合は、アドレスの再利用を停止することも）。 あなたと彼らの両方がアップグレードすれば、お釣り用アウトプットの識別は難しくなり、 Taprootの他の驚くべきプライバシー上の利点もすべて得られます。

リリースとリリース候補

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

  • ● LND 0.13.3-betaは、資金の損失に繋がる脆弱性であるCVE-2021-41593を修正したセキュリティリリースです。 また、リリースノートには、すぐにアップグレードできないノードに対する緩和策の提案も含まれています。

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

今週の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 GUI #416では、”Enable RPC server”チェックボックスが追加され、 Bitcoin CoreのRPCサーバーをオン/オフできるようになりました（再起動が必要）。

    Screenshot of the Enable RPC server configuration option

  • ● Bitcoin Core #20591では、ウォレットに関連するトランザクションの履歴ブロックを再スキャンする際に、 ブロックのタイムスタンプのみを使用するよう、ウォレットの時間計算ロジックが変更されています。 rescanblockchain RPCを使って再スキャンを手動で呼び出すユーザーやアプリケーションは、 承認された時間ではなくスキャンされた時間で不正確にラベル付されたトランザクションを確認することはなくなり、 時折発生する混乱と不満の原因が解消されます。

  • ● Bitcoin Core #22722では、estimatesmartfee RPCが更新され、 設定済みおよび動的な最小トランザクションリレー手数料の両方よりも高い手数料率のみを返すようになりました。 例えば、見積もりツールが1 sat/vbyteの手数料を計算し、設定値が2 sat/vbyteで、 動的な最小値が3 sat/vbyteに上昇している場合、3 sat/vbyteの値が返されます。

  • ● Bitcoin Core #17526では、第3のコイン選択の戦略として、 Single Random Draw (SRD)アルゴリズムを追加しました。 これでウォレットは、分枝限定法（BnB）、ナップザック、SRDアルゴリズムのそれぞれからコイン選択結果を取得し、 以前紹介したwasteヒューリスティックを使用して、 3つの中から最も費用対効果の高い結果を選択してトランザクションに資金を供給します。

    約8,000の支払いを元にしたシミュレーションで、PRの作成者は、SRDアルゴリズムの追加により、 全体的なトランザクション手数料が6%削減され、お釣りのないトランザクションの発生が5.4%から9.0％に増加したことを発見しました。 お釣りのアウトプットを作成しないことで、トランザクションweightおよび手数料が減少し、 ウォレットのUTXOプールサイズも減少し、お釣りのアウトプットを後で使用するコストが削減され、 ウォレットのプライバシーが向上すると考えられます。

  • ● Bitcoin Core #23061では、-persistmempool設定オプションが修正されました。 これまでは、パラメーターが渡されない場合、シャットダウン時にmempoolをディスクに永続化しませんでした（実際に永続化するためには、 -persistmempool=1を渡す必要がありました。 今後は素の-persistmempoolオプションのみでmempoolが永続化されます（これはデフォルトのままなので、パラメーターを渡す必要はありません）。

  • ● Bitcoin Core #23065では、ウォレットのUTXOのロックをディスクに永続化できるようになりました。 Bitcoin Coreのウォレットでは、ユーザーが1つ以上のUTXOをロックし、 それを自動的に作成されるトランザクションで使用されるのを防ぐことができます。 lockunspent RPCには、設定をディスクに保存するpersistentパラメーターが追加され、 GIUではユーザーが選択したロックが自動的にディスクに永続化されるようになりました。 ロックの永続化の用途としては、金額の小さいスパムアウトプットや、 ユーザーのプライバシーを損なう可能性のあるアウトプットの支払いの防止が挙げられます。

  • ● C-Lightning #4806では、ユーザーがノードの手数料設定を変更してから新しい設定が適用されるまで、 デフォルトで10分の遅延が追加されました。 これにより、最近値上がりした手数料の支払いに失敗して支払いがリジェクトされる前に、 ノードによる新しい手数料の通知がネットワーク全体に伝播されます。

  • ● Eclair #1900とRust-Lightning #1065は、BOLTs #894を実装しています。 これによりコミットメントトランザクションでsegwitアウトプットの使用のみが許可されるため、 LNプロトコルがより厳密になります。この制限を実行することで、 LNプログラムは、より低いdust limitを使用することができ、 これにより（手数料率が低い場合に）、チャネルの強制クローズ時にマイナーに渡って失われる可能性のある金額を減らすことができます。

  • ● LND #5699では、支払いの試行を削除するためのdeletepaymentsコマンドが追加されました。 デフォルトでは、失敗した支払いの試行のみが削除されます。安全性のため、 成功した支払いの試行を削除するためには、追加のフラグを渡す必要があります。

  • ● LND #5366では、データベースのバックエンドとしてPostgreSQLを使用するための初期サポートを追加しました。 既存のbboltバックエンドと比較して、PostgreSQLは複数のサーバーにレプリケーションすることができ、 停止することなくデータベースの圧縮を行い、より大きなデータセットを扱うことができ、 I/Oロックの競合を改善する可能性のあるより詳細なロックモデルを提供します。

  • ● Rust Bitcoin #563は、P2TRアウトプットにbech32mアドレスのサポートしました。

  • ● Rust Bitcoin #644は、Tapscriptの新しいOP_CHECKMULTISIGADDopcodeとOP_SUCCESSxopcodeをサポートしました。

  • ● BDK #376は、データベースのバックエンドとしてsqliteをサポートしました。