この特別編のOptech Newsletterでは、2019年におけるビットコインの重要な開発についてサマリーします。 これは2018 summaryの続編です。

本サマリーは、この1年の約9,000コミット(約2,000マージ)、1,500を超えるメーリングリストへの投稿、数千件のIRCログ、その他のパブリックな情報などをレビューしたweekly newsletters を元に作成しております。すべての素晴らしい仕事をサマライズするために50のニュースレターの発行、200ページ相当のコンテンツの作成を行いました。それでも、多くの重要なコントリビューションを掲載できませんでした。特に、バグ・フィックス、テスト、レビュー、サポートなど非常に重要だけれどもニュースにならないものです。当サマリーでは、更に1年間を数ページにまとめるために、他の素晴らしい数多くのコントリビューションを省略しました。

それゆえに、本ニュースを続ける前に、2019年にビットコインに貢献したすべての人に心から感謝します。後続のサマリーで、たとえ、貴方やプロジェクトに言及することがなくとも、Optechそしてすべてのビットコイン・ユーザは、ビットコインに貢献した貴方に言葉にならないほど感謝しています。

Contents

January

1月に、Steven Rooseは、ビットコイン・カストディ業者が特定の量のビットコインを管理していることのエビデンスの作成に利用できる proof of reserves 疑似トランザクションの標準フォーマットを提案しました。この種のツールは、預金者がカストディアン業者からコインを引き出すことを保証するものではありませんが、カストディアン業者はコインの損失や盗難を隠すことが困難となります。Rooseはreserve proofsの作成に部分的署名ビットコイントランザクション(PSBTs)を元にした ツールの作成を進めており、BIP127として仕様を公開しています。

February

2月には、ビットコイン・コアのマスター開発ブランチに、 Hardware Wallet Interface (HWI) Python ライブラリとコマンドラインツールを利用するために必要となる最後のPR群がマージされました。HWIは3月に初期の安定リリースが発表され、4月にWasabi Walletがサポート追加、11月にBTCPayが side packageを通じてサポートを追加しました。. HWIはハードウェア・ウォレットとソフトウェア・ウォレットが output script descriptors と 部分的署名ビットコイン・トランザクション (PSBTs)の組み合わせでやり取りすることを容易にします。2019年は標準化されたフォーマットやAPIのサポートが進んだことにより、ユーザが特定のソリューションのみを選択するのではなく、ニーズに応じてハードウェアとソフトウェア・ソリューションの適切な組み合わせを選択することが容易にできるようになりました。

さらに2月には、Pieter WuilleがStanford Blockchain Conference にて彼が取り組んでいたoutput script descriptorsのスピンアウトであるminiscriptに関する プレゼンテーションを実施しました。Miniscriptはビットコイン・スクリプトの階層化表現であり、ソフトウェアによる自動分析を簡素化します。これにより、スクリプトを満たすためにウォレットが提供する必要があるデータ(例えば、署名、ハッシュプリイメージ)、スクリプトにより利用されるトランザクションデータ量とそれを満たすデータ、ならびに、スクリプトがコンセンサス・ルールと一般的なトランザクション・リレー・ポリシーをパスするかどうかが分析可能となります。

Miniscriptに加えて、WuilleとAndrew PoelstraとSanket Kanjalkarは、miniscriptへコンパイルされるコンポーザブルなポリシー言語を提供しました(miniscript自体はBitcoin Scriptへ変換されます)。ポリシー言語により、コインを利用するために満たすべき条件を容易に記述することができます。複数のユーザでコインを共有してコントロールしたい場合、ポリシー言語のコンポーザビリティによりそれぞれのユーザーのサイン・ポリシーを一つのスクリプトで組み合わせることが容易になりました。

これが広範囲に普及した場合、異なるビットコインを扱うシステムが共に1つのトランザクションに署名することが容易になり、ウォレットのフロントエンド、LNノード、コインジョイン・システム、マルチシグ・ウォレット、コンシューマ・ハードウェア・ウォレット、ハードウェア・署名・モジュール(HSM)やその他のハードウェア、ソフトウェアを統合するために必要なカスタムコードの量が、大幅に削減されます。

