Christian Decker

Decker の仕事を探すと、cdecker というアカウントや Snyke という名前に出会います。2026年10月の確認時には、公開プロフィールに Blockstream も記載されていました。これは作者とコードや提案を結び付ける手掛かりですが、短い紹介文だけで現在の職位までは断定できません。開かれたネットワークでは、何を解決し、検証に耐えられるかが提案の価値を決めます。名前や勤務先は、全員のルールを変更する権限を与えません。 [1]

新しいブロックは、あるコンピューターから別のコンピューターへと段階的に伝わり、その通信には時間がかかります。Christian Decker と Roger Wattenhofer は2013年の研究でこれを測定しました。取引やブロックの伝播と、ネットワークの各部分が異なる新しいブロックに基づいて動く一時的な分岐との関係を調べたのです。こうした過去の測定は実際の動作を説明しますが、現在の速度を示すものではありません。ソフトウェアも通信方法も、その後変化しています。 [2]

支払いチャネルでは、共同で拘束した資金を誰がどれだけ持つかを、参加者が繰り返し合意します。相手が自分に有利な古い合意でチャネルを閉じようとしたらどうなるでしょう。Decker、Rusty Russell、Olaoluwa Osuntokun による eltoo は、最終決済前に新しい状態を優先させる提案です。古い精算書を最新の合意に置き換えるような仕組みと考えられます。現在のすべての Lightning チャネルに自動的に備わる機能ではありません。 [3]

訂正できるだけでは十分ではありません。eltoo では、古い状態の決済が可能になる前に、訂正する取引を承認させる必要があります。OP_CSV は、対象の出力が承認されてから所定の待機期間が過ぎるまで、特定の支出を認めないことで対応時間を確保します。そのため利用者か委託先のサービスがチェーンを監視しなければなりません。古い状態への対処方法は変わっても、無期限のオフライン状態が安全になるわけではありません。 [3]

新しい合意をさまざまな過去の状態に適用するには、対応する署名ルールが必要です。Decker と Anthony Towns による BIP 118 は SIGHASH_ANYPREVOUT を提案しています。2026年10月の確認時点で文書の状態は Draft、つまり草案でした。ノードが Bitcoin を検証するルールを soft fork で変更する内容です。公開されたことや開発者の支持は、有効化の証拠にはなりません。提案、実装、ネットワークでの採用はそれぞれ異なる段階です。 [4]

通常、署名は支出対象となる特定の過去の取引出力にも結び付きます。出力とは、金額と支出条件をまとめたものです。BIP 118 は選択した方式でこの結び付きを緩め、署名済み取引を別の互換性のある出力につなげられるようにします。古いチャネル状態の置き換えに役立ちますが、他人の資金を自由に使えるわけではありません。署名を再利用できる範囲が広がるため、慎重な設計が必要です。方式によっては金額や支出条件との結び付きも重要です。 [4]

Lightning ノードには継続的な運用作業が必要です。Blockstream は2023年10月12日に Greenlight の一般提供を発表し、Decker をプロジェクト責任者と紹介しました。利用者が秘密鍵を保ち、事業者がノードの設備を運用する分担です。秘密鍵は支出を承認するためのものなので、保有することとサーバーを運用することは異なります。この方式だけで無停止のサービスや不変の取引条件が保証されるわけではありません。それらは別に評価する必要があります。 [5]

Core Lightning は Lightning ノードを動かすソフトウェアです。プラグインという拡張機能で運用者の用途に合わせられ、reckless が導入と有効化を支援します。これは Bitcoin の新しい署名ルールを提案することとは別の変更です。拡張機能を入れるだけでは、ネットワーク全体のルールに BIP 118 は追加されません。Decker の仕事は研究、プロトコルの提案、実用ツールを結びますが、それぞれ実際の利用までの道筋は異なります。 [6]