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

Bitcoin Optech Newsletter #304

May 24, 2024

今週のニュースレターでは、LNチャネルを閉じたり再オープンしたりすることなくチャネルをアップグレードするためのいくつかの提案の分析と、プールマイナーに適切な支払いを保証する際の課題に関する議論、サイレントペイメントに関する情報を伝達するためにPSBTを安全に使用することについての議論のリンク、 miniscriptのBIP提案の発表、価格先物契約をシミュレートするためにLNチャネルの頻繁なリバランスを使用する提案を掲載しています。また、サービスとクライアントソフトウェアの変更、新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、恒例のセクションも含まれています。

ニュース

● 既存のLNチャネルのアップグレード: Carla Kirk-Cohenは、新機能をサポートするために既存のLNチャネルをアップグレードするための既存の提案の要約と分析をDelving Bitcoinに投稿しました。彼女は以下のようなさまざまなケースを検証しています:
- ● パラメーターの変更: 現在、いくつかのチャネルの設定は、参加者間で交渉され、チャネルの存続中は変更できません。パラメーターを更新すると、その後の再交渉が可能になります。たとえばノードは、HTLCのトリミングを始めるsatoshiの量や、古い状態での閉鎖を抑制するために取引相手に保持させるチャネルリザーブの量を変更したい場合があります。
- ● コミットメントの更新: LNの コミットメントトランザクション により、個々人は現在のチャネル状態をオンチェーンに展開することができます。コミットメントのアップグレードにより、 P2WSHベースのチャネルでは、アンカーアウトプットや v3トランザクションへの切り替えが可能になり、 Simple Taproot Channelでは、 PTLCの使用への切り替えが可能になります。
- ● ファンディングの置き換え: LNチャネルは、 ファンディングトランザクション でオンチェーンにアンカリングされており、そのアウトプットは、コミットメントトランザクションとしてオフチェーンで繰り返し使用されます。当初、すべてのLNファンディングトランザクションは、P2WSHアウトプットを使用していました。しかし、PTLCのような新しい機能では、ファンディングトランザクションはP2TRアウトプット使用する必要があります。
Kirk-Cohenは、チャネルをアップグレードするための以前の3つのアイディアを比較しています:
- ● ダイナミックコミットメント: ドラフト仕様に記載されているように、これはほとんどすべてのチャネルパラーメーターを変更することができ、新しい「キックオフ」トランザクションを使用してファンディングトランザクションおよびコミットメントトランザクションをアップグレードするための一般化されたパスも提供します。
- ● アップグレードのためのスプライス: このアイディアは、チャネルのオンチェーンファンディングを更新するスプライストランザクションで、使用するファンディングタイプとオプションでコミットメントトランザクションのフォーマットを変更できるようにするものです。これはチャネルパラメーターの変更には直接対応しません。
- ● 再確立時のアップグレード: ドラフト仕様にも記載されているように、 2つのノードがデータ接続を再確立するたびに多くのチャネルパラメーターを変更することができます。ファンディングトランザクションやコミットメントトランザクションの変更には直接対応しません。
Kirk-Cohenは、提示されたすべてのオプションについて、オンチェーンコスト、長所、短所をリストアップした表で比較し、アップグレードしない場合のオンチェーンコストとも比較しています。彼女は次のようないくつかの結論を導き出しました。「Taprootチャネルへのアップグレードをどのように行うかに関係なく、ダイナミックコミットメントを介したパラメーターとコミットメントの両方のアップグレードに取り組み始めるのが理になかっていると思います。これにより、option_zero_fee_htlc_txアンカーチャネルへのアップグレードが可能になり、 v3チャネルへのアップグレードに使用できるコミットメント形式のアップグレードメカニズムが提供されます。」
● プールマイナーへの報酬の課題: Ethan Tuttleは、マイニングプールがマイナーにマイニングしたシェアに比例した ecashトークンを与える提案をDelving Bitcoinに投稿しました。マイナーはそのトークンをすぐに売却したり送金することもできます。もしくは、プールがブロックをマイングするのを待つこともでき、マイニングされた時点でプールはトークンとsatoshiを交換します。