Wuilleと彼の協力者らは、1年を通じてminiscriptに取り組み続け、続いてコミュニティ・フィードバックを求め、ビットコイン・コアにサポートを追加するPRを開きました。Miniscriptは12月にLNディベロッパーにより、アップグレードされたバージョンによるオンチェーン・トランザクションの複数の新しいスクリプトを分析し最適化するために利用されました。

March

3月には、Matt Corallo がビットコインのコンセンサス・コードの潜在的な問題を取り除くconsensus cleanup soft forkを提案しました。これらが適用されることにより、time warp attackの解消、レガシー・スクリプトのワーストケースのCPU使用量の低減、キャッシュしているトランザクション検証結果の信頼性向上、既知の(コストはかかる)軽量クライアントへの攻撃の解消が見込まれます。

Time-warp のフィックスなど一部の提案は多くの人々の関心を引きつけましたが、ワーストケースのCPU使用量、検証結果のキャッシュのフィックスに関しての提案は、批判も受けました。おそらく、それ故にこの年の後半にかけて実装に向けて当提案が進捗することはありませんでした。

また3月には、Kalle Almが、signetに関するイニシャル・フィードバックをリクエスト、後にBIP325となりました。Singet プロトコルは、全ての有効なブロックが中央集権型パーティによって署名される必要があるテストネットを作ることが可能です。この中央集権化はビットコインとは正反対のものですが、テスターが破壊的なシナリオ(chain reorganizationなど)を作成したり、単にソフトウェア相互運用性テストを実施したい場合などに、テストネットとして理想的なものとなります。既存のビットコインのテストネットでは、reorgやその他のディスラプションが頻繁に発生、またそれが長期間にわたることもあり、テスト実施を非現実的なものとしています。

Signetは一年を通じて成熟していき、ゆくゆくはC-Lightningといったソフトウェアに統合eltooのデモなどに利用されていくでしょう。ビットコイン・コアにサポートを追加するプルリクエストはオープンになっています。

さらに、3月にはLightning LabsがLightning Loopを発表し、チャネルをクローズすることなく、オンチェーンのUTXOにLNチャネルからファンドの一部を引き出すノン・カストディアル・ソリューションを提供しました。6月には、既存のチャネルにUTXOを送信(追加)できるようLoopをアップグレードしました。Loopは通常のオフチェーン・LN・トランザクションで使用されているHash Time Locked Contracts (HTLCs)を使用し、想定通りユーザのファンドがLNチャネルに転送されているか、もしくは、オンチェーントランザクションフィー以外の全てのコストのリファンドをユーザが受け取ることを保証します。これによりLoopはほぼ完全にトラストレスになります。

  • C-Lightning 0.7 は、3月にリリースされ、年末までにかなり利用されるプラグイン・システムを追加しました。また、監査性を強化した安全性の高い再現可能なビルドをサポートする最初のC-Lightningリリースとなりました。

  • LND 0.6-beta は、4月にリリースされStatic Channel Backups (SCBs) のサポートを追加しました。これにより、最新のチャネル・ステートを失ったとしても、LNチャネルでセトルしたファンドをリカバリーすることができます。このリリースには、新しいチャネルを開くのを支援する改善されたautopilotの機能や、チャネルを閉じる、またはカストディアンを利用することなくオンチェーンでファンドを動かすための Lightning LoopとのBuit-in 互換性が含まれます。

  • Bitcoin Core 0.18は5月にリリースされ、部分的署名ビットコイン・トランザクション(PSBT)のサポートの改善、output script descriptorsのサポートが追加されました。これら2つの機能の追加により、Hardware Wallet Interface (HWI)の初期リリース・バージョンを利用することができます。

  • Eclair 0.3は5月にリリースされ、バックアップ・安全性の改善、プラグインのサポートの追加、Tor hidden serviceとしての稼働を可能にしました。

  • LND 0.7-betaは7月にリリースされ、オフライン時にチャネルを保護する watchtowerを利用するサポートを追加しました。

  • LND 0.8-betaは10月にリリースされ、より拡張可能なオニオン・フォーマットのサポートを追加し、バックアップ・安全性を改善、watchtowerサポートを改善しました。

  • Bitcoin Core 0.19は11月にリリースされ、CPFP carve-out mempool policyを実装し、 BIP158スタイルのコンパクト・ブロック・フィルター (現時点ではRPCのみ)の初期サポートを追加し、BIP37 ブルーム・フィルターならびにBIP70 payment requestsをデフォルトにするプロトコルを無効化することでセキュリティを改善しました。また、GUIユーザーをbech32アドレスをデフォルトにしました。

  • C-Lightning 0.8は12月にリリースされ、multipath payments のサポートを追加、デフォルトネットワークをテストネットからメインネットに変更しました。また、デフォルトでsqliteサポートに加えてpostgresqlサポートを提供するなど代替データベースをサポートする最初のメジャーリリースとなりました。

