今週のニュースレターでは、Coinjoinトランザクションのピン留めを防止するためのアイディアと、 期待されるコンセンサスの変更を投機的に使用するための提案を掲載しています。 また、mempoolポリシーに関する限定週刊シリーズの新しい記事に加えて、 Bitcoin Stack Exchangeの人気の質問とその回答や、新しいリリースとリリース候補、 人気のBitcoinインフラストラクチャソフトウェアの変更など恒例のセクションも掲載しています。

ニュース

  • ● v3トランザクションリレーを使用してCoinjoinのピン留めを防止する: Greg Sandersは、提案されているv3トランザクションリレールールによって、 トランザクションのピン留めに対して脆弱でない Coinjoinスタイルのマルチパーティトランザクションの作成がどう可能になるかについての説明を Bitcoin-Devメーリングリストに投稿しました。 ピン留めに関する具体的な懸念は、Coinjoinの参加者の1人が、 自身のインプットを使用してCoinjoinトランザクションの承認を妨げる競合トランザクションを作成する可能性があることです。

    Sandersは、Coinjoinスタイルのトランザクションでは、 各参加者が最初に自身のビットコインを、Coinjoinの全参加者の署名か、 タイムロックが切れた後に参加者自身の署名でのみ使用可能なスクリプト宛に送金することで、 この問題を回避できると提案しています。または、協調型のCoinjoinの場合は、 コーディネーターと参加者が必ず共同で署名する必要があります（タイムロックの有効期限が切れた後は参加者のみ）。

    タイムロックが期限切れになるまでは、参加者は、競合するトランザクションを作成する場合、 他の参加者またはコーディネーターのいずれかに競合するトランザクションに共同で署名してもらう必要がありますが、 その署名がすべての参加者にとって最善の利益にならない限り（たとえば手数料の引き上げなど）、 彼らが共同署名する可能性は低いでしょう。

  • ● 期待されるコンセンサスの変更を投機的に利用する: Robin Linusは、長期間（たとえば20年）実行できないスクリプトの断片に資金を投じるアイディアを Bitcoin-Devメーリングリストに投稿しました。 そのスクリプトの断片が現在のコンセンサスルールにしたがって解釈される場合、 20年後のマイナーがその断片に支払われた資金をすべて請求できるようになります。 しかし、この断片は、コンセンサスのアップグレードによって異なる意味を持つように設計されています。 Linusは、OP_ZKP_VERIFY opcodeを例に挙げており、このopcodeがBitcoinに追加されれば、 特定のハッシュを持つプログラムに対するZKP（ゼロ知識証明）を提供する人が資金を請求できるようになります。

    これによって、人々は今日BTCをこれらのスクリプトの１つに支払うことができ、 その証明を使ってサイドチェーンや別のチェーン上で同額のBTCを受け取ることができるようになります（one-way peg）。 別のチェーン上のBTCは、タイムロックの期間が切れるまで、20年間繰り返し使用できます。 その後、別のチェーン上のBTCの現在の所有者は、そのBTCを所有していることを証明するZKPを生成し、 その証明を使ってBitcoinのmainnet上でロックされたデポジットを引き出すことができ、 two-way peg が作成されます。検証プログラムをうまく設計すれば、引き出しは簡単で柔軟なものになり、 ファンジブルな引き出しが可能になります。

    著者らは、この構成がメリットになる人（たとえば、別のチェーンでBTCを受け取る人）は基本的に、 Bitcoinのコンセンサスルールが変更されること（たとえば、OP_ZKP_VERIFYが追加される）ことに賭けることになると指摘しています。 これにより、変更を求めるインセンティブが得られますが、 一部のユーザーにシステム変更を強く奨励すると、他のユーザーは強制されているように感じる可能性があります。 このアイディアは、この記事の執筆時点では、メーリングリストで議論されていません。

承認を待つ #7: ネットワークリソース

トランザクションリレーや、mempoolへの受け入れ、マイニングトランザクションの選択に関する限定週刊シリーズです。 Bitcoin Coreがコンセンサスで認められているよりも制限的なポリシーを持っている理由や、 ウォレットがそのポリシーを最も効果的に使用する方法などが含まれます。

前回の記事では、ノードリソースの保護について説明しました。 ノードリソースはノード毎に固有であり、設定可能な場合もあります。 また、1つポリシーに収束することが最善である理由についても説明しましたが、 そのポリシーの一部として何が含まれるべきでしょうか？ この記事では、スケーラビリティ、アップグレード性、ブートストラップやフルノードの維持のし易さなどにとって重要な、 ネットワーク全体のリソースの概念について説明します。

