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

内容

1月

LDKは1月にステートレスインボイスの実装をマージし、 支払いが成功しない限りインボイスに関するデータを一切保存することなく無限にインボイスを生成できるようにしました。 ステートレスインボイス自体は2021年9月に提案され、LDKの実装は提案された方法とは異なりますが、 同じ目標を達成し、LNプロトコルの変更も必要ありません。同じ月末に、LNの仕様の更新が マージされ、他の種類のステートレスインボイスのサポートが可能になり、 少なくとも一部のサポートがEclair、Core Lightning、 LNDに追加されました。

また1月に、Jack DorseyとAlex Morcos、Martin Whiteによって Bitcoin Legal Defense Fundが発表されました。 これは、「ソフトウェア開発者がBitcoinや関連プロジェクトを積極的に開発することを妨げる 法的問題を最小限に抑えることを目的とした非営利団体」です。

2月

1月に行われた事前署名されたトランザクションに手数料を追加しやすくすることについての議論から、 2月には、Jeremy Rubinの2020年のトランザクション手数料のスポンサーシップ構想が 再び議論されるようになりました。その実装にはいくつかの課題が挙げられました。 当面の議論はあまり進展しませんでしたが、同様の目標を達成しつつ、 スポンサーシップと違ってソフトフォークを必要としない手法が10月に提案されることになります。

LDKがステートレスインボイスを早期にサポートしたことで、 ファントムノードペイメントと呼ばれる LNノードの負荷分散を図るための新しくシンプルな方法を追加することができました。

ファントムノードペイメントの図

3月

René PickhardtとStefan Richterが2021年に最初に発表したLNの経路探索アルゴリズムが 3月に更新され、Pickhardtは、計算効率を大幅に向上させた改善について言及しています。

ゼロ承認チャネルを可能にする一貫した方法が定義され、 実装のサポートが見られるようになりました。3月に、 LDKの関連するSCID（Short Channel IDentifier）エイリアスフィールドのサポートから始まり、 Eclair、Core Lightning、LNDが続きました。

ゼロ承認チャネルの図

2022年のまとめ
Replace-By-Fee

今年は、RBF（Replace By Fee）に関して多くの議論といくつかの重要なアクションがありました。 1月のニュースレターでは、Jeremy Rubinによる、元のトランザクションがノードで最初に確認されてからしばらくの間は、 どのトランザクションであってもより高い手数料の代替トランザクションに置き換えることができ、 その期間が経過すると、既存のルールが適用されBIP125をオプトインしたトランザクションのみ置換可能になるという提案を掲載しました。 これにより、マーチャントは置換可能な時間が経過した後も、今と同じように未承認トランザクションを受け入れることができるようになる可能性があります。 さらに重要なことは、セキュリティのために置換可能性に依存しているプロトコルは、 プロトコルのノードやウォッチタワーがトランザクションを最初に確認した後すぐに対応する妥当な機会がある限り、 非オプトインのトランザクションについて心配する必要がないことです。

1月末に、Gloria Zhaoは現在のRBFポリシーの背景や、長年にわたって発見されたいくつかの問題 （Pinning攻撃など）、 ポリシーがウォレットのユーザーインターフェースに与える影響の検証および、 いくつかの可能な改善についての説明を投稿し、RBFに関する新しい議論を始めました。 3月初旬に、Zhaoは多くの開発者が行ったRBFに関する2つの議論（1つは対面での議論、 もう1つはオンラインでの議論）の要約をフォローアップしました。

3月にはまた、Larry RuaneがRBFに関連して、トランザクションのtxidの一部となる部分を変更することなく、 トランザクションのwitnessを置き換えることについて質問を投げかけました。

