このOptechニュースレターの特別版では、2021年のBitcoinの注目すべき動向についてまとめています。 2018年、2019年、2020年のまとめの続編になります。

内容

1月

数年にわたる議論の末、先行するC-LightningによるサポートやLNDでのサポートに続いて、 1月にはsignetをサポートする最初のBitcoin Coreのバージョンがリリースされました。 signetは、誰もがBitcoinのメインネットワーク（mainnet）をシミュレートするために使用できるテストネットワークで、 現在存在するものと、特定の変更（ソフトフォークによりコンセンサスの変更を有効化したものなど）を含むものが存在します。 signetを実装するほとんどのソフトウェアは、デフォルトsignetもサポートしています。 デフォルトsignetは、さまざまなチームによって開発されたソフトウェアを、 実際のお金がかかっている時の環境に可能な限り近い安全な環境でテストするための便利な手段を提供しています。 また今年は、Bitcoin Coreのデフォルトsignetに意図的なブロックチェーンの再編成を追加し、 開発者がその種の問題に対してソフトウェアをテストできるようにすることについても議論されました。

bech32mのドラフトBIPも1月に発表されました。 Bech32mアドレスは、bech32を少し修正したもので、Taprootや 将来のプロトコルの拡張で安全に使用できるようにしたものです。 その後、Bitcoin Wikiページが更新され、 ウォレットやサービスのbech32mアドレスの採用状況が追跡できるようになりました。

新しいプロトコルのもう１つの最初のリリースは、 OnionメッセージとOfferプロトコルでした。 Onionメッセージは、LNノードが、HTLCベースのメッセージ送信と比べて、 オーバーヘッドを最小限にする方法で他のノードにメッセージを送信することを可能にします。 Offerは、Onionメッセージを使ってあるノードが他のノードに支払いをオファーできるようにし、 受信ノードが詳細なインボイスや他の必要な情報を返すことができるようにします。 OnionメッセージとOfferは、今年いっぱいはドラフト仕様のままですが、 これらを支払いのスタックによる影響を軽減するために使用する提案を含め、 さらなる開発が行われる予定です。

2月

Bitcoinのコントリビューターは、改良された署名の作成と検証アルゴリズムの研究を進め、 その研究を利用して、さらに改良を加えたバリエーションを作成しました。 libsecp256k1に実装され（1、2）、その後Bitcoin Coreに実装されると、 署名検証にかかる時間が約10%短縮されました。これはBitcoinのブロックチェーンで 約10億の署名を検証する際の大きな改善となります。 この変更が数学的に正しく、安全に使用できることを確認するために、複数の暗号学者が作業を行いました。 また、この変更により、低消費電力のハードウェア署名デバイスで安全に署名を作成する速度が大幅に向上します。

2015年以来、LNの既知の問題であるチャネルジャミング攻撃は、 年間の継続的な議論の中で、さまざまな可能な解決策が議論されました。 残念ながら広く受け入れられる解決策は見つからず、年末までこの問題は未解決のままです。

Illustration of jamming attacks

3月

3月の重要な議論は、Bitcoinに対する量子コンピュータによる攻撃のリスク、 特にTaprootが有効になり広く使用されるようになった場合のリスクの分析に向けられました。 Bitcoinの元々の機能の1つである公開鍵のハッシュは（Bitcoinアドレスを短くするために追加された可能が高い）、 量子コンピュータが突然大きく進歩した場合、限られたユーザーから資金を盗むのを困難にする可能性もあります。 Taprootはこの機能を提供しておらず、少なくとも1人の開発者は、 それによる不合理なリスクを懸念していました。 多数の反論が提示され、Taprootに対するコミュニティの支持は変わりませんでした。

2021年のまとめ
Taprootの有効化