このアイディアに対する批判と提案の両方が投稿されました。特にMatt Coralloの根本的な問題について説明した返信は洞察に富んでいました。それは、プールマイナーが短期間で報酬の支払いを計算できるように、大規模なプールで実装されている標準化された支払い方法が存在しないというものです。一般的に使用される支払いの種類は2つあります:
- ● PPS（Pay per share）: これはブロックが見つからなくても、マイナーが貢献した作業量に比例して支払われます。ブロック報酬の比例配当の計算は簡単ですが、トランザクション手数料の計算はより複雑です。 Coralloは、ほとんどのプールはシェアが作成された日に収集された手数料の平均を用いているようで、これはシェアがマイニングされた翌日まで1シェアあたりの支払額を計算できないことを意味すると指摘しています。さらに、多くのプールでは、プールごとに異なる方法で手数料の平均を微調整する場合があります。
- ● PPLNS（Pay per last n shares）: プールがブロックを見つける直前に見つかったシェアに対してマイナーに報酬を与えます。ただし、マイナーがプールでブロックを見つけたと確信できるのは、マイナー自身がブロックを見つけた場合のみです。一般的なマイナーにとって、プールが正しく支払いをしていることを知る方法は（短期的には）ありません。
この情報の欠如は、メインプールが支払いを騙し始めても、マイナーがすぐに別のプールに乗り換えることがないことを意味します。 Stratum v2ではこの問題は解決されませんが、プールは標準化されたメッセージを使用してマイナーに新しいシェアの支払いを停止することを伝えることができます。 Coralloは、すべてのシェアが支払いに含まれていることをマイナーが確認できるようにする Stratum v2への提案のリンクを記載しています。これにより、マイナーは少なくとも長期間経てば（数時間から数日）、正しく支払われていないかどうかを検知できるようになる可能性があります。

この記事の執筆時点では、議論は継続中です。
● サイレントペイメント用のPSBTに関する議論: Josie Bakerは、 Andrew Tothのドラフト仕様を引用して、サイレントペイメント（SP）用のPSBT拡張に関する議論を Delving Bitcoinで始めました。SP用のPSBTには2つの側面があります:
- ● SPアドレスへの支払い: トランザクションに配置される実際のアウトプットスクリプトは、サイレントペイメントアドレスとトランザクションのインプットの両方に依存します。 PSBT内のインプットを変更すると、標準的なウォレットソフトウェアではSPアウトプットを使用できなくなる可能性があるため、 PSBTの追加検証が必要になります。インプットの種類によってはSPと一緒に使用できないため、これも検証が必要です。
  
  使用可能な種類のインプットについては、SP対応の支払いロジックにはそれらのインプットの秘密鍵が必要ですが、その基礎となる鍵がハードウェア署名デバイスに保存されている場合、ソフトウェアウォレットでは秘密鍵を利用できない可能性があります。 Bakerは、支払人が秘密鍵なしでSPアウトプットスクリプトを作成できるようにするスキームについて説明していますが、これには秘密鍵が漏洩する可能性があるため、ハードウェア署名デバイスには実装されない可能性があります。
- ● 過去に受信したSPアウトプットの使用: PSBTには、支払いに使用する鍵への微調整に使用される共有シークレットを含める必要があります。これは単に追加のPSBTフィールドで構いません。
この記事の執筆時点では、議論は継続中です。
● miniscriptのBIP提案: Ava Chowは、miniscriptのBIPドラフトを Bitcoin-Devメーリングリストに投稿しました。 miniscriptは、Bitcoinスクリプトに変換できる言語で、さらに合成、テンプレート化、最終的な分析が可能です。このBIPのドラフトは、miniscriptの以前からあるWebサイトから派生したもので、 P2WSH witnessスクリプトおよびP2TRのTapscriptの両方の既存のminiscriptの実装に対応するものです。
● チャネル価格へのペグ: Tony Klausingは、 ステーブルチャネル 関する提案を動作するコードと共にDelving Bitcoinに投稿しました。アリスが$1,000 USDに相当する量のビットコインを保持したいと考えているとしましょう。ボブは、BTCの価値が上昇することを期待している、またはアリスが彼にプレミアム支払うため（もしくはその両方）、それを保証するつもりです。両者は一緒にLNチャネルを開き、1分ごとに以下のアクションを実行します:
- どちらも同じBTC/USD価格ソースをチェックします。
- BTCの価値が上昇した場合、アリスは自分のビットコイン残高を$1,000 USDになるまで減らし、超過分をボブに送信します。
- BTCの価値が下がった場合は、ボブはアリスのビットコイン残高が再度$1,000 USDに等しくなるのに十分なBTCをアリスに送信します。
目標は、各価格変動が不利な側のチャネルを閉じるコストを下回るほど頻繁にリバランスが行われるようにすることです。そうすることで、不利な側のトレーダーは、単に代金を支払って関係を継続するようになります。