6月、Antoine RiardはBitcoin Coreにmempoolfullrbf設定オプションを追加するプルリクエストを公開しました。 このオプションは、BIP125のシグナルを含む場合のみ未承認トランザクションの置換を許可するという Bitcoin Coreのこれまでの動作がデフォルトに設定されています。 このオプションが別の値に設定されたノードは、置換するトランザクションがBIP125のオプトインシグナルを含まない場合でも、 リレーやマイニングのために置換トランザクションを受け入れるようになります。 Riardはまた、Bitcoin-Devメーリングリストにスレッドを立ち上げ、 この変更について議論を始めました。プルリクエストのほぼすべてのコメントは、 肯定的なもので、メーリングリストでの議論のほとんどは関係のない話題だったため、 プルリクエストが公開されてから約1ヶ月でマージされたのは当然のことでした。

10月、Bitcoin Coreプロジェクトは、mempoolfullrbf設定オプションを最初に含むことになる バージョン24.0のリリース候補の配布を開始しました。 Dario Sneidermanisは、このオプションに関するリリースノートのドラフトを見て、 多くのユーザーやマイナーがこのオプションを有効にしたら、シグナルの無い置換が信頼できるものになるだろうと Bitcoin-Devメーリングリストに投稿しました。 シグナルの無い置換の信頼性が高くなると、 未承認トランザクションを最終的なものとして受け入れるサービスからの盗難の信頼性も高めることになり、 これらのサービスは動作を変更する必要がでてきます。 議論は、翌週も翌々週も続きました。 Sneidermanisがメーリングリストで最初の懸念を提起してから1ヶ月後、 Suhas Daftuarがこのオプションに対するいくつかの議論をまとめ、 Bitcoin Coreからこのオプションを削除するプルリクエストを公開しました。 他の同様のプルリクエストがそれより前や後に公開されましたが、 Daftuarのプルリクエストはオプションを永久に削除する可能性についての議論の焦点になりました。

Daftuarのプルリクエストでは、mempoolfullrbfオプションを維持することに賛成する多くの反論が行われました。 その中には、何人かのウォレット開発者が、BIP125をオプトインしていないにもかかわらず 置換を希望するユーザーに遭遇することがあると指摘したものも含まれています。

11月末までに、DaftuarはPRを閉じ、Bitcoin Coreプロジェクトはmempoolfullrbfオプション付きの バージョン24.0をリリースしました。12月、開発者の0xB10Cは、 BIP125シグナルを含まないトランザクションの置換を監視するウェブサイトを公開しました。 これは、承認されたトランザクションのいずれかが、 mempoolfullrbfオプション（もしくは他のソフトウェアの同様の機能）を使用して フルRBFを有効にするマイナーによって処理された可能性があることを示しています。 この年末、フルRBFは、他のBitcoin CoreのPRやメーリングリストでまだ議論されています。

4月

4月、Ruben Somsenがサイレントペイメントのアイディアを提案しました。 これは、オンチェーンで識別されることのない公開識別子（アドレス）への支払いを可能にし、 アドレスの再利用を防止するのに役立つでしょう。 たとえば、アリスは自身のウェブサイトに公開識別子を掲載し、 ボブはそれを新しい一意なBitcoinアドレスに変換します。このアドレスのコインを使用できるのはアリスだけです。 後でキャロルがアリスのウェブサイトにアクセスし、アリスの公開識別子を再利用した場合、 キャロルはアリスへの支払いのために異なるアドレスを導出するでしょう。 このアドレスについて、ボブも他の第三者も、それがアリスのアドレスだと直接判断することはできません。 その後、開発者のW0ltxは、Bitcoin Core用のサイレントペイメントの実装案を作成し、 年内に大幅なアップデートを行いました。

Lightning Labsは、ユーザーがBitcoinのブロックチェーン上でビットコインではないトークンの作成と転送に コミットできるようにするための（以前の提案に基づいた）プロトコル案、Taroを発表しました。 Taroは、ルーティング可能なオフチェーン転送のためにLNと一緒に使用されることを意図しています。 LN上のクロスアセット転送に関するこれまでの提案と同様に、支払いを転送するだけの中間ノードは、 Taroのプロトコルや転送されるアセットの詳細を認識する必要はありません。中間ノードは、 他のLN支払いと同じプロトコルを使用してビットコインを転送するだけです。