2020年の年末に、Schnorr署名とTapscriptのサポートを含む Taprootのソフトフォークの実装がBitcoin Coreにマージされました。 これでプロトコル開発者の作業はほぼ完了し、あとはコミュニティが希望すればTaprootが有効になり、 ウォレット開発者がTaprootおよびbech32mアドレスなどの関連技術のサポートを追加し始めるだけになりました。

  • ● １月 は、Bitcoin Core 0.21.0のリリースから始まりました。 これはTaprootが有効になったデフォルトsignetを含むsignetをサポートした最初のリリースで、 ユーザーと開発者にテストを始めやすい環境を提供するものでした。

  • ● ２月 には、##taproot-activation IRCチャネルで予定された多くの会議の最初の会議が開かれました。 これは、Taprootを有効化する方法について、開発者、ユーザー、マイナーが話し合うための主要なハブになります。

  • ● ３月 は、多くの会議参加者がSpeedy Trialという特定の有効化方法を 試みることに暫定的に合意したところから始まりました。 Speedy Trialは、マイナーからの迅速なフィードバックを集めながら、 ユーザーがTaprootを適用するにあたりソフトウェアをアップグレードするための十分な時間を与えるよう設計されています。 Speedy Trialは、Taprootを有効化するために使用される実際のメカニズムになるでしょう。

    有効化の議論が続く中、その設計上の決定の1つである、公開鍵をそのまま使用することについて、最終的な議論がありました。 これはユーザーの資金が将来の量子コンピュータによって盗まれる危険性が高まるかもしれないという議論でした。 多くの開発者は、この懸念は杞憂に終わるか、少なくとも誇張されていると主張しました。

    また3月に、Bitcoin CoreがBIP350のサポートをマージし、bech32mアドレスへの支払いを可能にしました。 元々Segwitバージョンのアドレスの支払いに使用されているbech32アドレスへの僅かな変更により、 非常に稀なケースで、Taprootユーザーが資金を失う原因となる可能性のあったバグが修正されます。 （bech32アドレスから作られた元のSegwitアウトプットは安全で、バグの影響は受けません。）

  • ● ４月 は、プロトコル開発者と一部のユーザーが、 2つの微妙に異なるSpeedy Trialの有効化メカニズムのメリットについて議論したため、 有効化の進捗が脱線しました。しかし、2つの異なるバージョンの異なる実装の作者は、有効化メカニズムとパラメーターを持つ Bitcoin Coreのバージョンをリリースできるようにするという妥協案に合意しました。

  • ● ５月 になると、 マイナーはTaprootを適用する準備ができたことを通知することができるようになり、 通知の進捗を追跡するウェブサイトが人気になります。

  • ● ６月 、マイナーはTaprootをロックインし、 推定6ヶ月後のブロック709,632で有効化することをコミットしました。 これはウォレット開発者や他のインフラストラクチャ開発者が、 彼らのソフトウェアをTaprootに対応させることに注意を払うべき時が来たことを意味し、 多くの開発者が対応を行いました。 さらに、オンチェーンのTaprootウォレットが、 LNやCoinswapsなどのさまざまなコントラクトプロトコルを使用して、 ウォレットのプライバシーに貢献できるようにするための提案もされました。 Optechも、Taprootの準備シリーズを始めました。

  • ● ７月 には、Taproot有効化後に、 ウォレットでTaprootを使用できるようにするために必要なbech32mアドレスフォーマットのサポートを追跡する Bitcoin Wikiページが開設されました。 多くのウォレットやサービスの開発者が、この機会に立ち上がり、 有効化されたら誰もがTaprootを使用できるようにするために準備することになりました。 他のソフトフォークの提案も、Taprootを使用するように更新されたり、 その有効化から学んだ知見を反映しました。

  • ● ８月 は、Taprootに関連するいくつかのドキュメントが作成されましたが、 Taprootの開発については静かな時期でした。

  • ● ９月 には、Bitcoinで最も人気のあるオープンソースのマーチャントソフトウェアが、 予定された有効化に先立ちTaprootのサポートを追加しました。 また、Taprootの機能を利用しScriptベースのCovenantsを可能にする新しいopcodeも提案されました。

  • ● １０月 に入り、Taprootの有効化が近づくにつれ、 新たな開発活動が始まりました。 TaprootのBIPは、ウォレットやインフラストラクチャの開発者がその実装を検証できるよう、 Test Vectorを拡張して更新されました。

  • ● １１月 はTaprootが有効化されました。 ブロック709,632とそれに続くいくつかのブロックのマイナーが、 Taproot支払いのトランザクションをブロックに含めなかったため、当初は混乱がありました。 しかし、複数の開発者とマイニングプールの管理者の作業のおかげで、 その後マイニングされたほとんどのブロックで、Taproot支払いのトランザクションを含める準備ができました。 Taproot対応ソフトウェアの開発とテストが続けられました。

  • ● １２月 、descriptor walletでTaproot支払いを受け取るための bech32mアドレスを作成できるようにするPRがBitcoin Coreにマージされました。 また、LN開発者はTaprootの機能の活用についてさらに議論しました。