Klausingは、トレーダーによっては、このような最小限の信頼関係の方がカストディアルな先物市場よりも好ましいと感じる可能性があることを示唆しています。また、ドル建てのecashを発行する銀行の基盤として利用できる可能性も示唆しています。このスキームは市場価格が決定できるあらゆる資産に対して機能します。

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

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

● サイレントペイメントのリソース: silentpayments.xyz情報サイトや、2つのTypeScriptライブラリ、 Goベースのバックエンド、Webウォレットなどを含む、いくつかのサイレントペイメントのリソースが発表されました。ほとんどのソフトウェアは新しいものや、ベータ版または開発中のものであるため注意が必要です。
● Cake Walletがサイレントペイメントをサポート: Cake Walletは最近、最新のベータリリースでサイレントペイメントのサポートを発表しました。
● コーディネーター不要のcoinjoinのPoC: Emessbeeは、中央のコーディネーターを必要とせずに coinjoinトランザクションを作成する概念実証プロジェクトです。
● OCEANがBOLT12をサポート: OCEANマイニングプールは、ライトニング支払いの一部として、署名付きメッセージを使用してBitcoinアドレスを BOLT12オファーに関連付けます。
● Coinbaseがライトニングをサポート: CoinbaseはLightsparkのライトニングインフラストラクチャを使用して、ライトニングの入出金のサポートを追加しました。
● Bitcoinエスクローツールの発表: BitEscrowチームは、非カストディアルのBitcoinエスクローを実装するための開発ツールのセットを発表しました。
● Blockがマイニングコミュニティへフィードバックの呼びかけ: Blockは、3nmのチップの進捗に関するアップデートの中で、マイニングハードウェアおよびソフトウェアの機能やメンテナンスおよびその他の質問について、マイニングコミュニティからのフィードバックを求めています。
● Sentrumウォレットトラッカーのリリース: Sentrumは、さまざまな通知チャネルをサポートする監視専用ウォレットです。
● Stack WalletがFROSTをサポート: Stack Wallet v2.0.0は、モジュラーFROST Rustライブラリを使用して、 FROST閾値マルチシグのサポートを追加しました。
● トランザクションブロードキャストツールの発表: Pushtxは、トランザクションをBitcoinのP2Pネットワークに直接ブロードキャストするシンプルなRustプログラムです。

リリースとリリース候補

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

● Bitcoin Inquisition 27.0は、signet上でソフトフォークやその他の主要なプロトコル変更をテストするために設計されたBitcoin Coreのこのフォークの最新メジャーリリースです。このリリースの新機能は、BIN24-1とBIP347で定義されたOP_CATのsignetへの適用です。また、「スクリプトのopcodeの動作をテストするために使用できるbitcoin-util用の新しいevalscriptサブコマンド」も含まれています。 annexdatacarrierと疑似エフェメラルアンカーのサポート（ニュースレター#244および#248参照）は終了しました。
● LND v0.18.0-beta.rc2は、この人気の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 #27101では、JSON-RPC 2.0のリクエストとサーバーレスポンスのサポートが導入されています。注目すべき変更点は、HTTPエラーや不正なリクエストがない限り、サーバーは常にHTTP 200 “OK”を返すこと、エラーフィールドまたは結果フィールドのいずれかを返しますが両方を返すことはなく、単一リクエストとバッチリクエストの結果が同じエラー処理動作になることです。リクエストボディでバージョン2.0が指定されていない場合は、従来のJSON-RPC 1.1プロトコルが使用されます。
● Bitcoin Core #30000では、txidの代わりにwtxidでインデックスを作成することで、 txidが同じ複数のトランザクションがTxOrphanage内で共存できるようになります。 orphanageは、Bitcoin Coreが現在アクセスできない親トランザクションのtxidを参照するトランザクションを保存するために使用するサイズが制限されたステージング領域です。そのtxidを持つ親トランザクションを受信したら、子を処理できます。 1p1c（Opportunistic 1-parent-1-child）パッケージ受け入れでは、 orphanageに保存されることを期待して、最初に子トランザクションを送信し、その後親トランザクションを送信します。これにより親子の集約手数料率が考慮されるようになります。

