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

Bitcoin Optech Newsletter #154

Jun 23, 2021

今週のニュースレターでは、手数料による普遍的なトランザクションの置換を可能にする提案と、 Taprootの準備に関する新しい週刊シリーズの最初の記事を掲載しています。また、クライアントやサービスの更新や、新しいリリースおよびリリース候補、人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更点などの恒例のセクションも含まれています。

ニュース

● デフォルトでトランザクションの置換を許可: 現在、ほぼすべてのBitcoinフルノードは、BIP125 opt-in Replace By Fee (RBF)を実装していると考えられます。 RBFは、トランザクションの作成者が元のトランザクションにシグナルを設定した場合に限り、ノードのmempool内の未承認トランザクションを、より高い手数料の代替バージョンに置き換えることができるようにするものです。このopt-inの動作は、手数料の引き上げや加法的な支払いのバッチ処理などでトランザクションの置換を許可したい人々と、置換を許可すると未承認のトランザクションを最終的なものとして受け入れるマーチャントを欺くツールの構築が簡単になるという理由で反対する人々との間の妥協案として提案されました。

５年以上経過した現在、未承認トランザクションを最終的なものとして受け入れているマーチャントはほとんどいないようです。実際に、 BIP125 opt-inシグナルをチェックし、それらのトランザクションを異なる方法で処理しているマーチャントの数は明らかになっていません。誰もBIP125のシグナルに依存していないのであれば、すべてのトランザクションを置換可能にすることで、以下のような利点が得られます:
- RBFによる手数料の引き上げのアイディアでは、悪意ある相手がBIP125シグナルの設定を防ぐの能力を考慮する必要があるが、（LNやVaultなどの）事前署名されたトランザクションプロトコルの分析を簡素化します。
- RBFを選択したトランザクションは、選択していないトランザクションとはチェーン上で異なって見えるため、 トランザクション分析の機会が減少します。ほとんどのウォレットは一貫してオプトインするかしないかを選択するため、これは監視会社が誰がどのビットコインを所有しているかを特定するために使用できる証拠になります。すべてのトランザクションが置換可能であれば、BIP125シグナルを設定する必要はないでしょう。
今週、Antoine Riardは、BIP125 opt-inシグナルを設定するかどうかに関わらず、最終的にBitcoin Coreのコードを変更して、すべてのトランザクションにRBFを許可するという提案をBitcoin-Devメーリングリストに投稿しました。このアイディアは、最初のトランザクションリレーワークショップのミーティングでも議論されました。参加者の何人かは、別のアプローチとしてBitcoin CoreのPR #10823に言及していました。このPRでは、どのようなトランザクションでも置換可能ですが、そのトランザクションがノードのmempoolで一定時間（当初は6時間と提案されていましたが、その後72時間が提案されました）経過した後でのみ置換可能になります。

Riardのメールとミーティング参加者ともに、BIP125 opt-inシグナルを含まないトランザクションを置き換える提案には、現在BIP125の動作に依存しているマーチャントからのフィードバックが必要であると述べています。 Optechは、そのようなマーチャントがメーリングリストのスレッドに反応することを推奨します。

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

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

● Trezor SuiteがRBFのサポートを追加: Trezorのウォレットソフトウェア、 Trezor Suiteがバージョン21.2.2でReplace-by-Fee(RBF)のサポートを追加しました。 RBFはデフォルトでオンになっており、Trezorのいくつかのハードウェアデバイスでもサポートされています。
● Lightning LabsがTerminal Webを発表: Lightning Labsは、最近のブログ記事で、 WebベースのLightningノードのスコアリングダッシュボードであるTerminal Webについて説明しています。
● Specter v1.4.0リリース: Specter v.1.4.0は、BIP125 opt-in Replace-by-Fee (RBF)を使用してトランザクションを”キャンセル”する機能を追加しています。
● PhoenixがLNURL-payを追加: ACINQのモバイルウォレットPhoenixは、v1.4.12リリースで LNURL-payプロトコルのサポートを追加しました。
● JoinMarket v0.8.3リリース: JoinMarket v0.8.3では、カスタムのお釣り用アドレスを提供する機能と、 Electrum互換のsegwitのsignmessage実装が追加されました。

Taprootの準備 #1: bech32m送信のサポート

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

11月に予定されているブロック709,632から、 BitcoinユーザーはTaprootアドレスへの支払いを安全に受け取ることができるようになります。 Taprootに対するユーザーの熱意と、ウォレット開発者がTaprootのサポートを実装する必要がある5ヶ月を考えると、 Optechは、ユーザーができるだけ早くTaprootアドレスを生成できるようにする人気ウォレットがいくつか出てくると予想しています。

つまり、ユーザーが提供したアドレスにビットコインを送金するウォレットやサービスは、ブロック709,632までにTaprootアドレスに送信できるようにする必要があり、そうしないとユーザーを混乱させ失望させるリスクがあります。 Pay to TapRoot (P2TR)アドレスは、BIP350で定義されているbech32mを使用すます。これはsegwitのv0 P2WPKHおよびP2WSHアドレスに使用されているBIP173のbech32アルゴリズムと少し異なります。 bech32mは、チェックサム関数でbech32の0x01に代わって、0x2bc830a3を使用します。