Taprootの有効化メカニズムを選択する際の複雑さと、有効化直後の若干の混乱はありましたが、 BitcoinにTaprootソフトフォークのサポートを追加する最終ステップは全体的にうまくいったようです。 Taprootはこれで終わりという訳ではありません。Optechは、 ウォレットやインフラストラクチャの開発者がその多くの機能を利用し始める今後数年間、 かなりの時間を使ってこのことについて書き続けていくでしょう。

4月

LNDは4月にアトミック・マルチパス・ペイメント (AMP)をサポートしました。 これは、すべての主要なLN実装が現在サポートしている簡略化されたマルチパス・ペイメント（SMP）よりも前に 紹介されているためオリジナルAMPとも呼ばれています。 AMPはSMPよりもプライバシー面で有利であり、受信者が支払いを請求する前にすべてのパーツを受け取っていることを保証します。 AMPの欠点は、暗号学的な支払いの証明を生成しないことです。 LNDは、基本的に支払いの証明を提供できない自発的な支払いで使用するためにAMPを実装し、 AMPの1つの重大な欠点を考慮から排除しています。

5月

BIP125のトランザクションの置換の仕様とBitcoin Coreの実装との間の不一致が5月に開示されました。 私たちが知る限り、これによってビットコインが危険にさらされることはありませんでしたが、 予期しないトランザクションのリレー動作による（LNなどの）コントラクトプロトコルのユーザーのリスクについて、 いくつかの議論が生まれました。

5月はまた、C-Lightningプロジェクトが、 チャネルの両参加者がある程度の初期資金を提供できるデュアル・ファンディングチャネルを管理するプラグインを マージしました。今年マージされたデュアル・ファンディングの作業に加えて、 これにより、チャネルを開設した側が、チャネルの初期状態において、 チャネルを通じて資金を支払うだけでなく受け取ることができるようになります。 このように初期状態で資金を受け取ることができるため、LNの主な用途が送金ではなく支払いの受け取りであるマーチャントにとって、 デュアル・ファンディングは特に有用です。

2021年のまとめ
人気のあるインフラストラクチャプロジェクトのメジャーリリース

6月

6月に議論された新しい分析では、マイナーが作成するブロックにどのトランザクションを含めるか選択するための 代替方法について説明されています。この新しい方法は、短期的にマイナーの収益をわずかに増加させると予測されます。 長期的には、この手法がマイナーに採用されると、 それを知っているウォレットはCPFPによる手数料の引き上げのトランザクションで協力することができ、 その手法の有効性が高まります。

手数料の引き上げをより効果的にするもう1つの試みは、 Bitcoin CoreにおけるBIP125を使用した置換を許可するオプトインの手法だけでなく、 あらゆる未承認トランザクションをreplaced by fee (RBF)で置き換えることを許可する提案です。 これは、マルチパーティプロトコルの手数料引き上げに関するいくつかの問題の解決に役立ち、 またより多くのトランザクションが同じ設定を使用できるようにすることでプライバシーの向上になります。 プライバシーに関連して、別の提案では、Taproot支払いを作成するウォレットは、 BIP68のコンセンサスが適用されるシーケンス値によって提供される機能を必要としない場合でも、 デフォルトのnSequence値をセットすることが提案されました。 どちら提案でも、大きな反対はほとんどありませんでしたが、あまり進展はなかったようです。

