今週のニュースレターでは、サービスとクライアントソフトウェアの最近の変更点や、 ウォレットがTaprootアドレスを生成する前に待つ必要がある理由、 新しいソフトウェアのリリースとリリース候補のリストおよび、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更の要約を掲載しています。

ニュース

今週は重要なニュースはありません。

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

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

  • ● Lightning機能搭載のニュースサイトStacker Newsがスタート: LNURL認証やLNマイクロペイメントによる投票やコメントが可能な オープンソースのニュースサイトStacker Newsが開設されました。

  • ● SuredbitsがDLCウォレットのアルファリリースを発表: Suredbitsのbitcoin-sソフトウェアには、GIUが含まれ、 Bitcoinブロックチェーン上でオラクルを使用したDiscreet Log Contracts (DLCs)を実行することができます。 発表では、LN互換のDLCを実装するために、 Schnorr署名と Point Time Locked Contracts (PTLCs)を使用することも計画していると述べています。

  • ● Sparrow 1.4.3がP2TRをサポート: Sparrowの1.4.3リリースは、signetおよびregtestで、 シングルシグのP2TRウォレットをサポートします。 このリリースでは、P2TRのbech32mアドレスへの送信もサポートされています。

  • ● Coldcard FirmwareがSeed XOR機能を追加: Coldcardの4.1.0 Firmwareは、 各パーツが独自のウォレットとして機能するBIP39シードを分割/結合する方法であるSeed XORをサポートします。 XORで結合されたパーツは、ウォレットとしても機能します。 これにより、ハニーポッド資金やもっともらしい否認などの機能が可能になります。

  • ● BlueWalletがLightning Dev Kitを統合: BlueWalletは、Lightning Dev Kit (LDK)を使用する新しいLightning実装への移行を発表しました。

Taprootの準備 #5: なぜ待つ必要があるのか？

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

これまでの連載では、ウォレットやサービスの開発者に対してTaprootがアクティベートされた時に備えて、 Taprootのアップグレードを今から実装するよう呼びかけてきました。 しかし、サービスやユーザーが損失を被る可能性があるため、 ブロック709,632より前にP2TR用のアドレスを生成しないよう警告しました。

事前にアドレスを生成しない理由は、P2TRスタイルのアウトプットへの支払いは、 ブロック709,632より前では誰でも使用できるためです。 お金は完全に安全ではなくなります。 しかし、そのブロックになると何千ものフルノードがBIP341およびBIP342 （そして関連するBIP340）のルールの適用を開始します。

ブロックチェーンの再編成がないことが保証されているのであれば、 最後のTaproot前のブロック（ブロック709,631）が確認できた時点でP2TRアドレスの生成を始めても安全でしょう。 しかし、ブロックチェーンの再編成については懸念すべき理由があります。 偶然の再編成だけでなく、初期のP2TR支払いからお金を奪うために意図的に作られる再編成もあるためです。

P2TRの支払いを最初に受け取ろうとする大勢の人々を想像してみてください。 ブロック709,631が確認できるとすぐに彼らは単純にいくらかのお金を送信します。1 これらの支払いは、ブロック709,632では安全ですが、 ブロック709,631に代わるブロックを作成したマイナーによって盗まれる可能性があります。 P2TRアウトプットへ送られるお金の価値が十分に大きければ、 1つのブロックではなく2つのブロックをマイニングしようとする方が簡単に利益を得られる可能性があります （詳細はトピックフィー・スナイピングを参照）。

この理由から、再編成のリスクが効果的に解消されたと思われるまでは、 ソフトウェアやサービスでP2TR用のアドレスを生成することはお勧めしません。 アクティベーションから144ブロック（約1日）待つことは、 あなたやあなたのユーザーがTaprootの利点を利用するのを大幅に遅らせることなく、 リスクを最小限に抑えることができる、適度に保守的なマージンだと考えています。

まとめると:

  • 709,631: P2TRスタイルのアウトプットに送信されたお金を誰でも使うことができる最後のブロック
  • 709,632: P2TRアウトプットがBIP341とBIP342のルールを満たす場合にのみ使用できる最初のブロック
  • 709,776: ウォレットがユーザーにP2TRアウトプット用のbech32m受信アドレスを提供し始めるのに適したブロック