4月にはまた、量子安全な鍵交換についても議論され、 将来実現する可能性のある高速な量子コンピューターの攻撃にも耐えられる鍵で 保護されたビットコインの受け取りを可能にします。

5月

Schnorrのマルチシグを作成するためのMuSig2プロトコルは、 2022年にいくつかの進展が見られました。提案されたBIPは、 5月に重要なフィードバックを受けました。 その後10月に、Yannick SeurinとTim Ruffing、Elliott JinおよびJonas Nickが、 プロトコルのいくつかの使用方法に脆弱性を発見し、 研究者は更新版で修正する予定であると発表しました。

5月にGloria ZhaoがパッケージリレーのBIPドラフトを投稿しました。 パッケージリレーは、親トランザクションがノードの動的最小mempool手数料を支払っている場合にのみ、 個々のノードが手数料の引き上げを行う子トランザクションを受け入れるという、 Bitcoin CoreのCPFPによる手数料の引き上げの重大な問題を修正するものです。 この問題のため、多くのコントラクトプロトコル（現在のLNプロトコルを含む）など、 事前署名されたトランザクションに依存するプロトコルでは、CPFPの信頼性が不十分となります。 パッケージリレーは、親トランザクションと子トランザクションを1つの単位として評価可能にすることで、 この問題を解消します。ただし、トランザクションのPinningなど、 関連する他の問題は解消されません。6月に、パッケージリレーに関する追加の議論が行われました。

5月はまた、Bitcoin Kernel Library Project (libbitcoinkernel)の最初のマージも行われました。 これは、Bitcoin Coreのコンセンサスコードを可能な限り別のライブラリに分離する試みで、 現在のコードにはまだ非コンセンサスコードが付属しています。 長期的な目標は、コンセンサスコードのみを含むようlibbitcoinkernelを削減することで、 他のプロジェクトがそのコードを使用したり、 監査人がBitcoin Coreのコンセンサスロジックの変更の分析を容易にできるようにすることです。 いくつかの追加のPRが今年中にマージされるでしょう。

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

6月

6月、LN開発者はプロトコル開発の将来について議論するために集まりました。 議論されたトピックには、TaprootベースのLNチャネル、 TapscriptとMuSig2 (再帰的なMuSig2を含む)、 新しいチャネルと変更されたチャネルを公表するためのゴシッププロトコルの更新、 オニオンメッセージ、ブラインドパス、 プロービング、バランスの共有、トランポリンルーティング、 Offer、LNURLプロトコルが含まれていました。

7月

7月、Bastien Teinturierは、 DoS攻撃を防ぐためのオニオンメッセージのレート制限について、 Rusty Russellによるものだとするアイディアの概要を投稿しました。 しかし、Olaoluwa Osuntokunは、データのリレーに課金することでオニオンメッセージの悪用を防ぐという 3月の彼の提案について再考を提案しました。 議論に参加したほとんどの開発者は、プロトコルに追加の手数料を加える前にレート制限を試してみることを好んだようでした。

この月、Bitcoin Coreに、Miniscriptで書かれた 監視専用のアウトプット・スクリプト・ディスクリプターのサポートを追加する プルリクエストがマージされました。将来のPRでは、ウォレットが Miniscriptベースのディスクリプターを支払いで使用するための署名を作成できるようにする予定です。 他のウォレットや署名デバイスがMiniscriptをサポートすると、 マルチシグポリシーや異なる場面で異なる署名者が含まれるポリシー（例：フォールバック用の署名者）など、 ウォレット間でポリシーを転送したり、複数のウォレットが協力してビットコインを使用することが簡単になるはずです。

8月