6月には、Bitcoin Coreでmempoolのパッケージ受け入れを実装するシリーズの最初のPRがマージされ、 パッケージリレーへの最初の一歩が踏み出されました。パッケージリレーは、 リレーノードとマイナーに、関連するトランザクションパッケージを手数料率の目的で単一のトランザクションであるかのように扱わせるものです。 パッケージには手数料率の低い親トランザクションと手数料率の高い子トランザクションが含まれている場合、 子トランザクションの収益性は、マイナーが親トランザクションをマイニングする動機になります。 パッケージマイニングは2016年からBitcoin Coreに実装されていますが、 これまでのところノードがトランザクションをパッケージとしてリレーする方法はありません。 つまり、高手数料率の子を持っていたとしても低手数料率の親トランザクションは、 高手数料の期間中には、マイナーに届かない可能性があります。 このため、LNのような事前署名トランザクションを使用するコントラクトプロトコルでは、 CPFPによる手数料の引き上げの信頼性が低くなっています。パッケージリレーは、 この重要な安全性の問題を解決することを望むものです。

もともと2019年にLNのために提案されたアイディアが、6月に新たな命を吹き込まれました。 オジリナルのFast Forwardのアイディアは、LNウォレットがより少ないネットワークの往復で支払いを受信または中継し、 ネットワーク帯域幅と支払いのレイテンシーを削減する方法を説明したものです。 このアイディアは今年拡張され、LNウォレットが支払いのたびに署名鍵をオンラインにすることなく 複数の支払いを受け取り、署名鍵を簡単に保護できるようにする方法を紹介しました。

7月

数年にわたる議論と開発の末、分散型の流動性広告システムの最初の実装がLNの実装にマージされました。 まだドラフトであるliquidity adsの提案では、 ノードが、LNのゴシッププロトコルを使用して、一定期間資金をリースする意思を広告し、 他のノードは即時に支払いを受け取ることが可能なインバウンドキャパシティを購入できるようになります。 広告を見たノードは、デュアル・ファンディングチャネルを開いて、 支払いとインバウンドキャパシティの受け取りを同時に行うことができます。 広告ノードが実際に支払いをルーティングすることを強制する方法はありませんが、 この提案には、合意したリース期間が終了するまで広告主が他の目的に資金を使用することを防ぐ、 以前の提案（その後Lightning Poolでも使用）が取り入れられています。 つまり、支払いのルーティングを拒否しても何のメリットもなく、 広告ノードがルーティング手数料を得る機会が失われることになります。

Bitcoin Coreに最初に提案されてから3年、 Output Script DescriptorのドラフトBIPが作成されました。 Descriptorは、ウォレットまたは他のプログラムが、特定のScriptや関連するScriptのセット （例えば、HDウォレットのようなアドレスや関連アドレスのセット）に対する支払い、 もしくはそこからの支払いを追跡するために必要なすべての情報を含んでいる文字列です。 Descriptorは、Miniscriptと組み合わせて、 ウォレットがさまざまなScriptの追跡と署名を処理できるようにします。 また、PSBTと組み合わせると、ウォレットがマルチシグScriptで制御する鍵を決定することができます。 年末までに、Bitcoin CoreはDescriptorベースのウォレットを、新しく作成されるウォレットのデフォルト にしました。

