今週のニュースレターでは、場合によっては値がゼロのアウトプットのトランザクションのリレーを可能にする提案と、 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達が疑問に対して答えを探しに(もしくは他のユーザーの質問に答える時間がある場合に)アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。

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

今週のBitcoin CoreC-LightningEclairLNDRust-Lightninglibsecp256k1Hardware Wallet Interface (HWI)Rust BitcoinBTCPay ServerBDKBitcoin 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日(水)からは通常の発行に戻ります。