130 / 736CSV

CSV

特定のコインの承認から待つ仕組み

固定の日付までではなく、コインがチェーン上で一定の時間を経るまで待ちたい場合があります。CSV はその待機を強制する助けになります。起点はウォレットの作成時でも、支払いへの署名時でもありません。

CSV は Bitcoin Script の OP_CHECKSEQUENCEVERIFY の略称です。BIP 68 と組み合わせると相対ロックを実現でき、承認された出力が十分に古くなって初めて特定の支出経路を使えます。出力は受け取った金額と支出条件です。待つだけで署名が不要になったり、送金されたりはしません。

アンナとペーターは共同で保管するコインを合意によって使えます。加えて、関連する出力の承認から一定時間待てば、アンナだけでも使える復旧経路を用意したいと考えています。CSV はこの条件を強制する助けになります。固定の高さや時刻を指定する CLTV と異なり、その境界は履歴全体の中で先に決めた一点ではありません。対象のコインによって変わります。ウォレット作成、署名準備、未承認取引の長い待ち時間は、この起点の代わりにはなりません。ウォレットは、ビットコインを受け取ったり送ったりするためのアプリや機器です。 [1] [2] [8]

ブロックは、共有する履歴に追加する取引のまとまりです。ブロック高は、チェーン内でのブロックの位置を表します。出力が高さ 900000 で承認され、必要な遅延が 10 ブロックだとします。このロック条件で最も早く使えるのはブロック 900010 です。間隔が 9 ブロックだけでは足りません。ブロックは一定の間隔で届かないため、正確に何分かかるかを保証するものではありません。十分に古くなったことは、支払いの承認でもありません。取引はほかの点でも有効である必要があり、採掘者が実際にブロックへ取り込まなければなりません。 [2] [4] [9]

遅延は 512 秒単位でも符号化できます。コード 2 は 1024 秒を意味します。ただし二台のパソコンの時計を比較するのではありません。起点は出力を承認したブロックの一つ前の Median Time Past、もう一方は候補ブロックの一つ前の Median Time Past です。これは直近の最大 11 ブロックのタイムスタンプを並べた中央の値です。二つの中央値の差が必要な遅延に達しなければなりません。現地時間に正確に鳴るアラームではないのです。 [2] [4] [7]

ウォレットは支払いのために、過去に受け取った複数の金額をまとめることがあります。取引の各入力は、以前受け取った出力を参照します。その出力の経過期間はチェーン上での承認から数え、nSequence フィールドは入力自体に含まれます。このフィールドに相対的な待機の情報が入ります。一部のお金だけが十分に古くても足りません。取引に適用されるすべてのロックを満たす必要があります。チェーンの再編成で承認の位置が変わることもあります。そのため、以前使える状態だったことは、コインの不可逆な性質ではありません。再編成とは、ネットワークが別の有効な分岐を採用し、それまでのブロック履歴の一部を置き換えることです。 [2] [4] [9]

Full Node は関連する検査によって規則を独立に確かめます。BIP 112 の CSV は、スクリプト引数をその出力を使う入力の nSequence と比較します。年齢そのものは計算せず、取引検証時の BIP 68 が担当します。無効化フラグのない通常の引数では、取引バージョンが少なくとも 2 で、nSequence のビット 31 が未設定である必要があります。ビットは数値フィールド内の小さなスイッチです。負の引数、古いバージョン、不適合な nSequence では検査に失敗します。 [1] [2] [3]

ビット 22 が遅延の読み方を決めます。未設定なら単位はブロック、設定されていれば 512 秒単位です。スクリプト引数と nSequence は同じ種類を使わなければなりません。測定値の比較と同じで、片方がキロメートル、もう片方が時間なら、数字が大きいだけでは比較できません。ここで区別するのはブロック数と時間間隔です。 [1] [2] [3]

遅延の長さは下位 16 ビットに入ります。マスク 0x0000ffff は数値フィールドからその部分を取り出すものです。CSV はこの部分と遅延の種類を比較し、大きな nSequence を何でも長い待ち時間と解釈するわけではありません。対象のビットを取り出した後、スクリプトの要求は入力の値以下でなければなりません。ウォレット設計者にとって重要な技術条件ですが、利用者が全体の手順を理解せず手動設定するものではありません。 [1] [2] [3]

遅延ゼロは待ち時間を追加しませんが、通常の CSV のほかの検査は残ります。一方、非負のスクリプト引数自体でビット 31 が設定されていると、CSV は相対ロックに作用しない NOP として振る舞います。その引数では待機を強制できません。入力の nSequence にある同じフラグとは区別が必要です。通常の引数では、入力側のそのフラグは未設定でなければなりません。 [1] [3]

アンナの復旧経路に署名が必要なら、待ち時間の後も署名を提供しなければなりません。秘密鍵は、そのような署名を作るために使う秘密の数値です。失った秘密鍵は戻らず、別の分岐では早い支出が可能な場合もあります。スクリプト実行中、CSV は引数をデータの作業用の積み重ねであるスタックに残します。そのため、取り除くための OP_DROP がよく続きます。ただしデータを除くだけでは、誰にもお金を使う権限は与えられません。選んだ経路の署名やその他の条件で決まります。 [1] [3] [5]

BIP 112 は OP_NOP3 を CSV に置き換え、BIP 68、BIP 113 とともに導入しました。単なる計画ではなく、すでに使える機能です。例えば Lightning Network の支払いチャネルで、相手が対応するための時間を設ける用途があります。ただし、その対応自体を手配するわけではありません。待機後も取引の配信と承認が必要です。手数料、利用できるデータ、チェーンの状態も影響します。検証の詳細は Bitcoin Core v29.0 と掲載した仕様で確認できます。 [1] [2] [6]

理解を深めるには、この項目とあわせて次もお読みください CLTV, Opcode, Timelock, Bitcoin Script, Bitcoin, Full Node. 次の項目からも参照されています 承認, Timelock, HTLC, Opcode.

DOC · 001BIP 112 — OP_CHECKSEQUENCEVERIFY仕様 DOC · 002BIP 68 — Relative lock-time仕様 DOC · 003Bitcoin Core v29.0 — Script interpreter文書 DOC · 004Bitcoin Core v29.0 — Transaction sequence locks文書 DOC · 005Bitcoin Developer Reference — Transactions文書 DOC · 006Bitcoin Core 0.12.1 — BIP 68/112/113 release notes文書 DOC · 007BIP 113 — Median time-past lock-time calculations仕様 DOC · 008BIP 65 — OP_CHECKLOCKTIMEVERIFY仕様 DOC · 009Bitcoin Developer Guide — Block Chain文書
改訂日: 一次資料を優先 · 投資助言ではありません