/ home / newsletters /
Bitcoin Optech Newsletter #351
今週のニュースレターでは、secp256k1と互換性のある新しい集約署名プロトコルの発表と、 ウォレットディスクリプター用のバックアップスキームの標準化について掲載しています。 また、Bitcoin Stack Exchangeでの最近の質問とその回答や、 新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など 恒例のセクションも含まれています。
ニュース
-
● secp256k1互換の対話型集約署名: Jonas Nick、Tim RuffingおよびYannick Seurinは、 Bitcoinで既に使われている暗号プリミティブと互換性のある64 byteの集約署名の作成に関する 論文をBitcoin-Devメーリングリストで発表しました。 集約署名は、インプットをまたいだ署名の集約CISA(cross-input signature aggregation)の暗号要件です。 インプットが複数あるトランザクションのサイズを縮小し、 CoinjoinやPayjoinによるプライバシーが強化された支払いを含む、 さまざまな支払いのコストを削減できる可能性があります。
著者らが提案したDahLIASのような集約署名スキームに加えて、 BitcoinにCISAのサポートを追加するためにはコンセンサスの変更が必要で、 署名の集約と他の提案中のコンセンサスの変更との間の相互作用については、 さらに研究が必要かもしれません。
-
● ウォレットディスクリプター用のバックアップの標準化: Salvatore Ingalaは、ウォレットディスクリプターのバックアップに関連するさまざまなトレードオフと、 複雑なスクリプトを使っているものを含む多くの異なるタイプのウォレットに有用なスキームの提案を Delving Bitcoinに投稿しました。彼のスキームでは、 決定論的に生成された32 byteのシークレットを使ってディスクリプターを暗号化します。 ディスクリプター内の各公開鍵(または拡張公開鍵)に対して、 シークレットのコピーと公開鍵をXOR演算し、n 個の公開鍵に対して、 n 個の32 byteの暗号シークレットが作成されます。 ディスクリプターで使われている公開鍵の1つを知っている人は、 その公開鍵と暗号シークレットをXOR演算することで、ディスクリプターを復号できる32 byteのシークレットを取得できます。 このシンプルで効率的なスキームにより、誰でも複数のメディアやネットワーク上の場所にディスクリプターの暗号化コピーを多数保存し、 BIP32ウォレットシードを使ってxpubを生成することで、 ウォレットデータを紛失した場合でも、ディスクリプターを復号できます。
Bitcoin Stack Exchangeから選ばれたQ&A
Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに(もしくは他のユーザーの質問に答える時間がある場合に)アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。
-
● 半集約型Schnorr署名の実用性は? Fjahrは、CISA(cross-input signature aggregation)において半集約型署名を検証するために、 独立した非集約署名がなぜ必要ないのか、そして非集約署名が実際に問題となり得る理由について議論しています。
-
● これまでに作成されたOP_RETURNペイロードの最大サイズは? Vojtěch Strnadは、79,870 byteが最大の
OP_RETURN
であるRunesのメタプロトコルトランザクションのリンクを提供しています。 -
● LN以外でのpay-to-anchorの説明は? Murchは、P2A(pay-to-anchor)アンカーアウトプットスクリプトの 論拠と構造について詳細に説明しています。
-
● チェーンの再編成に関する最新の統計は? 0xb10cとMurchは、stale-blocksリポジトリ、 forkmonitor.infoウェブサイトおよびfork.observerウェブサイトを含む再編成のデータソースを示しています。
-
● ライトニングチャネルは常にP2WSHですか? Polespinasaは、進行中のP2TR Simple Taproot Channelの開発について言及し、 ライトニング実装間での現在のサポート状況をまとめています。
-
● 二重支払いに対する防御策としてのChild-pays-for-parent? Murchは、既に承認済みの二重支払いアウトプットに対する防御策として、 高額な手数料のCPFP子トランザクションを使ってブロックチェーンの再編成を促すことの複雑さをリストアップしています。
-
● CHECKTEMPLATEVERIFYはどの値をハッシュしますか? Average-grayは、OP_CHECKTEMPLATEVERIFYがコミットするフィールドを概説しています。 nVersion、nLockTime、インプットの数、シーケンスのハッシュ、アウトプットの数、 全アウトプットのハッシュ、インプットのインデックス、場合によってはscriptSigのハッシュ。
-
● ライトニングノードが、ルーティング効率を向上させるためにチャネル残高を開示できないのはどうしてですか? Rene Pickhardtは、データの古さと信頼性、プライバシーへの影響に関する懸念について説明し、 2020年の同様の提案を指摘しています。
-
● 耐量子暗号にはハードフォークとソフトフォークどちらが必要ですか? Vojtěch Strnadは、耐量子暗号(PQC)署名方式を ソフトフォークで有効化する方法、 そしてハードフォークまたはソフトフォークで量子コンピューターに対して脆弱なコインをロックする方法について概説しています。
リリースとリリース候補
人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。
- ● LND 0.19.0-beta.rc3は、この人気のLNノードのリリース候補です。 おそらくテストが必要な主な改善の1つは、協調クローズにおける新しいRBFベースの手数料引き上げです。
注目すべきコードとドキュメントの変更
最近の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およびBINANAsの注目すべき変更点。
-
● Bitcoin Core #31247は、BIP373で定義されている MuSig2のPSBTフィールドのシリアライズとパース処理をサポートし、 ウォレットがMuSig2インプットに署名して使用できるようにします。 入力側には、参加者の公開鍵をリストするフィールドに加えて、各署名ごとに別々の公開ナンスフィールドと 部分署名フィールドが含まれます。出力側は、新しいUTXOの参加者の公開鍵をリストする単一のフィールドです。
-
● LDK #3601は、標準のBOLT4エラーコードを表す新しい
LocalHTLCFailureReason
列挙型と、 以前はプライバシー上の理由から削除されていたユーザーへの追加情報を表示するいくつかのバリエーションを追加しています。
もっと知りたいですか?
このニュースレターで言及されたトピックについてもっと議論したい方は、 (ニュース レターが公開された翌日の)木曜日の15:30 UTCから Riverside.fmで毎週開催されているBitcoin Optech Recapにご参加ください。この議 論は録画もされ、ポッドキャストページからご覧いただけます。