この１つの定数を変更することで、bech32mのチェックサムを検証できますが、既存のP2WPKHおよびP2WSHアドレスについては、元の定数を使用する必要があります。コードはチェックサムを検証せずにアドレスをデコードし、 v0 segwit (bech32)を使用しているか、v1+ segwit (bech32m)を使用しているかを判断し、適切なチェックサムを検証する必要があります。例として、C、C++、JS、Pythonのbech32参照実装を更新したPRを参照ください。コードが既に参照ライブラリを使用している場合は、リポジトリから最新のコードに更新することができますが、 APIの一部がわずかに変更されていることに注意してください。 BIP350と参照実装は、すべてのbech32m実装が使用すべきtest vectorを提供しています。

Taprootアドレスへの支払いの受け取りは、ブロック709,632まで安全ではありませんが、支払いの送信によって送信者に問題が発生することはありません。 Bitcoin Coreは、（2019年11月にリリースされた）バージョン0.19以降、 Taprootへの支払いアウトプットを持つトランザクションのリレーや、マイニングをサポートしています。 Optechは、ウォレットやサービスの開発者に対して、Taprootがアクティベートされるまで待つことなく、今すぐにbech32mのTaprootアドレスへの支払いのサポートを実装することを推奨しています。

リリースとリリース候補

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

● LND 0.13.0-betaは、新しいメジャーリリースで、 anchor outputをデフォルトのコミットメントトランザクションフォーマットにすることで手数料率の管理を改善し、プルーニングされたBitcoinフルノードの使用をサポートし、 Atomic MultiPath（AMP）を使用した支払いの送受信を可能にし、 LNDのPSBTの機能を向上させるなどの改良やバグ修正を行っています。

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

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

● Bitcoin Core #21365では、P2TR公開鍵のみを使用したkeypathによる使用と、 Tapscript使用したscriptpathによる使用の両方について、 Taprootを使用する際の署名を作成する機能が追加されました。ウォレットはTaprootを使用するPSBTにも署名できますが、これはウォレットが必要なすべてのkeypathもしくはscriptpathの情報を既に持っている場合に限られます。多少関連するマージ済みのPR #22156では、 Taprootが有効になった後で、そのkeypathやscriptpathの情報をインポートすることのみ可能です（mainnetではブロック709,632ですが、Taprootが既に有効になっているテストネットワークでは、インポートは現在使用できます）。
● Bitcoin Core #22144は、ピアからのP2Pメッセージの解析と処理および、それらのピアへメッセージを送信するメッセージ処理スレッドで、ピアが処理される順序をランダム化します。これまでは、メッセージ処理スレッドは、それらのピアへの接続が最初に確立された順に ラウンドロビンでサービスを提供していました。このPRではロジックを変更し、メッセージ処理ループの各反復において、ピアにサービスを提供する順番がランダムになるようにしました。ピアは同じ頻度でサービスされますが（ピアは各反復毎に１回サービスされます）、サービスされるピアの決定論的な順序に依存する弱点や悪用は回避されます。
● Bitcoin Core #21261は、インバウンド接続保護をより多くのネットワークに拡張することを容易にし、そのフレームワークを使用してI2Pを保護されたネットワークのリストに追加できるようにしています。多様性保護（よく退避保護と呼ばれる）により、Bitcoin Coreが高レイテンシーの接続を切断する際に、望ましい特性を持つ少数のピアの接続が維持されるようになります。匿名ネットワーク上のピアへの少数の接続を維持することは、トランザクション作成者がネットワークの識別子を隠すためにそれらのネットワークを使用できるようにし、通常のインターネットプロトコルに加えてこれらのネットワークを介してブロックを受信する機能により、いくつかのタイプのエクリプス攻撃を防ぐことができるという理由から、非常に望ましいことです。
● Rust Bitcoin #601は、bech32mアドレスの解析のサポートを追加し、 v1以上のネイティブsegwitアドレスをbec32ではなくbech32mでエンコードするよう要求します。
● BTCPay Server #2450は、ユーザーが支払いの受け取りにホットウォレットを選択した場合に、 Payjoin互換のインボイスの生成をデフォルトにしました。 ウォレット作成画面にあるボタンで、このデフォルト設定を解除することができます。
● BTCPay Server #2559では、ユーザーが自分のウォレットから使用するトランザクションに署名する方法の選択をユーザーに案内するための別画面が追加されました。ホットウォレットの場合はサーバーが署名するだけですが、鍵が別の場所に保存されているウォレットの場合、魅力的で情報量の多いGUIで、リカバリーニーモニックの入力やハードウェア署名デバイスの使用、署名ウォレットへ転送するPSBTの生成などの署名オプションをユーザーに案内するようになりました。