今週のニュースレターは、Bitcoinのトランザクションを圧縮する新しい手法と、 トランザクションの共同署名のプライバシーを強化するアイディアを掲載しています。 また、新しいリリースとリリース候補の発表や、人気のあるBitcoinインフラストラクチャソフトウェアの 注目すべき変更など恒例のセクションも含まれています。

ニュース

• ● Bitcoinトランザクションの圧縮: Tom Briarは、 圧縮したBitcoinトランザクションのドラフト仕様と実装案を Bitcoin-Devメーリングリストに投稿しました。 より小さなトランザクションは、衛星やステガノグラフィー（トランザクションをビットマップ画像にエンコードするような）など、 帯域幅に制限のある媒体を介してリレーするのにより実用的です。 従来の圧縮アルゴリズムは、他の要素よりも頻繁に出現するいくつかの要素を持つ構造化データを利用します。 しかし、一般的なBitcoinのトランザクションは、 ランダムな値に見える公開鍵やハッシュダイジェストなど、均一な要素で構成されています。

  Briarの提案は、いくつかのアプローチを使ってこれに対処しています:

  • 現在整数が4バイトで表現されているトランザクションの部分（トランザクションのバージョンやOutPointのインデックス）を、 2ビット程度の可変長整数に置き換えます。

  • 各インプット内の一様に分散した32バイトのOutPointのtxidは、 ブロックの高さとブロック内の位置を使って、ブロックチェーンにおけるそのトランザクションの位置への参照に置き換えます。 たとえば、123456と789は、ブロック123,456の789番目のトランザクションを示します。 特定の高さのブロックは、ブロックチェーンの再編成によって変更される可能性があるため（参照が壊れ、トランザクションを展開できなくなります）、 この方法は参照されるトランザクションに少なくとも100回の承認がある場合にのみ使用されます。

  • 署名と33バイトの公開鍵をwitnessに含める必要があるP2WPKHトランザクションの場合、 公開鍵は省略され、代わりに署名から公開鍵を再構築する手法が使用されます。

  他のいくつかの手法は、典型的なトランザクションにおいて数バイトの余分なスペースを節約するために使用されます。 この提案の一般的な欠点は、圧縮されたトランザクションをフルノードや他のソフトウェアが使用できるように変換するのに、 通常のシリアライズされたトランザクションよりも多くのCPU、メモリおよびI/Oが必要になることです。 つまり、高帯域幅の接続では引き続き通常のトランザクション形式を使用し、 低帯域幅の送信のみが圧縮されたトランザクションを使用することになるでしょう。

  このアイディアについては、適度な議論が行われましたが、そのほとんどは、 インプット毎に追加されるスペースを少しでも節約するためのアイディアについてでした。

• ● 共同署名のプライバシーの強化: Nick Farrowは、 FROSTのようなスクリプトレスな閾値署名方式が、 共同署名サービスを利用する人々のプライバシーをどのように向上させることができるかについて、 Bitcoin-Devメーリングリストに投稿しました。 共同署名サービスの一般的なユーザーは、セキュリティのために別々に保管された複数の署名鍵を持っています。 しかし、通常の支払いを簡単にするため、自分の一部の鍵と、 何らかの方法でユーザーを認証した後にのみ署名する1つまたは複数のサービスプロバイダーが保持する1つまたは複数の鍵の組み合わせによって、 アウトプットを使用することを許可しています。ユーザーは、必要であればサービスプロバイダーを迂回することもできますが、 ほとんどの場合、サービスプロバイダーは運用を簡単にします。

  2-of-3のOP_CHECKMULTISIGのようなスクリプトによる閾値署名方式では、 サービスの公開鍵は支払いに使用するアウトプットに関連付けられる必要があるため、 どのサービスもオンチェーンデータを見ることで、署名したトランザクションを見つけることができ、 ユーザーに関するデータを蓄積することができます。さらに悪いことに、 現在使用されているプロトコルはすべて、 サービスプロバイダーが署名する前にユーザーのトランザクションを直接明かしてしまうため、 サービス側は特定のトランザクションへの署名を拒否することができます。

  Farrowが説明するように、FROSTは、アウトプットスクリプトの生成から署名、 完全に署名されたトランザクションの公開に至るまで、プロセスのすべての段階で、 サービスに署名済みトランザクションを隠すことができます。 サービスが知ることができるのは、いつ署名したかと、 ユーザーがサービスとの認証のために提供したデータだけです。

  このアイディアは、メーリングリストでいくつか議論されました。

リリースとリリース候補

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

• ● Libsecp256k1 0.4.0は、Bitcoin関連の暗号操作のためのこのライブラリの最新リリースです。 新バージョンには、ElligatorSwiftエンコーディングを実装したモジュールが含まれています。 詳細は、プロジェクトの変更履歴をご覧ください。

• ● LND v0.17.0-beta.rc2は、この人気のLNノード実装の次期メジャーバージョンのリリース候補です。 このリリースで予定されている主な実験的な新機能は、テストの恩恵を受ける可能性が高そうな、 「Simple taproot channel」のサポートです。

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

今週の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の注目すべき変更点。

• ● Bitcoin Core #28354は、testnetの-acceptnonstdtxnのデフォルト値を0に変更しました。 この変更は、アプリケーションがmainnetのデフォルトノードで拒否される非標準トランザクションを作成するのを回避するのに役立つ可能性があります。

• ● LDK #2468により、ユーザーはインボイスリクエストのメタデータフィールドに暗号化されたpayment_idを指定できるようになりました。 LDKは受け取ったインボイスのメタデータをチェックし、そのIDを認識し、まだ別のインボイスで支払いをしていない場合にのみ支払いを行います。 このPRは、BOLT12の実装に向けたLDKの作業の一部です。