April

4月には、James O’BeirneがAssumeUTXOを提案しました。これは、最近のUTXOセットの信頼するコピーをダウンロード、使用することでフルノードで古いブロックチェーンのヒストリーの検証を先送りすることができる手法です。新しく立ち上げたノードでは数時間、数日と待つのではなく、フルノードを使って、ウォレットやその他のソフトウェアがノードをスタートして数分でトランザクションの送受信を実施できます。

AssumeUTXOでは、ノードは最終的に初期のUTXOの状態を検証できるまで、バックグラウンドでブロックチェーンのヒストリーをダウンロード、検証することを提案しています。これにより、最終的にAssumeUTXOを利用しない通常のノードと同等のトラストレスなセキュリティを確保することができます。O’Beirneは年間を通じてプロジェクトに取り組み、 徐々に新しい機能を追加し、将来的にAssumeUTXOをビットコイン・コアに取り込むため既存コードのリファクタリングを実施しました。

また、4月には、Pierre-Marie Padiouがトランポリン・ペイメントのアイデアを提案しました。これは、軽量LNノードがパス・ファインディングを重量ルーチング・ノードにアウトソースします。モバイルアップなどの軽量ノードは、すべてのLNルーティング・グラフをトラックすることが出来ないかもしれないため、ルート探索が困難になります。Padiouの提案は、軽量ノードにペイメントを近接ノードへルートし、そのノードに残りのパスを計算させるものです。ペイメントはトランポリンノードを経由して(跳ねて)行き先までたどり着きます。 プライバシー向上のため、支払者は順番に複数のトランポリンノードからの支払いの跳ね返りを要求する場合があります。これにより支払いが最終的な受取人宛なのか、または別のトランポリンノードにルーティングしているかどうか各ノードは分からなくなります。

LN仕様にトランポリン・ペイメントの機能を追加するためのPR は現在オープンになっており、Eclairの実装はトランポリン・ペイメントをリレーする 実験的なサポート を追加しています。

May

5月にはPieter Wuilleは、bip-taprootbip-tapscriptからなるtaproot soft forkを提案しました。これらは共に昨年の bip-schnorr の提案の内容を継承しています。これらが実装されると、シングルシグ、マルチシグや多くのコントラクトにおいて同じスタイルのscriptPubKeysを使用することが可能になります。マルチシグや複雑なコントラクトの多くの支払いが、同様に見え、シングルシグの支払いにように見えます。これにより、大きくユーザ・プライバシーとコイン・ファンジビリティを改善すると同時に、マルチシグ、コントラクト・ユースケースにて消費されるブロックチェーンスペースの量を削減できます。

マルチシグとコントラクトの支払いがtaprootのプライバシーとスペース節約をフル活用出来ない場合でも、オンチェーンにコードのサブセットのみを入れれば良いだけかもしれません。それにより、現在よりもよいプライバシーとブロックチェーンスペース効率向上が見込まれます。Taprootに加えて、tapscriptによりビットコインのスクリプトの能力を改良します。主に、将来、新しいopcodeを追加することをより簡単にきれいにできるようにします。

この提案は残りの1年に渡り、多くの議論とレビューが実施されました。その中にはAnthony Townsによって開催されました、150人以上がレビューの手助けをするためにサインアップしたgroup review sessions などが含まれます。