7月には、これまでLNプロトコルの一部ではなかった、LNチャネルの一般的な開設方法が定義され始めました。 ターボチャネルとも呼ばれるゼロ承認チャネルは、資金提供者が初期資金の一部またはすべてを受信者に提供する 新しいシングル・ファンディングチャネルです。これらの資金は、 チャネル開設のトランザクションが十分な数の承認を得るまで安全ではないため、 受領者が標準的なLNプロトコルを使用して資金の一部を資金提供者に戻すことにリスクはありません。 例えば、アリスはボブのカストディアルな取引所の口座に数BTC持っています。 アリスはボブに、アリスに1.0 BTC支払う新しいチャネルを開くよう依頼します。 ボブは自分自身が開設したばかりのチャネルを二重使用しないと信じているので、 チャネル開設トランザクションが１つめの承認を受ける前であっても、 アリスがボブのノードを通じて0.1 BTCを第三者のキャロルに送信できるようにすることができます。 挙動を定義することは、LNノードとこのサービスを提供するマーチャントとの間の相互運用性の向上に役立つはずです。

Zero-conf channel illustration

新しい署名ハッシュ（sighash）タイプに関する2つの提案がBIP118に統合されました。 2017年に提案され、一部は10年前に遡る以前の提案に基づいていたSIGHASH_NOINPUTは、 2019年に最初に提案された SIGHASH_ANYPREVOUTとSIGHASH_ANYPREVOUTANYSCRIPTに 取って代わられました。新しいsighashタイプにより、LNやVaultなどのオフチェーンプロトコルは、 保持する必要のある中間状態の数を減らし、ストレージ要件と複雑さを大幅に軽減することができるようになります。 マルチパーティプロトコルでは、そもそも生成する必要のあるさまざまな状態の数をなくすことで、 メリットがさらに大きくなる可能性があります。

8月

Fidelity bondは、サードパーティのシステムでの不正行為の代償として、 ビットコインを一定期間ロックするために、少なくとも2010年には紹介されているアイディアです。 ビットコインはそのタイムロックが切れるまで再び使用することができないため、 ロック期間中に禁止されたり他のペナルティを受けた他のシステムのユーザーは、 同じビットコインを使って新しい仮想IDを作れなくなります。 8月、JoinMarketはFidelity bondを初めて大規模かつ分散的に利用するための本番運用を開始しました。 リリースから数日で、50 BTC以上がタイムロックされました（当時の価格で$200万USD以上）。

8月には、LNの新しい経路探索のバリエーションが議論されました。 この手法の支持者は、ルーティングノードが各支払いに最小の基本手数料（Base fee）を課さずに、 ルーティングされた金額の割合のみに手数料を課す場合に最も効果的であると考えました。 しかし、別の意見もありました。年末までに、この手法のバリエーションが C-Lightningに実装される予定です。

2021年のまとめ
Bitcoin Optech

Optechの4年めは、51の週刊ニュースレターを発行し、 トピックインデックスに30の新しいページをを追加し、 寄稿ブログ記事を公開し、 Taprootの準備に関する21部構成のシリーズを（2人のゲスト投稿者の助けを借りて） 書きました。合計すると、Optechは今年、Bitcoinソフトウェアの研究と開発について8万語以上を公開し、 これはおよそ250ページの本に匹敵します。

9月

Bitcoin開発者が長い間議論してきた機能の1つに、ビットコインをScriptに送ると、 そのビットコインを後で受け取る他のScriptを制限することができるCovenantsと呼ばれる仕組みがあります。 例えば、アリスがビットコインをScriptで受け取り、このScriptは彼女のホットウォレットで使用できますが、 2つめのScriptに送信することで、彼女のホットウォレットが使用するのを時間的に遅らせることができます。 この遅延時間の間、アリスのコールドウォレットは資金を使用できます。 そうせずに、遅延時間が過ぎると、アリスのホットウォレットは資金を自由に使えるようになります。 9月には、署名（keypath支払い）またはMASTのようなScriptツリー（scriptpath支払い）のいずれかを使用して 資金使用するTaprootの機能の活用する方法で、この種のCovenantsを作成する新しいOP_TAPLEAF_UPDATE_VERIFY opcodeが 提案されました。この新しいopcodeは、複数のユーザーがUTXOの所有権をトラストレスにシェアできるようにすることで、 プライバシーを大幅に向上できるJoinpoolの作成に特に有用です。

10月