ただ、1p1cがマージされた時（ニュースレター #301参照）、攻撃者は無効なwitnessデータを含むバージョンの子トランザクションを先に送信することで、正直なユーザーがこの機能を使用するのを防ぐことができることが知られていました。その不正な子トランザクションは、正直な子トランザクションと同じtxidを持ちますが、親トランザクションを受信した際に検証に失敗し、パッケージの受け入れが機能するために必要な CPFPパッケージ手数料率に子が貢献できなくなります。

このPR以前は、orphanage内のトランザクションは、txidでインデックス付けされていたため、特定のtxidを持つトランザクションの最初のバージョンがorphanageに保存されるものとなり、正直なユーザーよりも速く頻繁にトランザクションを送信できる攻撃者は、正直なユーザーを無期限にブロックすることができました。このPR後は、それぞれ異なるwitnessデータを持つ（つまり、wtxidが異なる）ものの、 txidが同じ複数のトランザクションを受け入れることができます。それらの親トランザクションを受信すると、ノードは不正な子トランザクションを削除し、有効な子トランザクションに対して期待される1p1cパッケージ受け入れを実行するのに十分な情報を持ちます。このPRについては、以前ニュースレター #301のPR Review Clubの要約で取り上げました。
● Bitcoin Core #28233は、#17487をベースに、ウォームコイン（UTXO）キャッシュの24時間毎の定期的なフラッシュを削除しました。 #17487以前は、ディスクへの頻繁なフラッシュにより、ノードやハードウェアのクラッシュにより時間のかかる再インデックス処理が必要になるリスクが軽減されました。 #17487以降、メモリキャッシュを空にすることなく、新しいUTXOをディスクに書き込むことができるようになりましたが、割り当てられた最大メモリ領域に近づくとキャッシュを空にする必要があります。ウォームキャッシュは、デフォルトのキャッシュ設定のノードのブロック検証速度をほぼ2倍にし、キャッシュに追加のメモリを割り当てたノードでは、さらに性能が向上します。
● Core Lightning #7304では、reply_pathノードへのパスが見つからない場合に、オファースタイルのinvoice_requestsへの返信フローが追加されました。 CLNのconnectdでは、インボイスを含むOnionメッセージを配信するために、リクエストノードへの一時的なTCP/IP接続を開きます。このPRにより、Core LightningとLDKの相互運用性が向上し、少数のノードしかサポートしていない（ニュースレター #283参照） Onionメッセージも使用できるようになります。
● Core Lightning #7063は、手数料の値上げを動的に調整するため、セキュリティマージンの倍率を更新しました。この倍率は、チャネルトランザクションが承認されるのに十分な手数料率を支払うこと保証しようとするもので、（手数料引き上げできないトランザクションの場合は）直接または手数料の引き上げを通じて行われます。この倍率は低レート（1 sat/vbyte）では現在の手数料率の推定の2倍から始まり、手数料率が日次のmaxfeerateに近づくにつれて徐々に1.1倍に減少します。
● Rust Bitcoin #2740は、pow（proof of work）APIにfrom_next_work_requiredメソッドを追加しました。このメソッドは、（以前の難易度ターゲットを表す）CompactTargetと、（現在のブロックと以前のブロックの時間差を表す）timespan、ネットワークパラメーターオブジェクトParamsを受け取り、次の難易度ターゲットを表す新しいCompactTargetを返します。この関数に実装されているアルゴリズムは、pow.cppファイルにあるBitcoin Coreの実装に基づいています。