今週のニュースレターでは、dust limitに関する議論の要約と、 サービスやクライアントソフトウェアの変更点、Taprootへの準備方法、新しいリリースとリリース候補、 および人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点などの恒例のセクションを掲載しています。

ニュース

  • ● dust limitの議論: Bitcoin Coreや他のノードソフトウェアは、 アウトプットの値が一定の金額 （dust limit）以下のトランザクションの中継やマイニングをデフォルトで拒否します （正確な金額はアウトプットの種類によって異なります）。 これにより、ユーザーが不経済なアウトプット（保持する価値より手数料の方が多いUTXO）を作成するのが難しくなります。

    今週、Jeremy RubinはBitcoin-Devメーリングリストに、 dust limitを撤廃するための5つの論点を投稿し、 この制限の理由は「スパム」と「dust fingerprint attack」を防ぐためであるという信念を述べました。 他の人々は、この制限は「スパム」の防止のためにあるのではなく、 ユーザーが決して使用することに経済的なインセンティブを持たないUTXOを作成することで フルノードの運用者のリソースを恒久的に消費するのを防ぐためにあるという反論で応答しました。 議論の一部では、dust limitと不経済なアウトプットの両方がLNの一部に与える影響についても述べられました。

    この記事を書いている時点では、何の合意も得られそうにありませんでした。 少なくとも短期的には、dust limitはこのままだと思われます。

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

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

  • ● Spark Lightning WalletがBOLT12のサポートを追加: Sparkのv0.3.0rcリリースは、 BOLT12のOfferのサポートを追加しました。

  • ● Blockstreamが非カストディ型のLNクラウドサービスGreenlightを発表: Blockstreamは最近のブログ記事で、 ノード運用（Blockstream）とノードが保有する資金の管理（ユーザー）を分離する、 ホスト型のC-Lightning-nodes-in-the-cloudサービスの詳細を発表しました。 SphinxとLastbitは両方とも現在Greenlightサービスを利用しています。

  • ● BitGoがnative segwitのお釣り用アウトプットを発表: Segwitの採用が75%を超えたことを受け、BitGoのブログ記事では、 デフォルトのお釣り用のアウトプットを、P2SHでラップしたものから native segwitのアウトプットに変更することが発表されました。

  • ● Blockstream Green desktop 0.1.10リリース: バージョン0.1.10では、 segwitがデフォルトのシングルシグウォレットと、 手動のコイン選択機能が追加されています。

Taprootの準備 #9: 署名アダプター

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

ある人が、その人の好きな数字を当てることができたら、特定の慈善団体に1,000 BTCを寄付すると申し出たとします。 寄付者がこれを実行する簡単な方法は、1,000 BTCを支払う未署名のトランザクションを作成し、 好きな数字を復号鍵として、そのトランザクションの署名を暗号化したコピーを公開する方法です。

理論的には、数字を推測した人は、署名を復号し、トランザクションをブロードキャストして慈善団体へ支払いができます。 しかし、寄付者がAESのような標準的な暗号化方式を使用している場合、 第三者が復号する前に署名がそのトランザクションに対して有効なものであることを簡単に知る方法はありません。 数字の推測に注力したい人は、寄付者がトロールではなく誠実であることを信頼しなければなりません。

この問題をもう少し拡張してみましょう。第三者であるアリスとボブは、署名が公開されるかどうかを賭けたいとします。 彼らは署名者に署名のハッシュを尋ね、それをHTLC関数内のハッシュとして使用することができますが、 これもまた寄付者が正直に行動することを信頼する必要があります。 最終的に署名が公開されたとしても、寄付者は誤ったハッシュをアリスとボブに与えることで、そのコントラクトを妨害することができます。

アダプターの魔法

署名アダプター（Signature adaptor）は、 アダプター署名（Adaptor signature）やone-time verifiably encrypted signatureとも呼ばれ、 これらの問題を解決するもので、Bitcoin上に構築されたプロダクションシステムで現在実際に直面している多くの問題を解決します。 Bitcoinの既存のECDSA署名方式でも使用可能ですが、 BIP340で実装されているTaproot用のSchnorr署名と組み合わせることで、 アダプターを非公開でコストをかけずに使用することができます。 上の例が、アダプターを使うとどう変わるか見てみましょう。