Townsは5月にtapscriptと組み合わせて利用できる2つの新しい署名ハッシュである、SIGHASH_ANYPREVOUTSIGHASH_ANYPREVOUTANYSCRIPTを提案しました。

署名ハッシュ(sighash)は、署名がコミットするトランザクションのフィールドと関連するデータのハッシュです。ビットコインにおいて異なるsighashはトランザクションの異なる部分にコミットします。それにより、署名者にオプションとして、他のユーザがトランザクションに対して特定の修正を実施できるようにします。2つの新しく提案されたsighashは、UTXOBIP118SIGHASH_NOINPUTと同様に機能します。意図的に利用するUTXOを特定しないことにより、(例えば、同一のpubkeyを利用するなど)スクリプトが満たしさえすれば、署名によりいかなるUTXOでも送信することができます。

インプットがないスタイルのsighashの主要な提案された利用方法は、LN向けに以前提案されたeltoo update layerを可能にすることです。Eltooはチャネル構築と管理を複数の観点から簡素化します。特にオンチェーンのチャネルコストを大きく削減できるため2つ以上の参加者が含まれるチャネルを簡素化することが望ましいとされています。

当月に提案された3つ目のソフトフォークは、Jeremy Rubinからのもので、OP_CHECKTEMPLATEVERIFY(CTV)と呼ばれる新しいopcodeです。これにより、例えば、本スクリプトを使用したトランザクションの後続トランザクションのoutputには他の特定のoutputが含まれている必要があるなど、限られた形式の契約(covenants)が可能になります。

これの推奨される使用法は、後で数十、数百、または数千の異なる受信者に支払うトランザクション(またはトランザクションのツリー)を使用してのみ使用できる少量のoutputを将来支払うことにコミットすることです。

これにより、コインジョインスタイルのプライバシーを強化し、セキュリティ強化された保管庫をサポートし、取引手数料が急増した場合の支出コストを管理するための新しい手法が可能になります。

Rubinは、CTVの展開バージョンをより効果的に可能にするべくBitcoin Coreの一部の改善のためにPRを開くなど、CTVへの貢献を、本年の終わりまで実施しています。

2019 summary
Notable technical conferences and other events

June

Gleb Naumenko、Pieter Wuille、Gregory Maxwell、Sasha Fedorova、Ivan Beschastnikhはerlay論文を発表しました。アナウンスのバンドワイズを試算上84%削減する libminisketch-based set reconciliationを利用した、ノード間でコンファームしていないトランザクションアナウンスをリレーするプロトコルです。論文ではerlayによりノードがデフォルトで接続するアウトバウンド接続の数を大幅に増加することが実現可能になることも記載されています。これは、ほとんどのPoWのブロックチェーンにないブロックをエクセプトすることでノードを騙すエクリプス攻撃に対する各ノードの耐性を改善します。より多くのアウトバウンド接続が可能になることで、トラックしたり、ノードが起点とするペイメントを遅延させるなど他の攻撃に対するノードの耐性を改善します。Erlayに関するワークは、追加の研究やreconciliation protocolのBIP330 の提案など一年間に渡り続きました。

今年のP2Pリレーにおける他の改善は、ビットコイン・コアのトランザクション・リレーのプライバシー改善(Sergi Delgado-SeguraらによるTxProbe 論文に記載されている問題を取り除く)と エクリプス攻撃に対する抵抗を改善する、新しいブロックのリレーにのみ使われる 2つの追加アウトバウンド接続の追加です。

数多くの先行ワークを経て、6月にLNDにaltruist(利他的) LN watchtowersマージされました。Altruist watchtowersでは、クライアントのチャネルを保護することの対価として、プロトコル経由でいかなる報酬も受け取りません。それゆえ、ユーザは自分自身のwatchtowerを建てるか、watchtower operatorの慈善に依存しますが、他のユーザの代わりにペナルティ・トランザクションをwatchtowerが確実に送信することのデモとしては十分だと思われます。これにより長期間オフラインになるユーザーが資金を失わないことを確実にします。

Altruist watchtowersは、最終的には LND 0.7.0-beta でリリースされ、年内に追加の開発が実施されました。それらには、watchtowerの仕様提案eltooのような次世代のペイメント・チャネルとの組み合わせに関する議論が含まれます。

