/ home / newsletters /
Bitcoin Optech Newsletter #179
今週のニュースレターでは、場合によっては値がゼロのアウトプットのトランザクションのリレーを可能にする提案と、 PTLCの採用に向けたLNの準備に関する議論のまとめを掲載しています。 また、サービスやクライアントソフトウェアの最近の変更のリストや、 Bitcoin Stack Exchangeで人気のある質問、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点などの恒例のセクションも含まれています。
ニュース
-
● 特定の経済合理性のないアウトプット用の特別な例外の追加: ニュースレター #162の掲載以来、Jeremy RubinはBitcoin-Devメーリングリストで、 トランザクションがdust limit以下の値のアウトプットを作成することを認めることについて、 議論を更新しました。dust limitは、 ユーザーに経済的に意味のないUTXOの作成を思いとどまらせるために ノードが使用するトランザクションのリレーポリシーです。 UTXOは使用されるまで、少なくともいくつかのフルノードで保管され、 場合によっては迅速に取得できるため、経済合理性のないアウトプットを許可すると、 正当な理由もなく問題が発生する可能性があります。
しかしCPFPによる手数料の引き上げにおいては、 手数料を引き上げるトランザクションの資金を使用できない場合、 eltooみたいに、手数料の引き上げに使用される資金を別のUTXOから取得する必要がある場合、 ゼロ値のアウトプットを使うことができるかもしれません。 Ruben Somsenはまた、ゼロ手数料アウトプットが(one-wayペグのサイドチェーンの一種である)spacechainにどう役立つかの例も示しました。
この記事を書いている時点では、議論に明確な結論は出ていません。
-
● PLTC用のLNの準備: Bastien Teinturierは、Lightning-Devメーリングリストで、 ノードがPTLCを使用するようアップグレードするために必要な、 LNの通信プロトコルの最小限の変更に関するスレッドを立ち上げました。 PTLCは、現在使用中のHTLCよりもプライベート性が高く、ブロックスペースも少なくて済みます。
Teinturierは、提案中の
option_simplified_update
プロトコルの変更(ニュースレター #120参照)と同時に実行できる一連の変更を作成しようとしています。 2つめの目標は、通信プロトコルをニュースレター #152に掲載した fast-forwardベースのPTLCプロトコルと互換性のあるものにすることです。 これによりノードは、最初にHTLCでoption_simplified_update
を使用して、 次にPTLC、それからfast-forwardへ段階的にアップグレードすることができるようになります。
サービスとクライアントソフトウェアの変更
この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。
-
● Simple Bitcoin WalletがTaprootへの送金をサポート: SBWのバージョン 2.4.22では、ユーザーがTaprootアドレスに送金できるようになりました。
-
● Trezor SuiteがTaprootをサポート: Trezorは、Trezor Suiteのバージョン21.12.2でTaprootをサポートすると発表しました。 最新のクライアントとファームウェアをダウンロードすると、ユーザーは新しいTaprootアカウントを作成することができます。
-
● BlueWalletがTaprootへの送金をサポート: BlueWallet v6.2.14はTaprootアドレスへの送金をサポートしました。
-
● Cash AppがTaprootへの送金をサポート: 2021年12月1日より、Cash Appユーザーはbech32mアドレスに送金できるようになりました。
-
● SwanがTaprootへの送金をサポート: Swanは、Taprootでの引き出し(送金)のサポートを発表しました。
-
● Wallet of SatoshiがTaprootへの送金をサポート: モバイルのBitcoinおよびLightningウォレットであるWallet of Satoshiが、 Taprootへの送金のサポートを発表しました。
Bitcoin Stack Exchangeから選ばれたQ&A
Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに(もしくは他のユーザーの質問に答える時間がある場合に)アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。
-
● P2TR支払い(Taprootからの支払い)におけるScriptの組み立てや実行とは? Pieter Wuilleは、BIP341の簡略化した例で、Taprootアウトプットの構築、keypathを使った支払い、 scriptpathを使った支払い、支払いの検証について詳細な解説をしています。
-
● mainnetでP2TRトランザクションのサンプルを見つけるにはどうしたらいいですか? Murchは、最初のP2TRトランザクション、scriptpathとkeypathをインプットとした最初のトランザクション、 複数のkeypathインプットを持つ最初のトランザクション、2-of-2のマルチシグのscriptpathでの最初の支払いトランザクション、 新しいTapscriptの
OP_CHECKSIGADD
opcodeを最初に使用しているトランザクションに関する ブロックエクスプローラーのリンクを示しています。 -
● マイナーがマイニング中にブロックにトランザクションを追加すると、ブロックのPoWはリセットされますか? Pieter Wuilleは、マイニングには進捗というものがないと説明しています。 ブロックを解くための各ハッシュの試行は、現在マイニング中のブロックに新しいトランザクションが追加された場合も含めて、 これまでに行われた作業から独立しています。
-
● Schnorrの集約署名を他のSchnorrの集約署名内にネストすることは可能ですか? Pieter Wuilleは、Schnorr署名を用いた鍵の集約スキームの実現可能性について 「署名者に’姪/甥’の鍵の知識がなくても、鍵を階層的に集約することができる」と説明しています。 彼は、MuSig2がネストと互換性を持つように設計されており、 セキュリティの証明は存在しないものの、このユースケースに合わせて変更することができると述べています。
注目すべきコードとドキュメントの変更
今週の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 #23716は、Bitcoin CoreのテストコードにRIPEMD-160のネイティブなPython実装を追加しています。 これにより、Bitcoin Coreは、OpenSSLのRIPEMD-160実装をラップしたPythonの
hashlib
ライブラリのRIPEMD-160関数を使用しなくなりました。 OpenSSLの新しいバージョンでは、デフォルトでRIPEMD-160のサポートが提供されなくなったため、別途有効にする必要があります。 -
● Bitcoin Core #20295は、新しいRPC
getblockfrompeer
を追加し、 特定のピアから特定のブロックを手動で要求できるようになりました。 このRPCの用途は、フォークの監視や研究目的で、古くなったchaintipを取得することです。 -
● Bitcoin Core #14707は、複数のRPCを更新し、 マイナーのコインベーストランザクションのアウトプットから受信したビットコインを含めるようにしました。 RPCの新しい
include_immature_coinbase
オプションにより、 成熟する(コンセンサスルールにより最も早く使用可能になる100承認)前のコインベーストランザクションを 含めるかどうかを切り替えられるようになりました。 -
● Bitcoin Core #23486は、ScriptがP2SHもしくはP2WSHで使用できる場合にのみ、 ScriptのP2SHアドレスもしくはP2WSHアドレスを返すよう
decodescript
RPCを更新しました。 -
● BOLTs #940は、
node_announcements
でTor v2 onionのアナウンスとパースを非推奨にしました。 Rust-Lightning #1204も、今週マージされ、この仕様に従うように実装を更新しています。 -
● BOLTs #918は、pingメッセージのレート制限を削除しました。
ping
メッセージは、 主にピアの接続がまだ生きているかどうかを確認するために使われます。 このマージ以前は、ping
メッセージは、最大で30秒に1回送信されるものでした。 多くのノードでは、高品質のサービスを保証するために、ping
によるハートビートメッセージをより頻繁に送信することが有用です。 他のLightningメッセージはレート制限されていないため、ping
メッセージの30秒のレート制限も撤廃されました。 -
● BOLTs #906では、ニュースレター #165に掲載した、
channel_type
機能に新しいfeature bitが追加されています。 このbitを追加することで、将来のノードが新機能を理解したピアだけを選択することが簡単になります。
年末年始の発行スケジュール
Happy holiday! 今号が年内最後の定期的なニュースレターになります。 来週は、毎年恒例の1年を振り返る特別号を発行します。 1月5日(水)からは通常の発行に戻ります。