上記はいずれも、できるだけ早くbech32mアドレスへの支払いを可能にするという、 このシリーズの最初のパートで提供されたアドバイスを変更するものではありません。 安全だと思う前にP2TR用のアドレスを要求した場合、それは彼らのリスクです。

リリースとリリース候補

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

  • LND 0.13.1-betaは、0.13.0-betaで導入された機能のマイナーな改善とバグ修正を含むメンテナンスリリースです。

  • ● Rust-Lightning 0.0.99は、いくつかのAPIや設定の変更を行ったリリースです。 詳細はリリースノートをご覧ください。

  • ● Eclair 0.6.1は、パフォーマンスの向上や、 いくつかの新機能、いくつかのバグ修正を含む新しいリリースです。 そのリリースノートに加えて、 以下の注目すべき変更セクションのEclair #1871 と #1846 の説明をご覧ください。

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

今週の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 #22112では、I2Pアドレスの想定ポートを（ IPv4およびIPv6アドレスのデフォルトである）8333ではなく0に変更し、 0以外のポートのI2Pアドレス接続を防止しています。 （Bitcoin Coreがサポートする）SAM v3.1仕様には、ポートの概念が含まれていません。 ポートの概念を含むSAM v3.2をサポートするようBitcoin Coreが更新された場合、 この制限は解除される可能性があります。

  • ● C-Lightning #4611は、プライグインが提供するkeysend RPCを更新し、 未公開のチャネルに支払いをルーティングするための情報を提供できるroutehintsパラメーターを追加しました。

  • ● C-Lightning #4646は、古い動作の削除にむけて2つの変更を行いました。 1つめの変更は、ノードが2019年に追加されたTLVスタイルのエンコーディング （ニュースレター #55参照）をサポートしていることを前提とします。 TLVエンコーディングをサポートしていないことを明示的に示すノードのみが異なる方法で処理されます。 2つめの変更は、ペイメントシークレットが必要になります（以前の議論についてはニュースレター #75を、 LNDが要求を開始した時期についてはニュースレター #126参照）。

  • ● C-Lightning #4614は、listchannelsRPCを更新し、 要求されたノードにつながるチャネルのみを返すのに使用できる新しいオプションのdestinationパラメーターを追加しました。

  • ● Eclair #1871では、SQLiteの設定を変更し、 1秒間に処理できるHTLCの数を5倍に増やし、データ損失に対する堅牢性も高めました。 このPRでは、さまざまなノードソフトウェアのHTLCのスループットを比較したJoost Jagerのブログ記事を参照しています。

  • ● Eclair #1846では、 リモートピアが同意する新しいチャネルをネゴシエートする際にノードが指定するアドレスが、 後でチャネルを協力して閉じる際に使用できる唯一のアドレスとなる upfront shutdown scriptを使用するためのオプトインサポートが追加されました。 この機能のLNDの実装について掲載しているニュースレター #76もご覧ください。

  • ● Rust-Lightning #975では、 ベースの支払い転送手数料をデフォルトの1 satoshi（2021年7月の市場レート）で設定できるようにしました。 LNのルーティングノードは、支払いをルーティングするために固定のベース手数料と ルーティングされた金額のパーセンテージの2つの手数料を請求することができ、多くのノードは両方使用します。 以前のRust-Lightningは、ベース手数料をHTLCをオンチェーンで決済するために必要な推定手数料に設定していましたが、 これは1 satよりもはるかに高いものでした。

  • ● BTCPay Server #2462では、インスタンスの運用者が自分の個人的なウォレットを使って返金する場合など、 別のウォレットから行われた支払いを追跡するためにBTCPayを使用するのが容易になりました。

Footnotes

  1. 最初のTaprootブロックでP2TR支払いを受けたいユーザーは、 誰にも教えずにアドレスを生成し、そのアドレス宛にnLockTimeを709,631に設定したトランザクションを作成してください。 このトランザクションは、ブロック709,631を受信するとすぐにブロードキャストできます。 nLockTimeは、そのトランザクションがTaprootのルールが提供される709,632より前のブロックに含まれないことを保証します。 新しいスクリプトタイプやカスタムlocktimeに手を出すのは、 それが何をしているのか分からない場合には危険なので気をつけてください。 ↩