今週のニュースレターでは、BIP70のペイメントプロトコルの一部の機能について期待される代替案に関する議論と、 Discreet Log Contract (DLC)の不正の証明（Fraud Proof）を交換するための標準化された方法の提案の要約を掲載しています。 また、新しいソフトウェアリリースや利用可能なリリース候補、 人気のBitcoinインフラストラクチャソフトウェアの注目すべき変更点について説明する通常のセクションも含まれています。

ニュース

• ● BIP70の代替に関する議論: Thomas Voegtlinは、BIP70ペイメントプロトコルの一部の機能、 特に署名された支払い要求を受信する機能の代替について、 Bitcoin-Devメーリングリストでスレッドを開始しました。 Voegtlinは、彼が支払いをしたアドレスが実際に（取引所などの） 受信者によって提供されたアドレスであることを証明できるようにしたいと考えています。 Charles HillとAndrew Kozlikは、それぞれが取り組んでいるプロトコルに関する情報を返信しました。 Hillのスキームは、LNURLでの使用を意図したものですが、 Voegtlinの意図したユースケースに再利用することができます。Kozlikのスキームは、 BIP70の精神に近いものの、X.509証明書の使用をやめ、 取引所ベースのコインスワップの機能（例：BTCをアルトコインと取引する、もしくはその逆）を追加します。

• ● v0 Discreet Log Contract (DLC)の仕様における不正の証明: Thibaut Le Guillyは、バージョン0のDLCの仕様に不正の証明を含めるという目標について、 DLC-devメーリングリストで議論を開始しました。そこでは2種類の不正について議論されました:

  • ● 多義性: オラクルが同じイベントに複数回署名し、矛盾する結果を生成する不正。 この不正の証明は、第三者を信用することなく、ソフトウェアによって自動的に検証できます。

  • ● 偽り: オラクルが、ユーザーが間違いだと分かっている結果に署名する不正。 これはほとんどの場合、ユーザーのコントラクトソフトウェアが利用できない証拠に依存するため、 この種の不正の証明は、元のコントラクトとオラクルが署名した結果を比較できるユーザーが、 手動で検証する必要があります。

  議論の参加者は全員、v0の仕様に対して手間がかかりすぎるのではないかという懸念がありましたが、 多義性に対する証明の提供に賛成しているようでした。中間段階の解決策として、 偽りに対する不正の証明へ焦点をあてる提案がされました。 これらの証明の形式が確立されると、ソフトウェアを更新して、 同じオラクルとイベントに対する2つの偽りに対する不正の証明を利用して、多義性の証明を作成できるようになります

  偽りの証明に関する１つの懸念事項は、ユーザーが偽の証明によってスパムを受け、 偽の証明の検証に時間を浪費するか、不正の証明の検証を完全に放棄せざるをえなくなる可能性があることです。 反論には、オンチェーン・トランザクションから証明の一部を取得できること（誰かがオンチェーン手数料を支払う必要がある）、 ユーザーが不正の証明をダウンロードする場所を選択でき、 正確な情報のみを配信することで知られているソースから取得することを好むことが含まれていました。

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

今週の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 #16546では、新しい署名者用のインターフェースが導入され、 Bitcoin Coreが、HWIや同じインターフェースを実装した他のアプリケーションを介して、 外部のハードウェア署名デバイスと連携できるようになりました。

  Bitcoin Coreは、Bitcoin Core バージョン 0.18以降、 HWIを使用してハードウェア署名者と連携できるようになりました。 しかし、このPRまでは、Bitcoin CoreとHWIの間でデータを転送するのにコマンドラインを使用する必要がありました。 このPRでは、Bitcoin CoreがHWIと直接通信できるようにすることで、ユーザーエクスペリエンスを簡単にします。 このPRには、HWIと新しい署名者用インターフェースを使用する方法について完全なドキュメントが含まれています。

  新しい署名者用インターフェースは、現在のところRPCでしかアクセスできません。 GUIに署名者用インターフェースのサポートを追加するPRのドラフトでは、 コマンドラインを使用することなくBitcoin Coreでハードウェア署名者を使用できるようになっています。

• ● Rust-Lightning #791は、 起動時にBlockSourceインターフェースをポーリングしてブロックとヘッダーを同期するためのサポートを追加し、 同期中にフォークを検出します。ニュースレター #135で説明したように、BlockSourceを使用すると、 ソフトウェアが標準的なBitcoin Core互換ノード以外のソースからデータを取得できるようになるため、 エクリプス攻撃や他のセキュリティ問題を防ぐのに役立つ冗長性が得られます。

• ● Rust-Lightning #794では、シャットダウン開始時に将来のsegwitバージョンを許可する BOLT2のoption_shutdown_anysegwit機能のサポートを有効にします。 option_shutdown_anysegwitがネゴシエートされた場合、 チャネルを閉じるためにシャットダウンメッセージを送信するチャネル参加者は、 version byte（OP_1からOP_16の1バイトのプッシュopcode）に witness program（2〜40バイトのバイトベクトルのプッシュ）が続く標準的なBIP141 witness program形式に準拠している 支払い用のscriptpubkeyを送信することができます。 これらのシャットダウンスクリプトは、高額な手数料がかかるスクリプトや 非標準であるため伝播しない巨大なスクリプトを持つトランザクションを避けるため、標準形式に限定されています。 （2019年11月にリリースされた）Bitcoin Core 0.19.0.1で任意のsegwitスクリプトへの支払いの中継が可能になったため、 LNの標準形式にそれらを含めるのが安全になりました。

• ● HWI #413、#469、#463、#464、 #471、#468および#466では、 HWIのドキュメントが大幅に更新、拡張されています。特に注目すべき変更点は、 ReadTheDocs.io上のドキュメントへのリンク、新規のまた更新された例、 新しいデバイスがHWIにサポートされるために満たすべき基準を記述した新しいポリシーなどです。

• ● Rust Bitcoin #573では、新しいメソッドSigHashType::from_u32_standardを追加し、 提供されたsighashバイトがBitcoin Coreがデフォルトで中継、マイニングする標準の値の１つであることを保証します。 各署名のsighashバイトは、トランザクションのどの部分に署名する必要があるかを示します。 Bitcoinのコンセンサスルールでは、非標準のsighash値はSIGHASH_ALLと同等の値として扱われると規定されていますが、 デフォルトでそれらは中継したりマイニングされないという事実は、理論的に、 オフチェーンのコミットメントを使用しているソフトウェアを騙し強制力のない支払いを受け入れさせるのに使用することができます。 Rust Bitcoinを使用しているそのようなソフトウェアの開発者は、 コンセンサスで有効な任意のsighashバイトを受け入れるSigHashType::from_u32メソッドから、 この新しいメソッドに切り替えることができます。

• ● BIPs #1069は、BIP8を更新し、アクティベーションの閾値を設定可能にし、 最近のTaprootのアクティベーションの議論に基づいて、 以前の95%から減少して90%を推奨値として含めるようにしました。