半減期の1週間前、ビットコイン開発者は何に忙しいのでしょうか?ちょっと見てみましょう！

前面に書かれている内容:

ビットコイン史上3度目の半減期まで残り5日を切りました。では、この期間中、ビットコイン開発者は何に忙しいのでしょうか?

今週の Bitcoin Technical Weekly では、開発者が拡張 QR コードを使用して大規模な Bitcoin トランザクションを完了する方法を検討し、続いて高可用性 Lightning Network (LN) ノードの構築に関するレポート、Simplicity プログラミング言語などの技術的なトピック、最後に C-Lightning、LND、Bitcoin Core、BIP などの一般的な Bitcoin インフラストラクチャの主要な更新を含む通常のセクションを紹介します。

今週の公式コンテンツに入る前に、少しお祝いしましょう!

大規模なビットコイン取引のためのQRコード

QR コードには実際に約 3 キロバイトのデータを含めることができ、これは平均的なユーザーの取引には十分ですが、大規模な取引には不十分です。

これに対して、Riccardo Casatta 氏と Christopher Allen 氏はそれぞれ、部分的に署名された Bitcoin トランザクション (PSBT) や Bitcoin ウォレットとのやり取りに関連するその他の潜在的に大きなデータ ブロックを視覚的に通信する方法を標準化することを目指して、Bitcoin 開発者メーリング リスト (1、2) にディスカッション スレッドを投稿しました。 Spectre DIY リポジトリでの以前の議論と、Airgapped Signing リポジトリでの継続的な議論を参照してください。

エンタープライズ環境での Lightning ネットワーク ノードの実行

著者: Roman Taranchenko (Suredbits エンジニア)

初めて Lightning 支払いを送信したときに感じる興奮から、Lightning ネットワーク経由で支払いを受け取った後の興奮が薄れていくまで、ノードを安全かつ確実に運用する方法を常に考えることが重要です。しかし、失敗はほとんどの場合、予期せず起こります。障害が発生した場合、どのように回復しますか?確実にバックアップするにはどうすればいいですか?種を安全な場所に保管するにはどうすればいいですか?私たちが取り組みたいのは、このような種類の質問です。

Suredbits では、Eclair クライアントを使用して LN ノードを実行します。 Eclair 自体は非常に堅牢ですが、データベースバックエンドとして PostgreSQL を使用し、秘密鍵の保存に AWS Secrets Manager を使用するなど、信頼性を高めるためのいくつかの対策を講じました。

Eclair にはオンライン バックアップ機能が組み込まれていますが、自動化するには手動セットアップとスクリプトが必要であり、スケーラビリティが低く、エラーが発生しやすくなります。 AWS RDS 上で PostgreSQL を実行すると、多くの DevOps エンジニアに馴染みのある方法でバックアップとレプリケーションを自動化できるため、データベースの状態の回復が容易になります。

PostgreSQL をリモート データベース バックエンドとして使用すると、ノードのフェイルオーバーの実装が容易になります。何らかの理由でノードがクラッシュした場合に、バックアップからデータベースを復元する必要がなく、新しい Eclair クライアントを正しいデータベース サーバーにポイントするだけで済むためです。以下は、2 つの Eclair インスタンスと AWS の RDS、ELB、NAT ゲートウェイを使用した自動フェイルオーバーの簡単なデモです。

デモで説明したフェイルオーバー シナリオでは、ノードの秘密キー シードを Eclair インスタンス間で共有できるようにする安全な方法が必要です。 Eclair は、トレントをローカル ファイル システム上のファイルに保存します。このファイルはどこかにバックアップしておき、必要に応じて復元する必要があります。現在の Eclair 実装では、追加の手順を自動化する必要があります。代わりに、あらゆる種類の秘密 (データベースのパスワードや暗号化キーを含む) を安全に保存するように設計された AWS Secrets Manager ストレージツールを使用します。ここで、インスタンス間でシードを共有するには、構成ファイルで正しい秘密の場所を指定するだけです。一度設定すると、インスタンスは AMI イメージとして保存され、手動で設定することなく、必要な回数だけ再イメージ化できます。