先程と同様に、寄付者は1,000 BTCのトランザクションを用意します。 ほぼ通常の方法で署名しますが、1つの違いは、基本的に2つのnonceを生成する点です: 永久に秘密にしておく真のランダムnonceと、 もう１つは最初は秘密にしておくけど他の人が発見しても安全な好きな数字です。 寄付者は、これら2つの値を加算し1つのnonceであるかのようにして完全に有効な署名を作成します。

BIP340の署名コミットメントでは、nonceを2つの形式で使用します: 通常署名者のみが知っている数値表現（スカラーと呼ばれる）と、 検証を可能にするために公開される楕円曲線上の点です。

寄付者は、有効な署名コミットメント部を取り出し、隠されたスカラーを減算します。 これにより、署名は不完全（つまり無効）なものになりますが、 寄付者は（無効な）署名コミットメントと、完全なnonceの（有効な）点と、 隠された数字の（有効な）点を共有することができます。 これらの3つの情報を合わせて署名アダプターとします。

BIP340の署名検証アルゴリズムを少し変形し、 隠されたスカラーが（現在は無効な）署名コミットメントに単純に加算された場合、 署名アダプターが有効な署名を提供することを誰もが検証することができます。 これは隠された数字が何であるかを知らなくても検証できます。 要するに、ユーザーはトラストレスに隠されたスカラー値について推測することができるようになり、 正しい推測値により署名を取得しトランザクションを送信することができるという安心感が得られます。

寄付者の署名アダプターを受け取った他の人たちと同様に、アリスとボブは、 隠された数字の楕円曲線上の点のコピーを持っています。 また、他の人と同様、彼らは実際のスカラーを知りません。しかし、思い起こすと、 寄付者が有効な署名を無効な署名に変えるために行ったことは、 隠された数字の点に署名でコミットしながら、隠された数字を署名コミットメントから減算しただけでした。 アリスは、自分が知らないスカラーにコミットせず自分が知っている楕円曲線上の点にコミットすることで、 同じように簡単に（無効な）署名を作ることができます。 アリスは自分のnonceのペアを作り、（無効な）署名を作る際は秘密の形式を使用し、 寄付者の署名アダプターの楕円曲線の点とnonceの公開形式の集約にコミットします。 これにより、ボブに支払いをするトランザクションの署名アダプターが生成されます。 ボブがスカラーを知っていれば、アダプターを有効な署名に変換してトランザクションを送信し、 賭けに勝つことができます。

しかし、ボブはどうやって数字を知るのでしょうか？ 数字を推測した誰かがプレスリリースをするのを待つのでしょうか？いいえ。 寄付者が公開した署名アダプターは、寄付者の実際の署名からスカラーを引いたものであることをもう一度思い出してください。 隠された数字が発見され、誰かが1,000 BTCのトランザクションを送信した場合、 彼らは元の（有効な）署名コミットメントを公開しなければなりません。 ボブは、（有効な）署名コミットメントを取得し、 そこから元の署名アダプターの（無効な）署名コミットメントを減算しスカラーを入手します。 続いて、そのスカラーを使ってアリスのアダプターを有効な署名に変換します。

マルチシグアダプター

前節では、個々のユーザーが署名の作成方法を変更して署名アダプターを生成する方法を示しました。 マルチシグの参加者が同じトリックを使うことも可能です。 署名アダプターを使用する多くの場合、2人のユーザーの協力が必要となるため、これはとても便利です。

例えば、アリスとボブが上のような賭けをする場合、 二人はまず両者のマルチシグでのみ使用可能なスクリプトに資金をデポジットするところから始めるでしょう。 次にアリスは、署名アダプター形式の部分署名を生成できます。 ボブが隠された数字を知った場合、ボブがアリスのアダプターを有効なアリスの部分署名に変換し、 次にボブ自身の部分署名を提供して資金を使用できる完全な署名を作成することができます。