July

7月には、Carl DongのPRがビットコイン・コア・プロジェクトにマージ されました。これは、GNU Guix (”geeks”と発音する)を利用してビットコイン・コアのLinuxバイナリーのビルド再現性のサポートを追加するものです。ビットコイン・コアは、これまでGitian システムを使った再現性のあるビルドをサポートしてきましたが、セットアップが難しく、数百ものUbuntu パッケージのセキュリティに依存しています。比べて、Guixはインストール、実行が容易で、Guixを用いてビットコイン・コアをビルドした場合、パッケージの依存関係がより少なくなります。長期的には、Guixのコントリビューターは、bitcoindのようなバイナリーが単独で監査可能なソースコードから得られたことをユーザーが検証できるようにするためにtrusting trust問題を取り除けるように作業しています。

2020年にリリースされるビットコイン・コアの最初のメジャー・バージョンでGuixが使われることに期待を寄せており(おそらく古いGitianベースのメカニズムと並行して使用される)、1年を通じてGuixビルド・サポートの作業が続けられました。

また、C-LightningLNDのレポジトリーに信頼できるコンパイラーを使ってそれらのSWの再現性のあるビルドの作成方法に関するドキュメンテーションが追加されました。

August

8月には、Bryan Bishopがcovenantsを使わないビットコインにおけるVaultsの実装手法を提案しました。Vaultsは、仮に攻撃者がユーザの通常の秘密鍵を入手したとしても、攻撃者がファンドを盗む能力を制限するスクリプトを表すために使われる用語です。Covenantは他の特定のスクリプトに対してのみ送信できるスクリプトのことです。現在のビットコイン・スクリプト言語を利用してCovenantsを作成する既知の方法はありませんが、お金をvault contractにデポジットする際にユーザがいくつかのステップを実行するコードを走らすことができれば、Covenantsが必ずしも必要ではないことが分かりました。

特に、Bishopはvaultの弱点とその軽減方法についても記載しました。攻撃者によってvaultから盗むことの出来る最大資金を制限することができるというものです。実用的なvaultの開発は、個人のユーザ、取引所などの大規模なカストディアン事業者にとっても有用です。

2019 summary
Bitcoin Optech

2年目のOptechは、6社の新規メンバーのサインアップ、NYCブロックチェーン・ウィークにexecutive briefingの開催、 24週連続 のbech32送信のサポートのプロモーション、websiteにウォレット、サービスのcompatibility matrixの追加、51週分のnewslettersの発行、一部のニュースレター、ブログの日本語スペイン語などへの翻訳の開始、 topics indexの作成、Scalability Workbookへのチャプターの作成、パブリックにリリースされたjupyter notebooksを用いた2回の schnorr/taproot workshops の開催、BTSEBRDによるフィールドレポートの発行などを実施しました。

2020年も大きなプランがあり、皆様には継続してTwitterをフォロー、 weekly newsletterを購読し、または、RSS feedを追っていただけることを期待いたします。

September

Adam Gibsonは既存ビットコイン・システム向けの非対話型・コインジョイン提案しました。SNICKERと呼ばれるプロトコルは、ユーザが自身のUTXOの一つを選択し、グローバルなUTXOセットからランダムにUTXOを1つ選択し、同一のトランザクションで利用します。提案者がこのトランザクションの一部に署名し、パブリックサーバーに部分的署名ビットコイン・トランザクション(PSBT)のフォーマットでアップロードします。他のユーザーがサーバをチェックし、PSBTを確認したら、ダウンロードして署名し、ブロードキャストすることができます。これにより、両者が同時にオンラインである必要がなく、コインジョインを完成できます。提案者は、他のユーザがコインジョインをアクセプトするまで、同じUTXOを利用してPSBTsを作りたいだけ作成し、アップロードすることができます。

他のコインジョインのアプローチに対するSNICKERの主要な優位性は、両者が同時にオンラインである必要がないこと、ならびに、BIP174 PSBTサポート対応済みのウォレット(多くのウォレットが対応してきています)であれば簡単にサポート可能である点です。