8月、Eclairは2つノードのどちら（または両方）が新しいLNチャネルに資金を提供することができる デュアルファンディングプロトコルと依存関係のある 対話型のファンディングプロトコルのサポートをマージしました。 月末には、別のマージによってEclairがデュアルファンディングを実験的にサポートするようになりました。 デュアルファンディングのチャネルオープンプロトコルは、 マーチャントが顧客からの支払いをすぐに受け取れるチャネルへのアクセスを確保するのに役立ちます。

Antoine RiardとGleb Naumenkoは、チャネルジャミング攻撃と いくつかの解決策の提案についてのガイドを公開しました。 攻撃者が制御するチャネル毎に完了しない支払いを送信することで、多数の他のチャネルを使用不能にすることができます。 つまり、攻撃者は直接コストを払う必要がありません。この問題は2015年から知られていましたが、 以前提案された解決策は広く受け入れられませんでした。11月には、 Clara ShikhelmanとSergei Tikhomirovは、少額の前払い手数料と 自動化されたレピュテーションベースの紹介に基づく分析と解決策を提案した論文を公開しました。 その後、Riardが、取引不可能なノード固有のトークンを含む代わりの解決策を発表しました。 12月には、Joost Jagerが、LNプロトコルに変更を加えることなく、 ノードがジャミングの問題を軽減するのに役立つ「単純だが不完全な」ユーティリティを発表しました。

2種類のチャネルジャミング攻撃の図

Lloyd Fournierは、DLCのオラクルがBLS（Boneh-Lynn-Shacham）署名を使用して、 証明を作成することの利点について投稿しました。 BitcoinはBLS署名をサポートしておらず、追加するためにはソフトフォークが必要ですが、 Fournierは、BLS署名から情報を安全に抽出し、 Bitcoinに変更を加えることなくBitcoin互換の署名アダプターを使用する方法について説明している 共著の論文へのリンクを掲載しました。これにより、契約の参加者（オラクルではない）は、 オラクルが実行できるプログラミング言語で書かれたプログラムを指定するなどして、 オラクルに証明してほしい情報について非公開で合意することができるステートレスオラクルを実現することができます。 そして参加者は、オラクルに対してオラクルを利用する予定であることを伝えることなく、 契約にしたがってデポジットする資金を割り当てることができます。 契約の清算タイミングが来たら、各参加者が自分でプログラムを実行し、 その結果に参加者全員が合意すれば、オラクルを一切介さずに協力的に契約を清算することができます。 合意しなかった場合は、参加者の誰かがオラクルにプログラムを送信し（おそらくそのサービスに対して少額の支払いが発生する）、 プログラムのソースコードとそれを実行した結果に対するBLSの証明を返送してもらいます。 証明は署名に変換され、DLCをオンチェーンで清算することができます。現在のDLCコントラクトと同様に、 オラクルはどのオンチェーントランザクションがそのBLS署名に基づくものなのか知りません。

2022年のまとめ
Bitcoin Optech

Optechの5年めは、51の週間ニュースレターを発行し、 トピック・インデックスに11の新しいページを追加しました。 またOptechは今年、Bitcoinのソフトウェアの研究開発について、 全体で7万文字以上を公開しました。ざっと200ページの書籍に相当します。

9月

Lisa Neigutは、ノードが4段階の転送手数料を配信できるようにする手数料レートカードの提案を Lightning-Devメーリングリストに投稿しました。 転送手数料の配信を改善し、場合によっては負の手数料を設定できるようにすれば、 転送ノードが最終的な宛先に向けて支払いを中継するのに十分なキャパシティを確保できるようになります。 開発者のZmnSCPxjは、今年の初めにルーティングを改善するための独自の手数料ベースの解決策を投稿しており、 レートカードを使用するための簡単な方法を説明しています。 「レートカードは、同じ２つのノード間で、それぞれ異なるコストを持つ4つの別々のチャネルとしてモデル化することができます。 最も低コストの経路が失敗すると、ホップ数は増えるが実効コストの低い別の経路を試すか、より高いコストで同じチャネルを試すだけです。」 René Pickhardtからは、支払いのフロー制御のための別の方法が提案されました。