以前の記事で説明したように、Bitcoinネットワークの思想的目標の多くは、 その分散構造に具現化されています。Bitcoinのピア・ツー・ピアの性質により、 ネットワークのルールは個々のノードオペレーターの選択の大まかな合意から生まれ、 ネットワーク内で不当な影響力を獲得しようとする試みを抑制します。 これらのルールは、すべてのトランザクションを個別に検証する各ノードによって適用されます。 多様で健全なノード群を実現するには、ノードの運用コストを低く抑える必要があります。 世界中のユーザーを対象にプロジェクトを拡大するのは困難ですが、 分散化を犠牲にすることなくそれを行うことは、片手を背中に縛られて戦うようなものです。 Bitcoinプロジェクトは、共有ネットワークのリソース、つまりUTXOセットや、 ブロックチェーンのデータフットプリントとその処理に必要な計算量、 Bitcoinプロトコルを進化させるためのフックのアップグレードを厳重に保護することで、 このバランスをとろうとしています。

ブロックチェーンの成長に制限を設けることが自分自身のノードを運営するために手頃な価格を維持するのに必要であることを理解するために、 再度ブロックサイズ戦争を繰り返す必要はありません。ただし、ブロックチェーンの成長は、 「高度に複製された永久的なストレージに対する無制限の需要」の一部を表現するために必要な最小コストを確保する 1 sat/vbyteのminRelayTxFeeによってポリシーレベルでも抑制されています。

当初、ネットワークの状態は、未使用のアウトプットをまだ持つすべてのトランザクションを保持することで追跡されていました。 ブロックチェーンのこのより大きな部分は、資金を追跡する手段としてUTXOセットの導入により大幅に削減されました。 それ以来、UTXOセットは中心的なデータ構造となっています。特にIBD中だけでなく一般的にも、 UTXOのルックアップは、ノードのすべてのメモリアクセスの大部分を占めています。 Bitcoin Coreは、既にUTXOキャッシュ用に手動で最適化されたデータ構造を使用していますが、 UTXOセットのサイズはノードのキャッシュに収まらない量を決定します。 UTXOセットが大きいほどキャッシュミスが多くなり、ブロックの検証やIBD、トランザクションの検証速度が遅くなります。 ダスト・リミットは、UTXOの作成を制限するポリシーの例であり、 具体的には、その額が支払いに必要なコストを下回るため、 決して使用されない可能性のあるUTXOを抑制します。それでも、 数千件のトランザクションを伴う「ダスト・ストーム」は2020年にも発生しました。

データをブロックチェーン上に公開するためにベア・マルチシグアウトプットを使用するのが一般的になったとき、 標準トランザクションの定義が修正され、代わりに単一のOP_RETURNアウトプットを許可するようになりました。 人々は、ユーザーがブロックチェーン上にデータを公開するのを防ぐことは不可能であることに気づきましたが、 少なくともそのようなデータは決して使用されないアウトプットで公開される場合、 UTXOセットに永久に存在する必要はありません。 Bitcoin Core 0.13.0では、ユーザーがベア・マルチシグアウトプットを含む未承認トランザクションを 拒否するように切り替えることができる起動オプション-permitbaremultisigが導入されました。

コンセンサスルールでは、アウトプットスクリプトを自由な形式にすることができますが、 Bitcoin Coreノードによってリレーされるのはわずかなパターンだけです。 これにより、検証コストやプロトコルアップグレードメカニズムなど、 ネットワーク内の多くの懸念を理解しやすくなります。 たとえば、opcodeを含むインプットスクリプトや、15個以上の署名を持つP2SHインプット、 witnessスタックに100を超える項目を持つP2WSHインプットは、非標準トランザクションになります。 （ポリシーの例やその動機については、このポリシーの概要をご覧ください。）

最後に、Bitcoinプロトコルは、活動中のソフトウェアプロジェクトであり、 将来の課題やユーザーのニーズに対応するために進化し続ける必要があります。 そのため、annexやTaprootのリーフバージョン、witnessバージョン、OP_SUCCESSおよび 多数のno-op opcodeなど、コンセンサスが有効であるにもかかわらず未使用のまま意図的に残された多数のアップグレードフックがあります。 ただし、攻撃が中央集権的な障害点の欠如によって妨げられるのと同様に、 ネットワーク全体のソフトウェアのアップグレードには、数万もの独立したノードオペレーターの協調した取り組みが必要です。 ノードは、その意味が定義されるまで、予約されたアップグレードフックを利用するトランザクションをリレーしません。 この抑制は、アプリケーションが矛盾する標準を独自に作成することを思いとどまらせることを目的としています。 これにより、あるアプリケーションの標準を、別のアプリケーションの標準を無効にすることなくコンセンサスに採用することは不可能になります。 また、コンセンサスの変更が発生した場合、すぐにアップグレードしないノード、 つまり新しいコンセンサスを知らないノードは、「騙されて」無効なトランザクションを自分のmempoolに受け入れることはできません。 積極的な抑制により、ノードの前方互換性が維持され、完全に同期したソフトウェアアップデートを必要とせずに、 ネットワークがコンセンサスルールを安全にアップグレードできるようになります。