9月にはまた、C-Lightning, Eclair, そして LNDのメンテナーは以前のバージョンのソフトウェアに影響を与える脆弱性を公開しました。チャネルオープンの際のトランザクションが正しいスクリプト、金額であるチェックが実装されていなかったことが問題のようです。 悪用された場合、オンチェーン上でチャネル・ペイメントをコンファームすることが不可能になり、invalid channelからvalid channelへペイメントをリレーすることにより、ノードがお金を失う可能性があります。Optechは、最初の脆弱性に関するパブリック・アナウンスメントの前に、お金を失ったというユーザーを認識しておりません。LNの仕様は、将来の実装者が同じ失敗に直面することを避けるためにアップデートされ、LN通信プロトコルに対する他の変更提案が、この種の他の失敗を避けることにつながることが期待されています。

October

LNディベロッパーにより、過度の遅延なくユーザがいつでもチャネルをクローズ可能にするという長年の課題への対応に関して、10月から11月に非常に重要な進捗がありました。 ユーザが複数のチャネルのうちの1つをクローズしたいが、リモート・ピアに連絡がつかない場合、ユーザはチャネルの最新のコミットメント・トランザクションをブロードキャストします。これは、オフチェーンのコントラクトの最新のバージョンでチャネルのファンドをそれぞれのオンチェーンで支払うpre-signed transactionです。この際にコミットメント・トランザクションが、数日から数週間前の安いトランザクション・フィーの頃に作成され、セキュリティー上重要なタイムロック期限の前までに取り込まれるのに十分な高いフィーが設定されていな可能性があります。

この問題の解決策としては、fee bump commitment trasctionを可能にすることが知られています。しかしながら、ビットコイン・コアのノードでは帯域やCPUを消費するDenial of Service (DoS) 攻撃を防ぐためにfee bumpingを制限しています。LNのようなトラストレスでマルチユーザーのプロトコルでは、カウンター・パーティが、あなたのLNコミットメント・トランザクションのコンファメーションを遅延させるために故意にアンチ・DoS・ポリシーを発動する攻撃者であるかもしれません(transaction pinningと呼ばれる攻撃です)。このトランザクションは、タイムロックが解除されるまでにコンファームされないかもしれないため、攻撃者はカウンターパーティからファンドを盗むことが可能になります。

昨年、Matt Coralloは、Child-Pays-For-Parent (CPFP) fee bumpingに関連するビットコイン・コアのトランザクション・リレー・ポリシーの一部から、特例を除くことを提案しました。この特例は、2者のコントラクト・プロトコル(例えば、現在のLN)が、それぞれのパーティーに、彼ら自身のfee bumpを作成することを保証することが可能です。Coralloのアイデアは、CPFP carve-out という名称でBitcoin Core 0.19の一部としてリリースされました。その前のリリースでも、その他のLNディベロッパーがこの変更を利用開始するために必要なLNスクリプトやプロトコル・メッセージの改定は実施されていました。当ニュースレター執筆段階では、これらの仕様変更はネットワークへのデプロイの前の最終実装・受け入れ待ちです。

2019 summary
新しいオープン・ソース・インフラストラクチャー・ソリューション

  • Proof of reserves tool は、2月にリリースされました。これにより取引所やその他のビットコイン・カストディアン業者が BIP127 reserve proofs を利用して特定のUTXOのセットに対してコントロールしていることを証明することができます。

  • Hardware Wallet Interface は、3月にリリースされ、PSBTsoutput script descriptorsに既に互換性のあるウォレットが、セキュア・キー・ストレージ及び署名にハードウェア・ウォレットの複数の異なるモデルを利用することを容易にします。

  • Lightning Loopは、3月にリリース(loop-inサポートは6月に追加)され、既存チャネルをクローズまたは、新しいチャネルをオープンすることなく、LNチャネルからファンドを追加・削除することを可能にします。

November