10月

10月、Gloria Zhaoはバージョン番号3を使用するトランザクションに、 変更したトランザクションリレーポリシーのセットを使用できるようにすることを提案しました。 これらのポリシーは、CPFPとRBFの使用経験を基に、 さらにパッケージリレーに関するアイディアを加えたもので、 LNのような2者間のコントラクトプロトコルに対するPinning攻撃を防ぐのに役立つよう設計されています。 チャネルの閉鎖や支払いの決済（HTLC）、不正行為に対するペナルティの適用のために、 ユーザーがトランザクションの迅速な承認を得られるようにします。 Greg Sandersは、月の後半に、ほとんどのLN実装で既に使用可能なアンカー・アウトプットを簡略化した エフェメラル・アンカーに関する追加の提案を行いました。

Eclairは、トランポリン・リレーが使用されている際に、 非同期支払いの基本形をサポートするようにしました。 非同期支払いは、資金を第三者に託すことなく、オフラインのノード（モバイルウォレットなど）への支払いを可能にします。 非同期支払いの理想的な仕組みはPTLCに依存しますが、 部分的な実装では、オフラインのノードがオンラインに戻るまでサードパーティが転送を遅らせるだけですみます。 トランポリンノードは、この遅延を提供できるため、今回のPRでトランポリンノードを利用して非同期支払いを実験することができます。

10月はまた、複数のアプリケーションに影響を与えた2つのブロックのパースバグのうちの１つが発生しました。 BTCDで誤って発生したバグによって、BTCDと下流プログラムであるLNDが最新のブロックを処理できなくなりました。 このバグによりユーザーが資金を失う可能性がありましたが、そのような問題は報告されていません。 2つめの関連バグの方は意図的に引き起こされ、 再びBTCDとLNDおよびRust-Bitcoinの一部のバージョンのユーザーに影響を与えました。 ここでもユーザーが資金を失う可能性がありましたが、報告された事件はありませんでした。

John Lightは、現在のサイドチェーンの状態をメインチェーンにコンパクトに格納するサイドチェーンの一種である Validity Rollupについて作成した研究レポートを投稿しました。 サイドチェーン上のビットコインの所有者は、メインチェーンに格納されている状態を使用して、 自分が管理しているサイドチェーン上のビットコインの量を証明することができます。 Validity Proofを持つメインチェーンのトランザクションを送信することで、 サードチェーンの運営者やマイナーが引き出しを阻止しようとしても、 自分が所有するビットコインをサードチェーンから引き出すことができます。 Lightの研究は、Validity Rollupを深く説明し、そのサポートをどうやってBitcoinに追加できるかを説明し、 その実装に関するさまざまな懸念事項を検証しています。

暗号化されたv2 P2PトランスポートプロトコルのBIP324の提案は、 3年ぶりに更新されメーリングリストで議論が行われました。 未承認トランザクションの転送を暗号化することは、多くのインターネットの中継を制御する盗聴者（たとえば大規模なISPや政府）から、 その出所を隠すのに役立ちます。また、改ざんを検知しやすくなり、エクリプス攻撃をより困難にする可能性もあります。

Bitcoinプロトコル開発者のミーティングでは、 トランスポートの暗号化、 トランザクション手数料と経済的なセキュリティ、 FROST閾値署名方式、 ソースコードと開発の議論のホスティングにGitHubを使用することの持続可能性、BIPの証明可能な仕様、 パッケージリレーとv3トランザクションリレー、 Stratumバージョン2マイニングプロトコル、 コードをBitcoin Coreや他のフリーソフトウェアプロジェクトにマージしてもらうことを含む、 Bryan Bishopによって書き起こされたいくつかのセッションがありました。