上記の対策は、エンタープライズ レベルのライトニング ネットワーク ノードを構築するための最初のステップにすぎません。対処すべき問題はまだまだあります。たとえば、Lightning Network ノードに使用できるハードウェア セキュリティ モジュール (HSM) や、マルチインスタンス設定で Bitcoin Core ノードをフェイルオーバーする方法などです。しかし、私たちの取り組みは、Eclair を拡張し、より耐障害性を高めるための強固な基盤になると信じています。

このトピックの詳細については、プレゼンテーションをご覧ください。

免責事項: 秘密鍵が関係するため、徹底したリスク評価を行わずにサードパーティのクラウド サービスを使用しないでください。

ビットコイン開発者の焦点

Bitcoin Transcripts は、Bitcoin に関する技術的なプレゼンテーションとディスカッションの記録です。この週刊レポートでは、過去 1 か月間に開発者が注目した議論のいくつかを取り上げます。

1. シンプルさ: 次世代のビットコインスマートコントラクトプログラミング言語

Adam Back 氏は、Blockstream ウェビナーで、証明可能なセキュリティと表現力に重点を置いた Bitcoin Script スクリプト言語の次世代代替品である Simplicity を紹介しました。 Adam Back 氏は、Simplicity が Bitcoin に実装されると仮定すると、開発者はソフトフォークを必要とせずに SIGHASH_NOINPUT などの新しい機能を実装できる方法について説明します。彼はまた、今日 Simplicity で何ができるかのデモも披露しました。 （テキスト、ビデオ、スライド）

2. ビットコインコアへの攻撃

Amiti Uttarwar 氏は LA BitDevs で Evolution を発表し、Bitcoin の P2P レイヤーへの変更が信頼性、適時性、アクセシビリティ、プライバシー、アップグレード可能性という 5 つの目標に対してどのように評価されるかについて説明しました。彼女は、ネットワークパーティションとエクリプス攻撃の危険性について説明し、ブロックリレーのみの接続とアンカーノードが効果的な緩和策である理由を説明しました。 （テキスト、ビデオ）

3. LND v0.10

Laolu Osuntokun、Joost Jager、Oliver Gugger が Reckless VR イベントで LND v0.10 について議論しました。 Osuntokun 氏は、LND クライアントの最新リリースにおける Tor および RPC の機能強化と、数か月前にオンチェーン料金を見積もるという課題を解決するアンカー出力と呼ばれる新しいチャネル機能を紹介しました。 Jager 氏は、分割アルゴリズム、支払いの断片が異なる時間に到着した場合に何が起こるか、および複数部分の支払いの失敗を処理するための戦略など、複数部分の支払いの課題について説明しました。最後に、Gugger 氏は、部分的に署名された Bitcoin トランザクション (PSBT) チャネルと、それを可能にするチャネル抽象化の作業について説明しました。 （テキスト、ビデオ）

4. ビットコインを理解する

Kalle Rosenbaum 氏はビットコイン開発者のミートアップに出席し、ロンドン ビットコイン開発者会議で講演しました。ミートアップの議論は、ビットコインの技術教育、BIP32 HD ウォレット、ソフトフォークアップグレードの役割に焦点が当てられました。講演の中で、ローゼンバウム氏は、2017 年の Segregated Witness (segwit) アップグレードによってトランザクションの展性および二次ハッシュの問題がどのように解決されたかについて説明しました。

ビットコインの主要インフラアップデート

1. C-Lightning 0.8.2 が正式にリリースされました。このバージョンでは、任意のサイズのチャネルを開くためのサポート (--large チャネル構成パラメータを使用) が追加され、自発的な支払いを受け取るためのキー送信プラグインが提供され、その他の新機能とバグ修正が含まれています。クライアントの完全な更新内容については、ユーザーは新しい FAQ を読むことができます。

