/ home / newsletters /
Bitcoin Optech Newsletter #334: 2024年振り返り特別号
第7回のBitcoin Optech年間振り返り特別号では、2024年のBitcoinの注目すべき動向についてまとめています。 これは、2018年、2019年、2020年、 2021年、2022年、2023年のまとめの続編です。
内容
- 1月
- 2月
- 3月
- 4月
- 5月
- 6月
- 7月
- 8月
- 9月
- 10月
- 11月
- 12月
- 注目のまとめ
1月
- ● 手数料依存のタイムロック: John Lawが手数料依存のタイムロックを提案しました。 これは、ソフトフォークでブロックの手数料率の中央値がユーザーの指定したレベルを下回った場合にのみ タイムロックを失効させるというものです。 これにより、タイムロックの期限切れ間際に手数料が高騰することで、承認が妨げられるのを防ぐことができます。 その代わり、タイムロックは手数料が下がるまで延長され、大量のチャネル閉鎖が起きた際に、 強制的に期限切れになるという長年の懸念に対処しています。 この提案は、チャネルファクトリーや Joinpoolのようなマルチユーザー設定のセキュリティを向上させるとともに、 参加者に手数料の高騰を回避するインセンティブを与えます。議論には、 Taprootのannex内へのパラメーターの格納や、 軽量クライント向けの手数料率のコミットメント、プルーニングノードのサポート、 帯域外の手数料の影響などが含まれました。
- ● コントラクトプロトコルからの退出の最適化: Salvatore Ingalaが、Joinpoolやチャネルファクトリーのようなマルチパーティーコントラクトからの 退出を最適化する方法を提案しました。提案された方法では、 ユーザーが個別にトランザクションをブロードキャストするのではなく、 単一のトランザクションに調整できるようにします。これにより、 オンチェーンのサイズは少なくとも50%、理想的な状況では最大99%削減されます。 これは手数料が高い場合には特に重要です。そして保証金の仕組みにより正直な実行を保証します。 つまり、参加者の1人がトランザクションを構築しますが、不正が証明された場合は、保証金を失います。 Ingalaは、これをOP_CATとMATTのソフトフォークで実装することを提案しており、 OP_CSFSと64-bitの算術演算が使用できるとさらに効率化できます。
- ● LN-SymmetryのPoC実装: Gregory Sandersが、Core Lightningのフォークを使用したLN-Symmetryの PoC実装を共有しました。LN-Symmetryは、 ペナルティトランザクションを必要としない双方向のペイメントチャネルを可能にしますが、 子トランザクションが任意のバージョンの親トランザクションを使用できるようにするための SIGHASH_ANYPREVOUTのようなソフトフォークに依存しています。 Sandersは、LN-Penaltyと比較したそのシンプルさ、 (パッケージリレーとエフェメラルアンカーに関する 彼の研究をきっかけに)Pinningを回避することの難しさ、 およびOP_CTVのエミュレーションによる支払いの高速化の可能性を強調しました。 彼は、ペナルティが不要で、チャネルの実装を簡素化し、チャネルリザーブを回避できることを確認しました。 ただし、LN-Symmetryでは、誤用を防ぐためにCLTVの期限切れのdelta値を長くする必要があります。
2月
- ● Replace by feerate: Peter Toddが、標準のRBFポリシーが失敗した場合の トランザクションのPinningに対処するために、 Replace by Feerate(RBFr)を提案しました。 RBFrには2つのバリエーションがあり、純粋なRBFrでは、 はるかに高い手数料率(たとえば2倍)で無制限の置換が可能です。 ワンショットRBFrでは、置換トランザクションがmempoolの最上位に入った場合に、 適度に高い手数料(たとえば1.25倍)で1回の置換が可能です。Mark Erhardtが最初の問題点を特定し、 他の開発者は利用可能なツールでこのアイディアを完全に分析することの複雑さについて議論しました。 Toddは実験的な実装をリリースし、他の開発者はトランザクションPinningに対処するための代替ソリューションの開発を続けました。 これには、採用されるソリューションの信頼性を高めるために必要なツールの開発も含まれます。
- ● 人が読める支払い指示: Matt Coralloが、DNSベースの人が読めるBitcoinの支払い指示のためのBIPを提案しました。 これによりメールアドレスような文字列(例:example@example.com)で、 BIP21 URIを含むDNSSEC署名付きのTXTレコードを解決できます。 これは、オンチェーンアドレスやサイレントペイメント、 LNオファーをサポートし、他のペイメントプロトコルにも簡単に拡張できます。 この仕様は、BIP353として追加されました。 Coralloはまた、LNノード用にBOLTとBLIPを起草し、 ワイルドカードDNSレコードとオファーした安全な支払い先の解決を可能にしました。 実装は、11月にLDKにマージされました。 このプロトコルとサイレントペイメントの開発を受け、Josie Bakerが BIP21ペイメントURIの改訂に関する議論を始め、 議論は今年後半まで続きました。
- ● ASMap生成の改善: Fabian Jahrは、複数の開発者が独自に同等のASMapを作成できるソフトウェアを作成しました。 これにより、Bitcoin Coreはピアの接続を多様化し、エクリプス攻撃に抵抗できます。 Jahrのツールが広く受け入れられれば、Bitcoin CoreにデフォルトでASMapが組み込まれ、 複数のサブネットを制御する当事者からの攻撃に対する保護が強化される可能性があります。
- ● LNのデュアルファンディング: デュアルファンディングのサポートが インタラクティブなトランザクション構築プロトコルとともに、LN仕様に追加されました。 インタラクティブな構築により、2つのノードは、 ファンディングトランザクションを一緒に構築するために使用する設定とUTXOの詳細を交換できます。 デュアルファンディングは、トランザクションにどちらか一方または両者のインプットを含めることができます。 たとえば、アリスがボブとチャネルを開きたい場合に、この仕様の変更前は、 アリスはチャネル用の資金を全額提供しなければなりませんでした。 デュアルファンディングをサポートする実装を使用すると、アリスは、 初期のチャネル状態にボブが資金を全額を提供したり、それぞれが資金を提供することもできるチャネルを ボブと開くことができます。これは、まだ仕様に追加されていない Liquidity Adsプロトコルと組み合わせることができます。
- ● 将来の手数料率に対するトラストレスな賭け: ZmnSCPxjが、2人の参加者が将来のブロックの手数料率に賭けることができる トラストレスなスクリプトを提案しました。将来のブロックでトランザクションが承認されることを望むユーザーは、 このスクリプトを使用して、その時点で手数料率が異常に高くなるリスクを相殺することができます。 ユーザーがトランザクションの承認を必要とする頃にブロックをマイニングすることを期待するマイナーは、 このコントラクトを使用して、その時の手数料率が異常に低くなるリスクを相殺することができます。 マイナーの意思決定は、実際のマイニング状況のみに依存するため、集中型の市場で見られるような操作を防止する設計となっています。 このコントラクトはトラストレスで、協調的な支払いパスにより双方のコストが最小限に抑えられます。
2024年のまとめ: 脆弱性の開示
2024年、Optechは20件を超える脆弱性の開示をまとめました。その大半は、 今年初めて公開されたBitcoin Coreの古い脆弱性の開示でした。 脆弱性の報告は、開発者とユーザーの双方に過去の問題から学ぶ機会を与え、 責任ある開示により、私たち全員が、 慎重に発見を報告してくれた方々に感謝することができます。
注: Optechは、脆弱性の発見者が、 ユーザーへの危害のリスクを最小化するために合理的な努力をしたと考えられる場合にのみ、発見者の名前を公表しています。 このセクションで名前が上がっている方の洞察力とユーザーの安全に対する明確な配慮に感謝します。
2023年後半、Niklas Göggeは、彼が2年前に報告しLNDの修正バージョンがリリースされた 2つの脆弱性を公開しました。1つめはDoSの脆弱性で、 LNDがメモリ不足でクラッシュする可能性がありました。2つめは検閲の脆弱性で、 攻撃者が、LNDノードがネットワーク全体でターゲットチャネルの更新に関して学習するのを阻止できる可能性があります。 攻撃者はこれを利用して、ノードが支払いを送信する際に特定のルートを選択するように偏向させ、 転送手数料を増やし、ノードが送信した支払いに関するより多くの情報を攻撃者に与えることができます。
1月、Matt Morehouseは、Core Lightningのバージョン23.02から23.05.2に影響する 脆弱性を発表しました。彼が以前発見して開示した フェイクファンディングの修正を実装したノードを再テストした際、 約30秒の作業でCLNをクラッシュさせる競合状態を引き起こすことができました。 LNノードがシャットダウンすると、悪意ある取引相手や動作不良の取引相手からユーザーを保護できず、 ユーザーの資金が危険にさらされます。
1月にはまた、Göggeがbtcdフルノードで発見したコンセンサス障害の脆弱性を発表しました。 このコードは、トランザクションのバージョン番号を誤って解釈し、 相対的タイムロックを使用するトランザクションに誤ったコンセンサスルールを適用する可能性があります。 これにより、btcdフルノードはBitcoin Coreと同じ承認済みトランザクションを確認できなくなり、 ユーザーが資金を失うリスクにされされる可能性があります。
2月には、Eugene Siegelが、約3年前に最初に開示したBitcoin Coreの脆弱性の報告を公開しました。 この脆弱性は、Bitcoin Coreが最近のブロックをダウンロードするのを防止するのに使用される可能性があります。 この脆弱性を利用すると、接続されたLNノードがHTLCを解決するために必要なプリイメージを知ることができなくなり、 資金が失われる可能性があります。
6月には、Morehouseが再び、0.17.0未満のバージョンのLNDをクラッシュさせる脆弱性を開示しました。 前述したように、シャットダウンされたLNノードは、悪意ある取引相手や動作不良の取引相手から ユーザーを保護することができず、ユーザーの資金を危険にさらすことになります。
7月には、Bitcoin Coreの過去のバージョンに影響する複数の脆弱性の最初の公開がありました。 Wladimir J.Van Der Laanは、Bitcoin Coreが使用するライブラリで Aleksandar Nikolicが発見した脆弱性を調査していたところ、 リモートコード実行を可能にする別の脆弱性を発見しました。 この脆弱性は上流のライブラリで修正され、Bitcoin Coreに取り込まれました。 開発者のEvil-Knievelは、多くのBitcoin Coreノードのメモリを使い果たし クラッシュさせる脆弱性を発見しました。これは、 (LNユーザーなどから)資金を盗むたの他の攻撃の一部として使用される可能性があります。 John Newberyは、Amiti Uttarwarによる共同発見を引用し、 未承認トランザクションを検閲するために使用できる脆弱性を開示しました。 この脆弱性も(LNユーザーなどから)資金を盗むための攻撃の一部として使用される可能性があります。 CPUとメモリを過剰に使用しノードのクラッシュにつながる可能性のある脆弱性が報告されました。 開発者のpracticalswiftは、ノードが一定期間正当なブロックを無視する脆弱性を発見しました。 これはLNのようなコントラクトプロトコルに影響し、時間的な制約があるイベントへの対応を遅らせる可能性があります。 開発者のsec.eineは、CPUを過剰に消費する脆弱性を開示しました。 この脆弱性は、ノードが新しいブロックやトランザクションを処理できないようにするのに使用され、 資金の損失につながる可能性のある複数の問題を引き起こす可能性があります。 John Newberyは、多くのノードのメモリを使い果たし、クラッシュを引き起こす可能性のある別の脆弱性を責任を持って開示しました。 Cory Fieldsは、Bitcoin Coreをクラッシュさせる可能性のある別のメモリ枯渇の脆弱性を発見しました。 John Newberyは、帯域幅を浪費し、ユーザーのピア接続スロットの数を制限する可能性のある 3つめの脆弱性を開示しました。Michael Fordは、 BIP72 URLをクリックしたすべての人に影響し、ノードをクラッシュさせる可能性のある メモリ枯渇の脆弱性を報告しました。
その後の数ヶ月で、Bitcoin Coreからさらに多くの開示が行われました。
Eugene Siegelは、addr
メッセージを使用してBitcoin Coreをクラッシュさせる方法を発見しました。
Ronald Huveneersによるminiupnpcライブラリに関するレポートを調査していたMichael Fordは、
ローカルネットワーク接続を使用してBitcoin Coreをクラッシュさせる別の方法を発見しました。
David JaensonとBraydon Fullerおよび複数のBitcoin Core開発者は、
新しく起動したフルノードが最適なブロックチェーンに同期するのを妨げる脆弱性を発見しました。
この脆弱性は、Niklas Göggeによるマージ後のバグ修正で解消されました。
Niklas Göggeは、コンパクトブロックメッセージの処理の問題を悪用した
別のリモートクラッシュの脆弱性を発見しました。
複数のユーザーからCPUの消費量が多すぎるという報告があり、
開発者の0xB10CとAnthony Townsが原因を調査し解決策を実装しました。
William Casarinやghost43を含む複数の開発者からノードの問題が報告され、
Suhas DaftuarがBitcoin Coreが長時間ブロックを受け入れられない脆弱性を特定しました。
今年最後のBitcoin Coreの脆弱性レポートでは、
ブロックを10分以上遅らせる方法が説明されていました。
Lloyd FournierとNick FarrowおよびRobin Linusは、 Bitcoin署名デバイスから鍵を盗み出すための改良された方法Dark Skippyを発表しました。 この方法は、以前約15社のハードウェア署名デバイスベンダーに責任を持って公開されていました。 鍵の抽出 は、トランザクションに署名するコードが、秘密鍵やBIP32 HDウォレットのシードなど、 基盤となる鍵素材に関する情報を漏らすような方法で意図的に署名を作成する際に発生します。 攻撃者がユーザーのシードを入手すると、彼らはいつでもユーザーの資金を盗むことができます( 攻撃者が迅速に行動すれば、盗み出しにつながるトランザクションで使用される資金も含みます )。 これにより、抽出防止署名プロトコルに関する 新たな議論が起こりました。
新しいtestnetの導入により、新しいタイムワープ脆弱性も発見されました。 testnet4には元々あったタイムワープ脆弱性の修正が含まれていましたが、 開発者のZawyが8月に、難易度を約94%減らすことができる新しいエクスプロイトを発見しました。 Mark “Murch” Erhardtは、攻撃の難易度を最小値まで下げられるようさらに開発を進めました。 いくつかの解決策が提案され、それらのトレードオフについては12月時点でもまだ議論が続いてました。
10月、Antoine PoinsotとNiklas Göggeは、btcdフルノードに影響する 別のコンセンサス障害の脆弱性を公開しました。 Bitcoinのオリジナルのバージョン以来、ハッシュする前にスクリプトから署名を抽出するために使用される あまり知られていない(しかし重要な)関数が含まれています。btcdの実装は、 Bitcoin Coreに継承されたオリジナルバージョンとは若干異なっており、 攻撃者は、一方のノードでは受け入れられるものの、もう一方のノードでは拒否されるトランザクションを作成することができ、 さまざまな方法でユーザーに損失を与えることができます。
12月には、David Hardingが、デフォルトでEclair、LDK、LND(および非デフォルト設定のCore Lightning)に影響する 脆弱性を開示しました。チャネルの開設を要求し、チャネルを閉じる際に必要な 内部的な手数料を支払う責任がある参加者(開設者)は、 ある状態でチャネルの金額の98%を手数料として支払うことをコミットし、 次の状態で最小限の金額にコミットするよう削減し、チャネルの金額の99%を他の参加者に移動し、 その後98%を手数料として支払う状態でチャネルを閉じることができます。 これにより開設者は、古い状態を使用したことでチャネルの金額の1%を失いますが、 取引相手はチャネルの金額の98%を失います。開設者が自分でトランザクションをマイニングした場合、 手数料として支払われたチャネルの金額の98%を保持できます。 この方法では、ブロック毎に約3,000のチャネルで奪うことができます。
Wasabiと関連ソフトウェアに影響する非匿名化の脆弱性は、Optechが今年まとめた最後の開示でした。 この脆弱性により、WasabiやGingerWalletで使用されるタイプのCoinjoinコーディネーターは、 匿名であるはずのクレデンシャルをユーザーに提供し、追跡を可能にするために区別できるようすることができます。 クレデンシャルを区別する方法の1つは排除されましたが、コーディネーターが異なるクレデンシャルを生成することを可能にする より一般的な問題が2021年にYuval Kogmanによって特定され、この記事の執筆時点では未修正のままです。
3月
- ● BINANAとBIP: BIPのマージに関する継続的な問題により、1月に仕様やその他のドキュメント用に 新しくBINANAリポジトリが作成されました。2月、3月には、 既存のBIPエディターが支援を要請し、新しいエディターを追加するプロセスが始まりました。 4月に大規模な公開討論が最高潮に達した後、Bitcoinのコントリビューター数名がBIPエディターになりました。
- ● 強化された手数料の推定: Abubakar Sadiq Ismailが、リアルタイムのmempoolのデータを使用して Bitcoin Coreの手数料率の推定を強化する提案をしました。 現在の推定は、承認済みのトランザクションデータに依存しており、更新は遅いものの細工は困難です。 Ismailは、現在のアプローチと新しいmempoolベースのアルゴリズムを比較する予備的なコードを開発しました。 議論では、mempoolデータが推定値を上下に調整すべきか、それとも下げるだけにすべきかが強調されました。 二重調整により実用性は向上しますが、調整を下げた推定値に限定すると、細工をより効果的に防止できます。
- ● より効率的なトランザクションスポンサーシップ: Martin Habovštiakは、taproot annexを使用して無関係なトランザクションの優先順位を上げる方法を提案し、 以前の手数料スポンサーシップの方法と比較して、スペース要件を大幅に削減しました。 David Hardingは、署名コミットメントメッセージを使用して、 オンチェーンスペースを必要とせず、ブロックの順序に依存する、さらに効率的なアプローチを提案しました。 重複するスポンサートランザクションについては、HardingとAnthony Townsは、 ブースト毎に0.5 vbyteしか使用しない代替案を提案しました。Townsは、 これらのスポンサーシップの方法は提案中のクラスターmempoolの設計と互換性があるものの、 最も効果的なバージョンでは、ノードが有効性の情報を事前に計算して保存するのが難しいため、 トランザクションの有効性のキャッシュに若干課題があると指摘しました。 このスポンサーシップのアプローチでは、最小限のコストで動的な手数料の引き上げが可能になるため、 外部からの手数料を必要とするプロトコルにとって魅力的ですが、 トラストレスなアウトソースは依然として問題です。Suhas Daftuarは、 スポンサーシップは非参加ユーザーに問題を引き起こす可能性があると警告し、 意図しない影響を避けるために採用する場合はオプトインにすることを提案しました。
4月
- ● コンセンサスクリーンアップ: Antoine PoinsotがMatt Coralloの2019年のコンセンサスクリーンアップ提案を再検討し、 検証が遅いブロックや、盗難を可能にするタイムワープ攻撃、軽量クライントとフルノードに影響する フェイクトランザクションの脆弱性などの問題に対処します。 Poinsotはまた、ブロック1,983,702でフルノードに影響する重複トランザクションの問題にも焦点を当てました。 すべての問題にはソフトフォークによる解決策がありますが、検証の遅いブロックに対する1つの修正案では、 稀な事前署名済みトランザクションが無効になる可能性があるという懸念がありました。 提案された更新の1つは、軽量クライアントや(場合によっては)フルノードに影響するマークルツリーの脆弱性を軽減する代替方法を検討するもので、 8月、9月に重要な議論が行われました。 Bitcoin Coreは可能な限り脆弱性を軽減しましたが、以前のリファクタリングで重要な保護が削除されたため、 Niklas GöggeはBitcoin Core用に現在検出可能なすべての脆弱性を可能な限り早く検出し、 無効なブロックを拒否するコードを作成しました。12月には、コンセンサスクリーンアップソフトフォークを使用して、 元のコンセンサスクリーンアップ提案用に設計されたルールをtestnet4に実装した後に発見された タイムワープ脆弱性のZawy-Murchバージョンを修正することについて議論が行われました。
- ● BIPプロセスの改革: 新しいBIPエディターの追加に関する議論から派生して、 新しいBIPの追加と既存のBIPの更新に関する現在のプロセスを規定するBIP2の改革が望まれました。 議論は翌月も続き、9月には更新されたプロセス用のBIPのドラフトが公開されました。
- ● インバウンドルーティング手数料: LNDが、Joost Jagerが推進するインバウンドルーティング手数料をサポートし、 ノードはピアから受信した支払いに対してチャネル固有の手数料を請求できるようになります。 これにより、ノードは流動性を管理しやすくなり、 たとえば管理の不十分なノードからのインバンド支払いに対してより高い手数料を課すことができます。 インバウンド手数料は、後方互換性があり、最初は旧ノードと連携するためにマイナス(割引など)に設定されています。 数年前に提案されたものの、他のLN実装は、設計上の懸念や互換性の問題を理由にこの機能に抵抗してきました。 この機能はLNDで年間を通して開発が続けられました。
- ● 弱ブロック: Greg Sandersが、トランザクションリレーとマイニングのポリシーが異なる中で、 弱ブロック(Pow(Proof-of-Work)が不十分なものの有効なトランザクションを含むブロック)を使用して コンパクトブロックリレーを改善する提案を行いました。 マイナーは、マイニングしようとするトランザクションを反映して、PoWの割合に比例した弱ブロックを生成します。 弱ブロックは、作成コストが高いため悪用されにくく、過剰な帯域幅を浪費することなく mempoolとキャッシュを更新することができます。これにより、マイナーが非標準トランザクションをブロックに含めた場合でも、 コンパクトブロックリレーの有効性が維持されます。弱ブロックは、Pinning攻撃への対処や、手数料率の推定の強化にもなります。 SandersのPoC実装はこのアイディアを実証しています。
- ● testnetの再起動: Jameson Loppが、4月に現在のBitcoinの公開testnet(testnet3)の問題について議論を開始し、 特殊ケースのコンセンサスルールのセットを使用して、testnetを再起動することを提案しました。 5月には、Fabian JahrがBIPのドラフトとtestnet4の実装の提案を発表しました。 BIPとBitcoin Coreの実装は8月にマージされました。
- ● 開発者の逮捕: 4月は、プライバシーソフトウェアに注力する2人のBitcoin開発者の逮捕と 法的リスクを理由に米国へのサービスを停止する意向を発表した少なくとも2社のニュースで残念な終わりを迎えました。
2024年のまとめ: クラスターmempool
2023年からのmempoolの再設計のアイディアは、2024年を通して、 複数のBitcoin Core開発者にとって特に焦点となりました。クラスターmempoolを使用すると、 マイナーがローカルノードのmempoolと同じmempoolを持っている場合に、 マイナーが作成するすべてのブロックに対するトランザクションの影響をより簡単に推論できるようになります。 これによりトランザクションの排除がより合理的になり、置換トランザクション(またはトランザクションのセット)が 置換元のトランザクションよりも優れているかどうかを判断するのに役立ちます。 これはLNのようなコントラクトプロトコルに影響を及ぼす複数の問題(資金を危険にさらすこともある)に関係する さまざまなmempoolの制限に対処するのに役立ちます。
さらに、Abubakar Sadiq Ismailの1月の投稿に見られるように、 クラスターmempoolの設計から得られる洞察とツールは、 Bitcoin Coreにおける手数料の推定を改善する可能性があります。 現在、Bitcoin Coreは、CPFPによる手数料の引き上げをサポートするインセンティブ互換の方法として、 祖先の手数料率によるマイニングを実装していますが、手数料の推定は、 個々のトランザクションに対して実行されるため、CPFPによる手数料の引き上げは考慮されません。 クラスターmempoolは、トランザクションのグループをチャンクに分割します。 チャンクはmempool内で一緒に追跡され、マイニングされたブロック内に配置される可能性があるため、 手数料の推定を改善できます(特に、パッケージリレーや、 P2A、外部からの手数料供給などの CPFP関連の技術の使用が増加する場合)。
クラスターmempoolプロジェクトが成熟するのに合わせて、そのアーキテクトによって 複数の説明と概要が作成されました。Suhas Daftuarが1月に概要を示し、 課題の1つである、既存のCPFP carve-outポリシーと互換性がないことを明らかにしました。 このジレンマを解決するには、carve-outの既存のユーザーが TRUCトランザクションにオプトインし、 機能セットを改良することが考えられます。クラスターmempoolの別の詳細な説明が、 7月にPieter Wuilleから投稿されました。この説明では、基本原則や提案されたアルゴリズムについて説明され、 いくつかのプルリクエストがリンクされていました。 これらのプルリクエストのいくつかと 他のプルリクエストは、その後マージされました。
Daftuarは、クラスターmempoolとTRUCトランザクションなどの関連提案について、 さらに検討と調査を行いました。2月に、彼はreplace-by-feerateなどのアイディアのインセンティブ互換性や、 ハッシュレートが不均衡なマイナーのインセンティブの違いについて考慮し、 DoS耐性のないインセンティブ互換性の動作を探しました。 4月には、もしクラスターmempoolが1年早く導入されていたらどうなっていたかを調査し、 mempoolに若干多くのトランザクションを入れることができ、データ上のトランザクションの置換に大きな影響を与えず、 短期的にはマイナーがより多くの手数料を獲得するのに役立つ可能性があることを発見しました。 Pieter Wuilleは8月に、ブロックを構築するマイナーのために ほぼ最適なトランザクションの選択をするための原則と効率的なアルゴリズムを説明することで、 最後のポイントを構築しました。
5月
- ● サイレントペイメント: サイレントペイメントをより広く利用できるようにするための取り組みが今年も続きました。 Josie Bakerは、Andrew Tothのドラフト仕様に基づいて、サイレントペイメント(SP)用のPSBT拡張に関する議論を開始しました。 この議論は6月に入っても続き、ECDH共有を使用してトラストレスな調整を行うことを検討しました。 それとは別に、Setor Blagogeeは、軽量クライアントがサイレントペイメントを受け取るのを支援するプロトコルのドラフト仕様を投稿しました。 6月には基本のSP仕様にいくつかの調整が加えられ、 提案されたPSBT機能の2つのドラフトBIPが作成されました。
- ● BitVMX: Sergio Demian Lernerと数人の共著者は、BitVMの背後にあるアイディアに一部基づいた 新しい仮想CPUアーキテクチャに関する論文を発表しました。 彼らのプロジェクトであるBitVMXの目標は、RISC-Vなどの確立されたCPUアーキテクチャ上で実行するためにコンパイルできる すべてのプログラムの適切な実行を効率的に証明できるようにすることです。 BitVMと同様に、BitVMXでもコンセンサスの変更は必要ありませんが、信頼できる検証者として行動する1人以上の指定された当事者が必要です。 つまり、複数のユーザーが対話的にコントラクトプロトコルに参加することで、 コントラクトで指定された任意のプログラムを当事者が実行しない限り、 当事者の1人(または複数)がコントラクトから資金を引き出すことを阻止できます。
- ● 匿名使用トークン: Adam Gibsonが、UTXOをkey-pathで使用できる人なら誰でも、 どのUTXOか明らかにすることなく、それを使用できることを証明できるようにするために開発した 匿名使用トークンスキームについて説明しました。 彼が強調する用途の1つは、LNチャネルをアナウンスする際に、 そのチャネルのベースとなるUTXOの所有者を特定する必要がないようにすることです。 UTXOの特定は、帯域幅を浪費するサービス拒否攻撃を防止するために現在必須となっています。 Gibsonはまた、サインアップに匿名のプルーフを提供する必要がある概念実証のフォーラムを作成しました。 これにより、誰もがビットコインの所有者であることは分かるものの、 誰も自分自身や自分のビットコインに関する識別情報を提供する必要がない環境を作り出しました。 その後、Johan Halsethは、異なるメカニズムを用いてほぼ同じ目標を達成する概念実証の実装を発表しました。
- ● LNチャネルのアップグレード: 何年もの間、LNの開発者たちは、既存のチャネルをさまざまな方法でアップグレードできるように、LNプロトコルを変更することについて議論してきました。 5月に、Carla Kirk-Cohenは、これらのケースのいくつかを検証し、 アップグレードの3つの異なる提案を比較しました。6月には、 アップグレードやその他の機密性の高い操作をサポートするために、 LN仕様に静止プロトコルが追加されました。 10月には、新しいTaprootベースのファンディングトランザクションをサポートする チャネルアナウンスプロトコルの更新案の開発が再開されました。
- ● プールマイナー向けEcash: Ethan Tuttleが、マイニングプールがマイニングしたシェアの数に比例して マイナーにecashトークンを報酬として与えることができる提案をDelving Bitcoinに投稿しました。 マイナーは、そのトークンをすぐに売却まはた譲渡するか、プールがブロックをマイニングをするまで待ち、 見つかった時点でsatoshiとトークンを交換することができます。ただし、 Matt Coralloは、大規模なプールで実装されている標準化された支払い方法がないため、 プールマイナーが短期間で支払われるべき金額を計算できないという懸念を提起しました。 つまり、メインプールが支払いを騙し始めた場合、その支払いがecashであれ、 他のメカニズムであれ、マイナーはすぐに別のプールに切り替えることはありません。
- ● Miniscriptの仕様: Ava Chowが5月に、MiniscriptのBIPを提案し、 7月にBIP379になりました。
6月
- ● LN支払いの実行可能性とチャネルの枯渇: René Pickhardtが、チャネルキャパシティ内での可能な富の分配を分析することで、 LN支払いの実行可能性を推定する研究を行いました。 たとえば、アリスがボブを経由してキャロルに1 BTCを送金したい場合、成功の可能性は、 アリス-ボブおよびボブ-キャロルのチャネルが送金をサポートできるかどうかによって決まります。 この指標は、実際の支払いの制約を強調し、ウォレットやビジネスソフトウェアがよりスマートなルーティングを決めるのに役立ち、 LN支払いの成功率を向上させます。今年の後半、Pickhardtの研究は、 チャネル枯渇(チャネルが特定の方向に資金を転送できなくなること)の原因と可能性に関する洞察を提供しました。 また、チャネルファクトリーなどのk>2のマルチパーティチャネル管理プロトコルにより、 実行可能な支払いの数が大幅に増加し、チャネル枯渇率を低下できることも示しました。
- ● 量子耐性のあるトランザクション署名: 開発者のHunter Beastは、バージョン3のsegwitアドレスを量子耐性のある署名アルゴリズムに割り当てるための 「ラフなドラフト」BIPを投稿しました。ドラフトBIPでは、この問題について説明し、 いくつかのアルゴリズム候補とその予想されるオンチェーンサイズをリンクしています。 アルゴリズムの選択と具体的な実装の詳細は今後の議論に委ねられました。
2024年のまとめ: P2Pトランザクションリレー
手数料管理は、分散型のBitcoinプロトコルでは常に課題となっていましたが、 LN-Penaltyなどのコントラクトプロトコルの普及と、より新しく複雑なプロトコルの継続的な研究により、 ユーザーが要求に応じて手数料を支払い、増額できることを保証することがこれまで以上に重要になっています。 Bitcoin Coreのコントリビューターは、この問題に何年も取り組んでおり、 2024年には状況を大幅に改善するいくつかの新機能が公開されました。
1月は、以前導入されたCPFP carve-outポリシーのより堅牢な代替手段を提供する TRUC提案の最悪のケースのPinningコストに関する 議論から始まりました。TRUCの最悪のケースのコストはるかに低いものの、 開発者はいくつかのパラメーターを微調整することでコストをさらに下げることができるかどうかを検討しました。 1月の別の議論では、外部的な手数料の調達が増えると、 マイナーへの帯域外の手数料支払いを使用する方がオンチェーンより効率的(したがって安価)になり、 マイニングの分散化が危険にさらされるという理論上のリスクが検討されました。 Peter Toddは、この懸念に対処するために、別の手数料管理方法を提案しました。 これは、各決済トランザクションの複数のバリエーションをさまざまな手数料率で事前に署名することで、 手数料を完全に内部的に保持するというものです。しかし、このアプローチには複数の問題が特定されました。
1月にGregory Sandersが行った追加の議論では、 LNプロトコルがトリムされたHTLCの資金を P2Aアウトプットに入れるのにリスクがあるかどうかが検討されました。 これにより、mempoolのトランザクションのマイニングに必要な範囲を超えて特別なソフトウェアを実行するマイナーが、 MEV(miner extractable value)を実行できるようになる可能性があります。 Bastien Teinturierは、TRUCおよびP2Aアウトプットを使用するコミットメントトランザクションを処理するために LNプロトコルにどのような変更が必要かという議論を開始しました。 これには、Sandersが検討したトリムされたHTLCの提案、不要になる1ブロックの遅延の排除、 オンチェーントランザクションサイズの削減が含まれます。この議論により、 LNの既存のCPFP carve-outの使用に似たトランザクションにTRUCルールを自動的に適用し、 LNソフトウェアをアップグレードすることなくTRUCの利点を提供する組み込みTRUCの提案も行われました。
1月は、Gloria Zhaoによる、手数料による兄弟の入れ替えの提案で終わりました。 通常のRBFルールは、競合するトランザクションにのみ適用され、 有効なブロックチェーンには1つのバージョンしか存在できないため、 ノードはmempoolに1つのバージョンのトランザクションのみを受け入れます。 ただし、TRUCでは、ノードは未承認のバージョン3の親トランザクションの子孫を1つだけ受け入れます。 これは、競合トランザクションと非常によく似た状況です。 ある子孫が同じトランザクションの別の子孫を置き換えることを許可するということ、つまり 兄弟の排除 は、TRUCトランザクションの手数料の引き上げを改善し、組み込みTRUCが採用された場合に特に有益です。
2月は、LNプロトコルをCPFP carve-outからTRUCに移行することの影響に関する追加の議論から始まりました。 Matt Coralloは、ファンディングトランザクションと即時クローズトランザクションの両方が未承認になる可能性があり、 TRUCの未承認トランザクションが2つという制限により、CPFPによる手数料の引き上げを含む3つめのトランザクションを使用できないため、 既存のゼロ承認チャネルの開設をTRUCの使用に適応させるのに 課題があることを発見しました。Teinturierは、 スプライシングのチェーンが使用される場合の同様の問題を特定しました。 議論は明確な結論には至りませんでしたが、 各トランザクションにCPFPによる手数料の引き上げ用の(TRUCの前に必要な)独自のアンカーが含まれるようにするという回避策は、 満足のいくものであるように思われ、誰もがクラスターmempoolによって 将来TRUCルールの一部が緩和され、より柔軟なCPFPによる手数料の引き上げが可能になることを望んでいました。
クラスターmempoolの進歩によるTRUCポリシーの変更について、Gregory Sandersは 将来のポリシー変更に関するいくつかのアイディアを説明しました。 対照的に、Suhas Daftuarは、前年にノードが受信したすべてのトランザクションを分析し、 TRUCポリシーが組み込まれた場合、それらのトランザクションの受け入れにどのような影響があったかを確認しました。 CPFP carve-outポリシーで以前受け入れられたトランザクションのほとんどは、 TRUCポリシーが組み込まれた場合でも受け入れられましたが、 組み込みポリシーを採用する前にソフトウェアの変更が必要になる可能性のある例外がいくつかありました。
今年始めの活発な議論の後、5月と6月にはBitcoin Coreに新しいリレー機能のサポートを追加する一連のマージが行われました。 P2Pプロトコルの変更を必要としない限定的な1P1C(one-parent-one-child) パッケージリレーが追加されました。その後のマージで、 Bitcoin Coreのオーファントランザクションの処理を強化することで1P1Cパッケージリレーの信頼性が向上しました。 TRUCの仕様がBIP431としてBIPのリポジトリにマージされました。 TRUCトランザクションは、別のマージによりデフォルトでリレー可能になりました。 (TRUCパッケージを含む)1P1CクラスターのRBFのサポートも追加されました。
2人の長年の開発者が7月にTRUCに対する詳細な批判を書きましたが、 他の開発者は彼らの懸念に応えました。同じ2人の開発者によるさらなる批判が8月に発表されました。
Bitcoin Core開発者は、リレーの改善に取り組み、8月にP2A(Pay-to-Anchor)の サポートをマージし、10月に1P1Cパッケージリレー、TRUCトランザクションリレー、 パッケージRBFと兄弟の入れ替えおよび標準P2Aアウトプットスクリプトタイプをサポートした Bitcoin Core 28.0をリリースしました。これらすべての機能の開発に貢献したGregory Sandersは、 Bitcoin Coreを使用してトランザクションを作成またはブロードキャストするウォレットやその他のソフトウェアの開発者が どのように新しい機能を活用できるかを解説しました。
今年後半には、P2Aを使用するエフェメラルダストのサポートが マージされ標準となりました。これにより、手数料ゼロのトランザクションを、 関連するすべての手数料を支払う子トランザクションによって引き上げることができるようになり、 純粋な外部からの手数料の調達が可能になります。
Optechの今年最後のニュースレターでは、1P1Cパッケージリレーのさらなる改善について議論した Bitcoin Core PR Review Clubミーティングの概要が紹介されました。
7月
- ● BOLT11インボイス用のブラインドパス: Elle Moutonが、BOLT11インボイスにブラインドパスフィールドを追加するBLIPを提案しました。 これにより支払いの受取人は、ノードのIDとチャネルピアを隠すことができます。たとえば、 ボブは彼のインボイスにブラインドパスを追加し、アリスのソフトウェアがそれをサポートしている場合は プライベートに支払いを行うことができます。サポートしていない場合はエラーになります。 Moutonは、ブラインドパスをネイティブにサポートするオファーが広く採用されるまでの一時的な解決策として これを考えています。この提案は、8月にBLIP39となりました。
- ● 閾値署名用のChillDKG鍵生成: Tim RuffingとJonas Nickが、BitcoinのSchnorr署名と互換性のある FROSTスタイルのスクリプトレスな閾値署名の鍵を安全に生成するための BIPドラフトと参照実装であるChillDKGを提案しました。ChillDKGは、 FROSTのよく知られた鍵生成アルゴリズムと最新の暗号プリミティブを組み合わせて、 整合性と検閲耐性を確保しながら参加者間でランダムな鍵コンポーネントを安全に共有します。 暗号化には楕円曲線ディフィー・ヘルマン(ECDH)を使用し、署名されたセッショントランスクリプトの検証には、 認証されたブロードキャストを使用します。参加者は最終的な公開鍵を受け入れる前にセッションの完全性を確認します。 このプロトコルは鍵管理を簡素化し、ユーザーは自分の秘密のシードといくつかの非機密のリカバリーデータのみをバックアップする必要があります。 シードを使用してリカバリーデータを暗号化する計画は、プライバシーを強化し、 ユーザーのバックアップをさらに簡素化することを目的としています。
- ● MuSig用のBIPと閾値署名: 7月には、異なるソフトウェアが相互作用してMuSig2署名を作成するのを助ける いくつかのBIPがマージされました。月の後半には、 Sivaram Dhakshinamoorthyが、BitcoinのSchnorr署名の実装用に スクリプトレスな閾値署名を作成するためのBIPの提案を発表しました。 これにより、(ChillDKGを使用するなどして)既にセットアップ手順を実行した署名者のセットが、 その署名者の動的なサブセットとの対話のみで署名を安全に作成できるようになります。 この署名は、シングルシグのユーザーによって作成されたSchnorr署名とオンチェーンで区別がつかず、 プライバシーとファンジビリティが向上します。
8月
- ● Hyperionネットワークシミュレーター: Sergi Delgadoが、シミュレートされたBitcoinネットワークを通じてデータがどのように伝播されるかを追跡する ネットワークシミュレーターHyperionをリリースしました。 この研究は、当初、Bitcoinの現在のトランザクションアナウンス方式と、 提案中のErlay方式を比較したいという思いから始まりました。
- ● フルRBF: 開発者の0xB10Cが、最近のコンパクトブロックの再構築の信頼性を調査しました。 新しいブロックには、ノードが確認したことのないトランザクションが含まれていることがあります。 その場合、コンパクトブロックを受信するノードは通常、送信ピアにそれらのトランザクションを要求し、 ピアからの応答を待つ必要があります。これによりブロックの伝播が遅くなります。 この研究は、Bitcoin Coreでデフォルトでmempoolfullrbfを有効にするためのプルリクエストのきっかけとなり、 後にマージされました。
2024年のまとめ: コベナンツとスクリプトのアップグレード
2024年には、何人かの開発者が、コベナンツやスクリプトのアップグレード、 Joinpoolやチャネルファクトリーといった 高度なコントラクトプロトコルをサポートするためのその他の変更に関する提案の推進に多くの時間を割きました。
2023年12月下旬、Johan Torås Halsethは、MATTソフトフォーク提案の
OP_CHECKCONTRACTVERIFY
opcodeを使用して、任意のプログラムが正常に実行された場合に、
コントラクトプロトコルの当事者が資金を請求できる概念実証プログラムを発表しました。
これは、BitVMとコンセプトが似ていますが、プログラム実行の検証用に特別に設計されたopcodeを使用するため、
Bitcoinの実装はよりシンプルです。Elftraceは、LinuxのELFフォーマットを使用して
RISC-Vアーキテクチャ用にコンパイルされたプログラムで動作します。
ほとんどのプログラマーがその対象のプログラムを簡単に作成できるため、
Elftraceを使用するのは非常に身近なものとなっています。Halsethは8月に、
OP_CAT opcodeと組み合わせてゼロ知識証明を検証する機能をもったElftraceに関する
更新情報を提供しました。
1月には、OP_CHECKTEMPLATEVERIFY (CTV)と
OP_CHECKSIGFROMSTACK (CSFS)の以前の提案と、
Taprootの内部鍵をスタックに配置するOP_INTERNALKEY
の新しい提案を含む
LNHANCEの組み合わせソフトフォークの提案が発表されました。
今年の後半には、提案は更新され、OP_CAT
に似た機能を提供するものの、
意図的にコンポーザビリティが制限されたOP_PAIRCOMMIT
も含まれるようになります。
この提案は、CTVスタイルの輻輳制御やCSFSスタイルの署名の委任など、
基盤となる提案で説明されている利点に加えて、LN-Symmetryや
ArkスタイルのJoinpool、署名の削減されたDLC、
Vaultの開発を可能にすることを目的としています。
Chris Stewartが、将来のソフトフォークでBitcoin Scriptで64-bitの算術演算を可能にするための BIPのドラフトを投稿しました。Bitcoinは現在、32-bitの演算のみを許可しています( 符号付き整数を使用しているため、約20億を超える数値は使用できません)。64-bitのサポートは、 アウトプット内で支払われるsatoshiの金額を操作する必要がある構成で特に役立ちます。 これは64-bit整数を使用して定義されているためです。 この提案は、2月と6月に追加の議論が行われました。
2月にはまた、開発者のRijndaelが、現在のコンセンサスルールと提案中のOP_CAT opcodeにのみ依存するVaultのPoC実装を作成しました。
OptechはOP_CAT
Vaultを、現在可能な事前署名トランザクションによるVaultと、
BitcoinにBIP345 OP_VAULT
が追加された場合に可能なVaultと比較しました。
事前署名版 |
BIP345 OP_VAULT
|
OP_CAT とSchnorr
|
|
---|---|---|---|
有効性 | 現在利用可能 |
OP_VAULT とOP_CTVのソフトフォークが必要
|
OP_CAT のソフトフォークが必要
|
直前のアドレス置換 | 脆弱 | 脆弱ではない | 脆弱ではない |
一部の引き出し | 事前に取り決めがある場合のみ可能 | 可能 | 不可能 |
静的で非対話型の計算可能なデポジットアドレス | 不可能 | 可能 | 可能 |
手数料節約のためのRe-Vault/隔離のバッチ化 | 不可能 | 可能 | 不可能 |
最良(つまり正当な使用)の場合の効率(Optechによる非常に大まかな推定) | 通常のシングルシグの2倍のサイズ | 通常のシングルシグの3倍のサイズ | 通常のシングルシグの4倍のサイズ |
3月、開発者のZmnSCPxjは、特定のソフトフォークがアクティベートされたかどうかを 正しく予測した参加者にUTXOの制御を与えるプロトコルについて説明しました。 この基本的なアイディアは以前にも提案されていますが、ZmnSCPxjのバージョンは、 少なくとも1つ将来のソフトフォークで期待される仕様、OP_CHECKTEMPLATEVERIFYを扱っています。
3月はまた、Anthony TownsがLisp言語をベースとしたBitcoin用のスクリプト言語の開発に着手しました。 彼は、既にアルトコインChiaで使用されているLispスタイルの言語の概要を提供し、 BTC Lisp言語を提案しました。今年の後半、 Bitcoin ScriptとMiniscriptの関係に触発された彼は、 Lispプロジェクトを、ソフトフォークでBitcoinに追加可能な低レベルのBitcoin Lisp言語(bll)と、 bllに変換される高水準言語シンボリックbll(symbll)の2つに分割しました。 彼はまた、UTXOを特定の金額と使用条件に分割できる、 symbllと(そしておそらくSimplicityとも)互換性のある 汎用的な構成についても説明しました。 彼は、これらの柔軟なコインの用途指定がどのように使用できるかを示しました。これには、 LNチャネル(LN-Symmetryベースのチャネルも含む)のセキュリティと ユーザービリティの改善、BIP345バージョンのVaultの代替、 ペイメントプールの設計が含まれます。
Jeremy Rubinが5月に、OP_CHECKTEMPLATEVERIFY
の設計の2つの更新を提案しました。
オプションでより短いハッシュダイジェストのサポートと、追加のコミットメントのサポートです。
これは、LN-Symmetryや同様のプロトコルで重要なデータを復元するのに役立つ可能性のある
データ公開スキームでの使用にCTVを最適化するのに役立ちます。
Pierre Rochardが、同様のコストで同じ機能を多く提供できる提案中のソフトフォークは 相互に排他的であると考えるべきか、あるいは複数の提案をアクティベートして 開発者が好みの代替方法を使用できるようにするのが理にかなっているかを尋ねました。
Jeremy Rubinが、関数型暗号を使用して、コンセンサスの変更を必要とせずに Bitcoinに完全なコベナンツの動作を追加する理論に関する論文を公開しました。 関数型暗号は、特定のプログラムに対する公開鍵の作成を可能にします。 そのプログラムを満たすことができる参加者は、(対応する秘密鍵を知ることなく) 公開鍵に対応する署名を作成することができます。これは常によりプライベートで、 これまで提案されたコベナンツと比較して、スペースを節約することができます。 残念ながら、Rubinによると、関数型暗号の主な欠点は、 それが「現在のところ実用的ではないほど未発達な暗号」であるということです。
Anthony Townsが、OP_CATを使用して、 誰でもスクリプトに送られたコインをPoW(Proof of Work)で使用することができる signet用のスクリプトを投稿しました。 これは分散型のsignet-bitcoin Faucetとして使うことができます。 マイナーやユーザーが余ったsignet bitcoinを手に入れると、それをスクリプトに送信します。 signet bitcoinがほしいユーザーは、そのスクリプトへの支払いをUTXOセットから検索し、 そのコインを入手するためのPoWを行い、トランザクションを作成します。
Victor Kolobovが、OP_CAT
opcodeを追加するソフトフォーク案の研究に
100万ドルの資金を提供すると発表しました。
提出期限は2025年の1月1日です。
11月、Townsは、Bitcoin Inquisitionを通じて利用可能なソフトフォーク案に関連する デフォルトsignet上の活動をまとめました。 Vojtěch StrnadはTownsの投稿に触発され、「デプロイされたソフトフォークを使用するBitcoin signet上で作成された すべてのトランザクション」をリストアップするウェブサイトを作成しました。
Ethan Heilmanが、Victor Kolobov、Avihu LevyおよびAndrew Poelstraと共同執筆した論文を投稿しました。 この論文では、コンセンサスの変更なしにコベナンツを簡単に作成できる方法について説明していますが、 それらのコベナンツから支払いをする場合、非標準のトランザクションと数百万ドル(または数十億ドル)相当の特殊なハードウェアと 電力が必要になります。Heilmanは、この研究の応用の1つとして、量子耐性が突然必要になり、 Bitcoinの楕円曲線の署名演算が無効になった場合に、 ユーザーが安全に使用できるバックアップのTaproot支払い条件を簡単に組み込めることを示しています。 この研究は、Bitcoin用のランポート署名に関する著者の以前の研究に触発された部分もあるようです。
12月は、選択されたコベナンツの提案に関する開発者の意見投票で締めくくられました。
2025年1月から、Optechは毎月最初に発行されるニュースレターの特別セクションで、 コベナンツ、スクリプトのアップグレードおよび関連する変更について、注目すべき研究と開発の掲載を始めます。 私たちは、これらの提案に取り組んでいる皆さんに、 私たちの通常の情報源にとって興味深いことがあれば、 それについて書けるよう発表することをお勧めします。
9月
- ● ハイブリッドチャネルジャミングの緩和策のテストと調整: Carla Kirk-Cohenが、もともとClara ShikhelmanとSergei Tikhomirovによって提案された ハイブリッドチャネルジャミングの緩和策のテストと調整について説明しました。 チャネルを1時間妨害する試みは、攻撃者が既知の攻撃を使用するよりも多くの時間を費やしたか、 または意図せずに対象の収入を増やしたため、ほとんど失敗しました。ただし、 シンク攻撃は、より短い経路の支払いを妨害することで、ノードのレピュテーションを効果的に損ないました。 これに対抗するために、双方向のレピュテーションがHTLCエンドースメントに追加され、 この提案は、2018年にJim Posenが最初に提案したアイディアに近づきました。 ノードは、支払いを転送するかどうかを決める際に、送信者と受信者の両方の信頼性を評価するようになりました。 信頼性の高いノードは、エンドースされたHTLCを受け取りますが、 信頼性の低い送信者または受信者は拒否されるか、エンドースされていない転送に直面します。 このテストは、HTLCエンドースメントの仕様とEclairでの実装に従って行われました。年末直前にLNDの実装も追加されました。
- ● シールドCSV: Jonas NickとLiam Eagen、Robin Linusが、 新しいClient-Side Validation(CSV)プロトコルである シールドCSVを発表しました。このプロトコルは、 トークンの詳細や転送履歴を公開することなく、BitcoinのProof of Workによって保護されたトークンの転送を可能にします。 クライアントが広範なトークンの履歴を検証する必要がある既存のプロトコルとは異なり、 シールドCSVはゼロ知識証明を使用して、プライバシーを維持しながら、 検証が固定リソースで済むことを保証します。さらにシールドCSVでは、 何千ものトークンの転送をBitcoinのトランザクションあたり64-byteの更新にバンドルすることで、 オンチェーンデータ要件を削減し、スケーラビリティを強化します。 論文では、BitVMを介したトラストレスなBitcoin-to-CSVブリッジ、 アカウントベースの構造、ブロックチェーンの再編成の処理、未承認トランザクションおよび 潜在的な拡張性についても検討しています。このプロトコルは、他のトークンシステムよりも 大幅な効率性とプライバシーの向上を約束します。
- ● LNオフライン支払い: Andy Schroderが、オンライン時に認証トークンを生成することで、 LNのオフライン支払いを可能にするプロセスを概説しました。 これにより、支払人のウォレットは、オフライン時に常時オンラインのノードまたはLSPを介して支払いを承認できます。 トークンはNFCまたはその他のシンプルなプロトコルを介して受信者に転送できるため、 インターネットにアクセスせずに支払いを行うことができます。開発者のZmnSCPxjは代替案を提案し、 Bastien Teinturierは同様のユースケースにおける彼のリモートノードの制御方法を提供し、 スマートカードのようなより限られたリソースのデバイス用のオフライン支払いソリューションを強化しました。
10月
- ● BOLT12オファー: オファーの仕様BOLT12がマージされました。 当初2019年に提案されたオファーは、 2つのノードがOnionメッセージを使用してLN上で インボイスと支払いのネゴシエーションを行えるようにします。 Onionメッセージとオファー互換の支払いはどちらも、送信者が受信者のノードの身元を知るのを防ぐために ブラインドパスを使用できます。
2024年のまとめ: 人気のインフラストラクチャプロジェクトのメジャーリリース
-
● LDK 0.0.119では、マルチホップブラインドパスへの支払いをサポートしました。
-
● Core Lightning 24.02では、
recover
プラグインが改善され 「緊急時のリカバリーがストレスなく行える」ようになった他、 アンカーチャネルが改善され、 ブロックチェーンの同期が50%高速化され、testnetで発見された巨大なトランザクションのパース処理のバグが修正されました。 -
● Eclair v0.10.0では、「デュアルファンディング機能の公式サポート、 BOLT12オファーの最新実装、完全に機能するスプライシングプロトタイプが 追加されました」。
-
● Bitcoin Core 27.0では、libbitcoinconsensusが非推奨となり、 デフォルトでv2暗号化P2Pトランスポートが有効になり、 テストネットワークでオプトインの承認までトポロジーが制限される(TRUC)トランザクションポリシーが許可され、 手数料率が高いときに使用する新しいコイン選択戦略が追加されました。
-
● BTCPay Server 1.13.1(および以前のリリース)では、 ウェブフックの拡張性が向上し、BIP129マルチシグウォレットインポートをサポートし、 プラグインの柔軟性が向上し、すべてのアルトコインのサポートがプラグインに移行され、 BBQrエンコードされたPSBTがサポートされました。
-
● Bitcoin Inquisition 25.2では、signetでOP_CATをサポートしました。
-
● Libsecp256k1 v0.5.0では、鍵生成と署名が高速化され、 コンパイル後のサイズが削減され「開発者は特に組み込みユーザーにメリットがあると予想していました」。
-
● LDK v0.0.123では、トリムされたHTLC用の設定の更新と、 オファーのサポートの改善が含まれています。
-
● Bitcoin Inquisition 27.0では、BIN24-1およびBIP347で定義されている OP_CATのsignetでの適用が追加されました。また、「スクリプトのopcodeの動作をテストするために使用できる
bitcoin-util
の新しいサブコマンドevalscript
」も追加されました。annexdatacarrier
と疑似エフェメラルアンカーのサポートは廃止されました。 -
● LND v0.18.0-betaでは、インバウンドルーティング手数料、 ブラインドパス用の経路探索、 Simple Taproot Channel用のウォッチタワーの実験的サポートと 暗号化されたデバッグ情報の効率的な送信が追加されました。
-
● Core Lightning 24.05では、プルーニングされたフルノードとの互換性が向上し、
check
RPCがプラグインで動作できるようになり、オファーのインボイスがより堅牢に配信できるようになり、ignore_fee_limits
設定オプションが使用された際の手数料の過払いの問題が修正されました。 -
● Bitcoin Core 28.0では、testnet4、 1P1C(opportunistic one-parent-one-child)パッケージリレー、 オプトインのTRUC(topologically restricted until confirmation)トランザクションのデフォルトリレー、 pay-to-anchorトランザクションのデフォルトリレー、 制限付きのパッケージRBFリレーをサポートし、 フルRBFがデフォルトとなりました。assumeUTXOのデフォルトパラメーターが追加され、 Bitcoinネットワークの外部(torrent経由など)からダウンロードされたUTXOセットを使用して
loadtxoutset
RPCを実行できるようになりました。 -
● BTCPay Server 2.0.0では、「ローカライゼーションの改善、サイドバーナビゲゲーション、 オンボーディングフローの改善、ブランディングオプションの改善、プラグイン可能なレートプロバイダーのサポート」が追加されました。 このアップグレードには、いくつかの破壊的な変更とデータベースのマイグレーションが含まれています。
-
● Libsecp256k1 0.6.0では、「MuSig2モジュールと スタックからシークレットをクリアするための非常に堅牢なメソッドが追加され、 未使用の
secp256k1_scratch_space
関数が削除されました。」 -
● BDK 0.30.0では、ライブラリのバージョン1.0へのアップグレードの準備をしました。
-
● Eclair v0.11.0では、「BOLT12オファーを公式サポートし、 流動性管理機能(スプライシング、Liquidity Ads、オンザフライ・ファンディング)を進展させました」。 このリリースではまた、非アンカーチャネルの新しい受付を停止しました。
-
● Core Lightning 24.11では、高度なルート選択を使用した支払いを行うための新しい実験的なプラグインが含まれ、 オファーへの支払いおよび受け取りがデフォルトで有効になり、 スプライシングに複数の改良が加えられました。
11月
- ● SuperScalarタイムアウトツリー型チャネルファクトリー: ZmnSCPxjが、タイムアウトツリーを使用する チャネルファクトリーのSuperScalar設計を提案しました。 これは、トラストレス性を維持しながら、LNユーザーがチャネルを開いて流動性にもっと安価にアクセスできるようにするものです。 この設計では、サービスプロバイダーがツリーをオンチェーンに配置するコストを支払うか、 ツリーに残っている資金を失うことになる階層化されたタイムアウトツリーを使用します。 これにより、サービスプロバイダーは、オンチェーンへの移行を回避するために、 ユーザーが協力してチャネルを閉じるよう奨励します。この設計では、 Duplexマイクロペイメントチャネルと LN-Penaltyペイメントチャネルの両方を使用しています。 どちらもコンセンサスの変更なく実行できます。 複数のチャネルタイプを組み合わせてオフチェーンのステートを管理するという複雑さにもかかわらず、 この設計は大規模なプロトコル変更を必要とせずに単一のベンダーによって実装できます。 この設計をサポートするために、ZmnSCPxjは後に、LN仕様に プラグイン可能なチャネルファクトリーの調整を提案しました。
- ● 高速かつ安価なオフチェーン支払いの解決: John Lawが、参加者双方が資金を債権に拠出することを要求する オフチェーン支払いの解決(OPR)マイクロペイメントプロトコルを提案しました。 この債権は、どちらの参加者によっても いつでも事実上破壊することができます。 これにより両者に、相手をなだめるか、 債権の相互確証破壊(MAD)のリスクを負うかのインセンティブが生まれます。 このプロトコルはトラストレスではありませんが、他の方法よりもスケーラブルで、 迅速な解決が可能であり、タイムロックの期限が切れる前にデータをオンチェーンで公開することを参加者に強いることもありません。 これにより、チャネルファクトリーやタイムアウトツリー、または理想的にはネストされた部分をオフチェーンに保持する他のネスト構造内で OPRをより効率的にすることができます。
2024年のまとめ: Bitcoin Optech
Optechの7年めは、51の週刊ニュースレターを発行し、 トピックインデックスに35の新しいページを追加しました。 合わせて、Optechは今年Bitcoinソフトウェアの研究開発に関する120,000以上のワードを公開し、 これはおそよ350ページの本に相当します。
各ニュースレターやブログ記事は、中国語、チェコ語、フランス語、日本語に翻訳され、 2024年には合計200以上の翻訳が行われました。
さらに、今年のすべてのニュースレターにはポッドキャストのエピソードが添えられ、 音声形式では合計59時間以上、トランスクリプト形式では、 488,000語以上になりました。 Bitcoinのトップコントリビューターの多くが番組のゲストとして出演し、 複数のエピソードに出演した人もいました。2024年は、合計75人のゲストが出演しました:
- Abubakar Sadiq Ismail (x2)
- Adam Gibson
- Alex Bosworth
- Andrew Toth (x3)
- Andy Schroder
- Anthony Towns (x5)
- Antoine Poinsot (x5)
- Antoine Riard (x2)
- Armin Sabouri
- Bastien Teinturier (x4)
- Bob McElrath
- Brandon Black (x3)
- Bruno Garcia
- callebtc
- Calvin Kim
- Chris Stewart (x3)
- Christian Decker
- Dave Harding (x3)
- David Gumberg
- /dev/fd0
- Dusty Daemon
- Elle Mouton (x2)
- Eric Voskuil
- Ethan Heilman (x2)
- Eugene Siegel
- Fabian Jahr (x5)
- Filippo Merli
- Gloria Zhao (x10)
- Gregory Sanders (x7)
- Hennadii Stepanov
- Hunter Beast
- Jameson Lopp (x2)
- Jason Hughes
- Jay Beddict
- Jeffrey Czyz
- Johan Torås Halseth
- Jonas Nick (x2)
- Joost Jager
- Josie Baker
- Kulpreet Singh
- Lorenzo Bonazzi
- Luke Dashjr
- Matt Corallo (x3)
- Moonsettler (x2)
- Nicholas Gregory
- Niklas Gögge (x2)
- Oghenovo Usiwoma
- Olaoluwa Osuntokun
- Oliver Gugger
- Peter Todd
- Pierre Corbin
- Pierre Rochard
- Pieter Wuille
- René Pickhardt (x2)
- Richard Myers
- Rijndael
- rkrux
- Russell O’Connor
- Salvatore Ingala (x2)
- Sebastian Falbesoner
- SeedHammer Team
- Sergi Delgado
- Setor Blagogee
- Shehzan Maredia
- Sivaram Dhakshinamoorthy
- Stéphan Vuylsteke
- Steven Roose
- Tadge Dryja
- TheCharlatan
- Tom Trevethan
- Tony Klausing
- Valentine Wallace
- Virtu
- Vojtěch Strnad (x2)
- ZmnSCPxj (x3)
Optechは、Human Rights Foundationから私たちの活動に対して$20,000 USDの寄付を受ける幸運に恵まれ、 感謝しています。この資金は、ウェブホスティング、メールサービス、ポッドキャストの書き起こしおよび、 Bitcoinコミュニティへの技術コンテンツの配信を継続・改善するためのその他の費用に使用されます。
12月
12月には、いくつかの議論が継続し、複数の脆弱性が発表されましたが、これらはすべてこのニュースレター内にまとめています。
Bitcoin開発の素晴らしい1年を支えてくださった、上記すべてのBitcoinコントリビューターおよび 同様に重要な仕事をしてくださった多くの方々に感謝します。Optechのニュースレターは、 1月3日より通常の金曜日の発行スケジュールに戻ります。