2022年のまとめ
ソフトフォークの提案

1月、Jeremy RubinがOP_CHECKTEMPLATEVERIFY (CTV)のソフトフォークの提案を 検討・議論するIRCミーティングの第一回めを開催することから始まりました。 一方、Peter Toddは、この提案に対するいくつかの懸念をBitcoin-Devメーリングリストに投稿し、 特に、以前のソフトフォークがそうであったように、ほぼすべてのBitcoinユーザーに利益をもたらすとは思えないという懸念を表明しました。

Lloyd Fournierは、DLC-DevメーリングリストとBitcoin-Devメーリングリストの両方に、 CTV opcodeが特定のDLC（Discreet Log Contract）の作成に必要な署名の数を根本的に削減し、 また他のいくつかの操作の数も削減できると投稿しました。 Jonas Nickは、提案中のSIGHASH_ANYPREVOUT (APO)署名ハッシュモードを使用しても 同様の最適化が可能であることを指摘しました。

Russell O’Connorは、CTVとAPOの両方に代わる方法として、 OP_TXHASH opcodeとOP_CHECKSIGFROMSTACK (CSFS) opcodeを 追加するソフトフォークを提案しました。 TXHASH opcodeは、支払いトランザクションのどの部分をシリアライズしてハッシュすべきかを指定し、 ハッシュダイジェストは後のopcodeが使用できるように評価スタックに置かれます。 CSFS opcodeは公開鍵を指定し、 それに対応するスタック上の特定のデータ（TXHASHによって作成されたトランザクションの計算ダイジェストなど）に対する署名を要求します。 これにより、CTVとAPOのエミュレーションを、より単純でより柔軟性があり、 その後のソフトフォークによる拡張が容易な方法で行うことができるようになります。

2月には、Rusty RussellがOP_TXHASHのよりシンプルなバージョンであるOP_TXを提案しました。 一方、Jeremy RubinはCTVを有効にしたsignet用のパラメーターとコードを公開しました。 これにより、提案されたopcodeの公開実験が簡単になり、そのコードを使用する異なるソフトウェア間の互換性のテストがより簡単になりました。 2月にはまた、開発者のZmnSCPxjが、2021年に提案されたOP_TAPLEAF_UPDATE_VERIFY (TLUV) opcodeに代わる、 新しいOP_EVICT opcodeを提案しました。TLUVと同様に、EVICTは、 Joinpoolやチャネル・ファクトリー、 特定のCovenantなど、2人以上のユーザーが1つのUTXOの所有権を共有するユースケースにフォーカスしています。 ZmnSCPxjはその後、EVICTのような動作を構築できるより一般的な構成として（ただし、それには他のスクリプト言語の変更を必要とする） OP_FOLDという別の新しいopcodeを提案しました。

3月までに、CTVと新しいopcodeの提案に関する議論は、 Bitcoinのスクリプト言語の表現力を制限する議論につながりました。 これは主に、再帰的なCovenant（これらのビットコインを使用する、もしくはこれらにマージされたビットコインを 再利用するすべてのトランザクションで永久に満たす必要のある条件）を防ぐためのものです。 懸念されたのは、検閲耐性が失われること、ドライブチェーンの実現、 不必要な計算の促進、再帰的なCovenantによってユーザーが誤ってコインを失う可能性があることなどです。

3月にはまた、Bitcoinのスクリプト言語に対する変更に関する別のアイディアも見られました。 今回は、将来のトランザクションがLispをベースにした全く別の言語をオプトインできるようにするというものです。 Anthony Townsは、アイディアを提案し、 スクリプトと以前提案された代替案であるSimplicityより優れいている可能性があると説明しました。