ポリシーを使用して共有ネットワークリソースを保護することで、 ネットワークの特性を保護し、将来のプロトコル開発のための道を開いておくことができます。 一方、厳しく制限されたblockweightに対してネットワークを成長させる摩擦が、 ベストプラクティの採用、優れた技術設計、イノベーションの採用をどのように推進しているかが分かります。 来週の記事では、2ndレイヤープロトコルやスマートコントラクトシステムのインターフェースとしてのmempoolについて説明します。

Bitcoin Stack Exchangeから選ばれたQ&A

Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。

リリースとリリース候補

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

  • ● BTCPay Server 1.10.3は、このセルフホスト型のペイメントプロセッサソフトウェアの最新リリースです。 1.10ブランチの主要機能については、ブログ記事をご覧ください。

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

今週の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の注目すべき変更点。

  • ● Core Lightning #6303は、新しいsetconfig RPCを追加し、 デーモンを再起動することなくいくつかの設定オプションを変更できるようになりました。

  • ● Eclair #2701では、オファーされたHTLCをいつ受信し、いつ決済したかを記録するようになりました。 これにより、ノードの視点からHTLCがどれくらいの時間保留されていたかを追跡できるようになりました。 多くのHTLCや、少数の高額なHTLCが長時間保留されている場合、 これは、チャネルジャミング攻撃が進行中であることを示すかもしれません。 HTLCの期間を追跡することは、そのような攻撃を検出し、緩和するのに役立つ可能性があります。

  • ● Eclair #2696では、ユーザーが使用する手数料率を設定する方法が変更されました。 これまでは、ブロックターゲット で使用する手数料率を指定できました。たとえば「6」を設定すると、 Eclairは6ブロック以内にトランザクションが承認されるようにします。 現在、Eclairは、「slow」、「medium」、「fast」を受け付けるようになり、 それを定数またはブロックターゲットを使用して、特定の手数料率に変換します。

  • ● LND #7710では、プラグイン（またはデーモン自体）が、HTLCで以前受信したデータを取得する機能が追加されました。 これは、ルート・ブラインディングに必要で、 将来の機能のアイディアの中でも特に、さまざまなチャネルジャミング対策に使用される可能性があります。

  • ● LDK #2368は、アンカー・アウトプットを使用するピアによって作成された 新しいチャネルを受け入れられるようになりましたが、制御プログラムは新しい各チャネルを受け入れることを意図的に選択する必要があります。 これは、アンカー・チャネルを適切に設定するには、ユーザーが十分な額を持つ1つ以上のUTXOにアクセスできる必要があるためです。 LDKは、ユーザーのウォレットがどのような非LNのUTXOを管理しているのか知らないライブラリとして、 制御プログラムに必要なUTXOを持っているかどうかを確認する機会を与えるために、このプロンプトを使用します。

  • ● LDK #2367では、アンカー・チャネルがAPIの通常利用者にもアクセス可能になりました。

  • ● LDK #2319により、ピアは、元の送信者が支払わなければならないと言った金額よりも少ない金額を支払うことにコミットするHTLCを作成できるようになり、 ピアはその差額を追加の手数料として自分用に保持できるようになりました。 これは、ピアがまだチャネルを持っていない受信者のHTLCを受信するJITチャネルの作成に役立ちます。 ピアは、チャネルに資金を提供するオンチェーントランザクションを作成し、 そのチャネル内のHTLCにコミットします。しかし、オンチェーントランザクションの作成により、 追加のトランザクション手数料が発生します。追加手数料を取ることで、 受信者が新しいチャネルを受け入れ、HTLCを時間内に決済した場合に、そのコストが補償されます。

  • ● LDK #2120は、ブラインド・パスを使用している受信者へのルートを検索するためのサポートを追加しました。

  • ● LDK #2089は、ウォレットがオンチェーンで決済する必要のあるHTLCに 簡単に手数料を追加できるようにするイベントハンドラーを追加しました。

  • ● LDK #2077は、後でデュアル・ファンディングチャネルのサポートを簡単に追加できるように、 大量のコードをリファクタリングしました。

  • ● Libsecp256k1 #1129は、ElligatorSwift手法を実装し、 計算上ランダムデータと区別できない64バイトの公開鍵エンコーディングを導入します。 ellswiftモジュールは、新しい形式で公開鍵をエンコードおよびデコードするための関数に加えて、 一様にランダムな新しい鍵を生成し、ellswiftでエンコードされた鍵で ECDH（楕円曲線ディフィー・ヘルマン鍵交換）を実行するための便利な関数を提供します。 ellswiftベースのECDHは、バージョン2 P2P暗号化トランスポートプロトコル（BIP324）の接続を 確立する際に使用されます。