10月、Bitcoinの開発者はトランザクションがどのビットコインのセットを使用したいかを 識別するための新しい方法について議論しました。 現在、ビットコインは、最後に使用されたトランザクション内の位置で識別されています。 例えば、「トランザクションfooの0番めのアウトプット」のように。 新しい提案では、ビットコインを使用した以前のトランザクションと、降順階層におけるその位置を使って ビットコインを識別できるようにします。 例えば、「トランザクションbarの2つめの子の0番めのアウトプット」のように。 これによりeltooや、Channel Factories、 Watchtowerなどの設計に利点がもたらされ、 これらすべてがLNなどのコントラクトプロトコルにメリットをもたらすことが示唆されました。

また10月には、LNを改善するための既存のアイディアの組み合わせが、 SIGHASH_ANYPREVOUTのソフトフォークやその他のコンセンサスの変更を必要とせずに、 eltooと同じ利点のいくつかをもたらす1つの提案にまとめられました。 この提案は、特定の経路上のすべてのルーティングノード間を一方向に移動できるのとほぼ同じ速さまで、 支払いの待ち時間を短縮するものです。 また、ノードがチャネルの作成時に必要なすべての情報をバックアップし、 ほどんどの場合にデータの復元中に他の情報を入手できるようにすることで耐障害性を高めることができます。 また、オフラインの鍵で支払いを受けることができるため、特にマーチャントのノードが オンラインのコンピュータで鍵を使用する時間を制限することが可能になります。

11月

LN開発者は2018年以来最初の一般的なLNサミットを開催し、 PTLCやマルチシグのためのMuSig2、 eltooなどLNでのTaprootの利用、 仕様の議論のIRCからビデオチャットへの移行、現在のBOLT仕様モデルへの変更、 Onionメッセージ、Offer、 Stuckless payments、チャネルジャミング攻撃とさまざまな緩和策、 トランポリンルーティングなどのトピックについて議論しました。

12月

単一署名のオンチェーントランザクションの場合、マイナーにより早く承認するよう促すために、 トランザクションの手数料率を引き上げるのは比較的簡単な操作です。 しかし、LNやVaultのようなコントラクトプロトコルの場合、 手数料の引き上げが必要な場合に、支払いを承認したすべての署名者が協力可能な状態にあるとは限りません。 さらに悪いことに、コントラクトプロトコルでは、特定のトランザクションが期日までに承認される必要がある場合が多く、 そうしないと正直なユーザーがお金を失う可能性があります。 12月には、コントラクトプロトコルにとって効果的な手数料の引き上げメカニズムの選択に関連する研究が発表され、 この重要な長期的な問題に対する解決策の議論に拍車がかかっています。

最後に

今年のまとめでは、2021年の注目すべき20の開発について、 貢献者の名前を一人も出さずに説明するという、新しい試みを行いました。 私たちはこれらすべての貢献者に感謝し、彼らの素晴らしい業績が認められることを強く望んでいますが、 普段言及されていないすべての貢献者にも感謝したいと思います。

コードレビューに時間を費やしている人、 予期せず変更されないことを保証するために確立された動作のテストを書いている人、 お金が危険にさらされる前に問題を修正するために原因不明の問題のデバッグに力を注いでいる人、 やらなかった場合にニュースになるような多くのタスクに取り組んでいる方々。

2021年のこの最後のニュースレターは彼らに捧げます。 私たちは、このような知られざる貢献者たちの名前を簡単にリストアップする方法を持ち合わせていません。 代わりに、このニュースレターからすべての名前を省略し、Bitcoinの開発はチームの努力であり、 最も重要な仕事のいくつかは、 このニュースレターのどの号にも名前が載ったことのない人々によって行われていることを強調しています。

彼ら、そして2021年にBitcoinに貢献したすべての人々に感謝します。 2022年に彼らがどんなエキサイティングな新展開を見せてくれるのか、待ち遠しい限りです。

Optechのニュースレターは、1月5日から通常の水曜日の発行に戻ります。