これにより、署名アダプターは一般的なマルチシグと同様の利点を持つことになります。 つまり、単一の署名のように見え、使用するスペースは同じで、手数料を最小限に抑え、 プライバシーとファンジビリティを最大限に高めることができます。

来週のTaprootの準備では、署名アダプターが使用されることが予想される主な方法の１つを紹介します。 Point Time Locked Contracts (PTLC)は、LNやcoinswap、 その他の多くのプロトコルで広く使われているHash Time Lock Contracts (HTLC)をアップグレードしたものです。

リリースとリリース候補

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

  • ● Bitcoin Core 22.0rc2は、 このフルノード実装とそれに付随するウォレットおよび他のソフトウェアの次のメジャーバージョンのリリース候補です。 この新バージョンの主な変更点は、I2P接続のサポート、 Tor v2接続の廃止、ハードウェアウォレットのサポートの強化などです。

  • ● Bitcoin Core 0.21.2rc1は、 Bitcoin Coreのメンテナンス版のリリース候補です。 いくつかのバグ修正と小さな改善が含まれています。

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

今週の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 #22642は、次期バージョン22.0のBitcoin Coreのリリースプロセスを更新し、 バイナリの再現可能ビルドを行った 全員のGPG署名をバッチ検証（例）可能な単一のファイルに連結しました。 決定論的にビルドした人の署名は何年も前から入手可能でしたが、これによりアクセスしやすくなり、 プロジェクトのリードメンテナーがリリースバイナリに署名するという既存の依存関係も軽減されるでしょう。

  • ● Bitcoin Core #21800は、mempoolにおけるパッケージ受け入れの祖先と子孫の制限を実装しています。 Bitcoin Coreは、DoS攻撃に対する保護として、またマイナーがブロックの構築を扱いやすくするため、 mempool内の関連トランザクションの数を制限しています。 デフォルトでは、この制限によりmempool内のトランザクションは、 mempool内にある関連する祖先と合わせて25トランザクションもしくはサイズが101KvB weightを超えることができません。 同じルールがmempoolの子孫にも適用されます。

    これらの親子関係の制限は、トランザクションをmempoolに追加する際に適用されます。 トランザクションを追加することでいずれかの制限を超える場合、トランザクションは拒否されます。 パッケージのセマンティクスは確定していませんが、 #21800は、任意のパッケージの検証をするための親子関係の制限のチェックを実装しています （つまり、複数のトランザクションが同時にmempoolに追加される際の検討）。 mempoolパッケージの受け入れは、#20833でテスト用にのみ実装されていましたが、 最終的には、パッケージリレーの一部としてP2Pネットワーク上で公開される予定です。

  • ● Bitcoin Core #21500は、privateパラメーターでlistdescriptorsRPCを更新し、 これがセットされている場合、各descriptorのプライベート形式を返します。 プライベート形式には、既知の秘密鍵や、拡張秘密鍵（xprv）が含まれており、 この更新されたコマンドを使ってウォレットをバックアップすることができます。

  • ● Rust-Lightning #1009は、チャネルの設定オプションにmax_dust_htlc_exposure_msatを追加し、 これにより金額がdust limitを下回る保留中の”dusty HTLCs”の合計残高が制限されます。

    この変更は、提案されているoption_dusty_htlcs_uncounted feature bitに備えるものです。 これは、ノードがmax_accepted_htlcsに対して”dusty HTLCs”をカウントしないことを配信します。 max_accepted_htlcsは、主に強制クローズが発生した場合のオンチェーントランザクションの潜在的なサイズを制限するために使われていますが、 “dusty HTLCs”はオンチェーンでは請求できず最終的なトランザクションサイズに影響を与えることがないため、 ノード運用者はこのfeature bitを採用したいと考えています。

    新たに追加されたチャネルの設定オプションmax_dust_htlc_exposure_msatにより、 option_dusty_htlcs_uncountedがオンになっていても、 ユーザーは”dusty HTLCs”の総残高を制限することができます。 この残高は強制クローズの際にマイナーへの手数料として失われてしまうからです。