4月、Jeremy Rubinは、マイナーが提案されているCTV opcodeの BIP119ルールを適用するかどうかを通知できるようにするソフトウェアをリリースする計画を Bitcoin-Devメーリングリストに投稿しました。 これはCTVやAPOのような類似の提案についての議論を引き起こしました。 Rubinはその後、他のCTV支持者と共に受け取ったフィードバックを評価するため、 現時点ではCTVを有効化するためのコンパイル済みのソフトウェアをリリースしないと発表しました。

5月、Rusty Russellは彼のOP_TXの提案を更新しました。 元の提案は、再帰的なCovenantを許可していたため、このセクションで述べたような懸念がありました。 代わりに、Russellは、再帰的なCovenantを防ぐために特別に設計された、 CTVの動作を許可することに限定したOP_TXの初期バージョンを提案しました。 この新バージョンのOP_TXは、将来、段階的にアップグレードして機能を追加することで、 より強力なものになると同時に、新しい機能を独自に分析することも可能にします。 5月には、（2010年にBitcoinから削除された）OP_CAT opcodeについても議論され、 一部の開発者は、将来追加する可能性があることを示唆しています。

9月、Jeremy Rubinは、Trusted Setupの手順と提案されているAPOを組み合わせることで、 ドライブチェーンが提案するのと同様の動作を実装できることを説明しました。 Bitcoinでドライブチェーンの実装を防止することは、開発者のZmnSCPxjが今年の初めに、 フルノードのオペレーターは再帰的なCovenantを可能にするソフトフォークに反対した方がいいかもしれないと示唆した理由の1つでした。

9月にはまた、Anthony Townsがsignetでソフトフォークをテストするために 特別に設計されたBitcoinの実装を発表しています。 Bitcoin CoreをベースにしたTownsのコードは、高品質の仕様と実装を備えたソフトフォークの提案ルールを適用し、 ユーザーが提案された変更を簡単に実験できるようにします（それぞれの変更を比較したり、 どのように作用するか確認したりすること含めて）。また、Townsは、 （パッケージリレーなど）トランザクションリレーポリシーに対する大きな変更案も含める予定です。

11月、Salvatore Ingalaは、（ソフトフォークを必要とする） 新しいタイプのCovenantの提案をBitcoin-Devメーリングリストに投稿しました。 この提案では、あるオンチェーントランザクションから別のトランザクションに状態を運ぶことができる スマートコントラクトをマークルツリーを使って作成することが可能になります。 これは他の暗号通貨システムで使用されているスマートコントラクトと同様の機能を持ち、 Bitcoinの既存のUTXOベースのシステムと互換性があるものです。

11月

11月、Joost Jagerは、失敗した支払いに関するLNのエラー報告を改善するための2019年の提案を更新しました。 エラーは、ノードによる支払いの転送に失敗したチャネルの身元を報告し、 送信者がそのノードを含むチャネルを一定期間使用しないようにするものです。 EclairやCore Lightningなど、 いくつかのLN実装は、すぐにその提案を使い始めないまでも、コードを更新して提案をサポートする予定です。

12月

12月、プロトコル開発者のJohn Lawは、今年3回目の重要な提案をLightning-Devメーリングリストに投稿しました。 彼の以前の2つの提案と同様に、Bitcoinのコンセンサスコードを変更することなく、 LNのオンチェーントランザクションを設計して新しい機能を有効にする方法を提案しました。 Lawの3つの提案は、カジュアルなLNユーザーが一度に数ヶ月オフラインでいられる方法、 ウォッチタワーとの互換性を向上するために特定の支払いの執行を すべての決済資金の管理から分離する方法、 LNを使用するためのオンチェーンコストを大幅に削減できるチャネル・ファクトリーを使用するための LNチャネルの最適化などを提案しています。

私たちは、上記のすべてのBitcoinコントリビューターと、同様に重要な仕事をした多くの方々、 Bitcoin開発の驚くべき一年に感謝します。 Optechのニュースレターは、1月4日に通常の水曜日の発行スケージュールに戻ります。