2. LND 0.10.0-beta では、マルチパス支払いの送信、PSBT 経由の外部ウォレットからの資金調達チャネルの使用、0.043 BTC を超える請求書の作成機能、その他の新機能とバグ修正のサポートが追加され、ユーザーは新しい運用セキュリティ ドキュメントを読むことができます。

3. Bitcoin Core 0.20.0rc1 は、Bitcoin Core の次期メジャー バージョンのリリース候補です。

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

注: 以下に記載されている Bitcoin Core コミットの変更は、メインの開発ブランチに適用されるため、これらの変更は、次の 0.20 リリースの約 6 か月後の 0.21 バージョンまで含まれない可能性があります。

1. Bitcoin Core #16528 により、createwallet RPC は、出力スクリプト記述子を使用してウォレットが支払いの受け取りに使用する特定の scriptPubKeys をエクスポートするウォレットを作成できるようになります。これは、ウォレット内の公開鍵ごとにウォレットが処理する支払いの種類ごとにスクリプトを派生させることにより、旧式のウォレットスキャン支払い方法を大幅に改善したものです。記述子ウォレットは、（未使用のスクリプト タイプをスキャンする必要がないため）より効率的で、新しいスクリプト タイプ（例: taproot）へのアップグレードが容易になり、外部ツール（例: マルチシグ ウォレット、または PSBT 経由の HWI 互換ハードウェア ウォレット）での使用が容易になります。

デフォルトでは、記述子ウォレットは、従来の Bitcoin Core HD ウォレットで使用される非標準化パスではなく、BIP 44、BIP 49、および BIP 84 で指定された一般的な BIP32 HD ウォレット パスを使用します。多くのウォレット RPC は、記述子に準拠していないか、開発者が新しいエッジケースで動作するように調整しているため、記述子ウォレットでは動作しません。この PR を 0.21 クライアントにマージする開発プロセスはまだ初期段階であり、開発者は記述子ウォレットをデフォルト以外のオプションにすることも決定しました。

2. Bitcoin Core #18038 は、ウォレットが再送信を試みる頻度を約 30 分から 1 日 1 回程度に減らすことで、トランザクションを最初にブロードキャストする際のプライバシーを向上させます。以前は、ネットワークを監視するエンティティは、これらの再送信中に同じノードからの同じトランザクションの複数のブロードキャストを確認し、イニシエーターがどのウォレットを使用したかについて結論を導き出すことができました。再送信の試行頻度を減らすことで、トランザクションの開始者を識別できる可能性が低くなります。

ウォレットによる頻繁な再ブロードキャストがなくても新しいトランザクションがネットワークに到達できるようにするために、この PR では、ストレージ プール mempool に非ブロードキャスト トランザクションも追加します。非ブロードキャスト トランザクションとは、ウォレットまたは RPC を介してローカルに送信されたが、ネットワーク上のピア ノードにまだ正常に中継されていないトランザクションです。このようなブロードキャストされていないトランザクションはストレージ プールに残り、ピアがノードにそのトランザクションの getdata P2P メッセージを送信してトランザクションを取得するまで、10 ～ 15 分ごとに再ブロードキャストされます。

3. BIP#893 は、schnorr 公開鍵と署名の BIP340 仕様にいくつかの変更を加え、taproot の BIP341 仕様にも関連する変更を加えます。

4. BIP#903は、以前に提案された一般的な署名メッセージ用のBIP322仕様を簡素化します（Weekly Report No. 91を参照）。この変更により、主に、複数のスクリプト (アドレス) が同じ証明で同じメッセージに署名できるようにする詳細が削除されます。

5. BIP#900 は、BIP325 のシグネット仕様を更新し、すべてのシグネットが同じハードコードされたジェネシス ブロック (ブロック 0) を使用するようにしますが、独立したシグネットはネットワーク マジック (メッセージ開始バイト) によって区別できます。