Taproot paymentsに bech32アドレスを利用するという11月の議論は、5月に発見されたbech32アドレスの問題 で注目を集めました。BIP173によると、ミス・コピーされたbech32 文字列が検出されない失敗率は最悪でも10億回に1回程度とされてきました。しかしながら、pで終わるbech32 文字列は、その前にqを削除、挿入しても有効な文字列となります。これは実用的には、segwit P2WPKH、P2WSH addressesに影響を与えません。一つのアドレスタイプを別のものに変えるには少なくとも19連続でqが追加される、または削除される必要がありますが、v0 segwit addressの文字列の長さは固定長であり、変更されると無効となるためです。

しかし、taprootで提案されているようなv1+ segwit addressでは可変長を前提としており、v0 segwit addressのように無効にはならず、脆弱性のあるアドレスへの一つの q の挿入、削除により、ファンドの損失につながります。BIP173の共著者であるPiter Wuilleは、追加の調査を実施し、この件のみがbech32の起こりうるエラー訂正機能からの逸脱であるとし、ビットコインにおいては20バイトまたは32バイトのウィットネス・プログラムでのみBIP173アドレスの利用ができるように制限することを提案しました。これによりv1、それ以降のsegwit addressのバージョンについてもv0 segwit addressと同等の信頼性のあるエラー訂正が提供可能です。また、次世代のビットコイン・アドレス・フォーマットにおいてもBCH誤り訂正の適用が可能になります。

また、11月にはビットコイン・コアはOpen SSLへの依存関係を削除しました。これは、初期の2009リリースであるビットコイン 0.1からコードベースに存在したものです。OpenSSLは、コンセンサスの脆弱性リモート・メモリー・リーク(潜在的な秘密鍵の漏洩)、その他のバグ、並びに低いパフォーマンスの原因となっていました。今回の削除により将来の脆弱性の頻度が低下することが期待されます。

OpenSSLの廃止の一部として、ビットコイン・コアのバージョン 0.18のBIP70 ペイメント・プロトコルのサポートは廃止予定となり、後のバージョン 0.19でデフォルトでサポートが無効となりました。この決定は、2019年にBIP70を継続利用していたいくつかの企業のCEOによって支持 されました。

December

12月にLN ディベロッパーは前年のプランニング・ミーティングに立てた主要な目標の一つである基本的な マルチパス・ペイメント実装を達成しました。ペイメントを複数パートに分割し、各パートが異なるチャネル経由で別々にルーティングします。これにより、一度に複数のチャネルを利用して資金の送受信が可能になり、ユーザのオフチェーンの残高合計分の送信や、フル・キャパシティー分の受信が一度のペイメントで(特定の安全上の制約の範囲内において)可能になります。 また、送信者が特定のチャネルの残高を気にする必要がなくなるため、LNがよりユーザーフレンドリーになることが期待されます。

Conclusion

上述のサマリーでは、革新的な提案や改善はなかったと言えるかもしれません。ビットコインやLNが既に稼働している裏側で、更に改善するため改修・構築がされていくという、多くの地道な、しかし重要な段階的改善の積み重ねでした。ディベロッパーの取り組みは、よりアクセスしやすいハードウェア・ウォレットの開発(HWI)、マルチシグやコントラクトのユースケース向けにウォレット間の通信の一般化(descriptors, PSBTs, miniscript)、コンセンサスのセキュリティの強化(cleanup soft fork)、テストの簡素化(signet)、不必要なカストディの排除(loop)、ノード立ち上げの簡易化(assumeutxo)、プライバシーの改善・ブロックスペースの削減(taproot)、LNのenforcement簡素化(anyprevout)、feerate高騰に対する運用改善(CTV)、バンドワイズ削減(erlay)、オフライン時におけるLNのユーザーの安全確保(watchtowers)、build時の信頼の必要性の削減(reproducible builds)、盗難防止(vaults)、プライバシーをよりアクセス可能にする技術(SNICKER)、LNユーザ向けのオンチェーンのフィー管理(anchor outputs)、LNペイメントがより自動でスムーズに働く技術(multipath payments)などで、これらは2019年のハイライトにすぎません。

ビットコイン・コントリビューターが2020年に成し遂げることは推測することしかできませんが、現状稼働しているものを壊すことなく、より良くしていく数多くの変更がされていくことでしょう。

*Optech Newsletterは1月8日より通常の水曜日配信版に戻ります。