bip-taprootやbip-tapscriptが定義されたが、これに関連してLightning Networkのeltooを実現するための提案も出てきてるので見てみる↓
https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout.mediawiki
eltooは、LNにおいて旧状態がブロードキャストされた際に、既存のPoon-Dryja形式のペナルティ型ではなく、チャネルの最新状態を適用するタイプのペイメントチャネルの提案。eltooの仕組みについては以前GBECで解説した動画が分かりやすいと思う↓。
このeltooを実現するためには、トランザクションの署名時にトランザクションダイジェストがインプットが参照する前のUTXOのOutPointへのコミットをしないようにするSIGHASH_NOINPUTの導入が前提として必要で、これはBIP-118として提案されている↓
techmedia-think.hatenablog.com
この未導入のSIGHASH_NOINPUTの提案を、以下のように変更した新しいフラグSIGHASH_ANYPREVOUTおよびSIGHASH_ANYPREVOUTANYSCRIPTの導入がbip-anyprevoutの提案内容。
SIGHASH_NOINPUTフラグはSegwitのversion 1以降で有効になるフラグであったが、bip-anyprevoutは、bip-schnorrおよびbip-taproot、bip-tapscriptの導入後に適用される。その際、ANYPREVOUTが適用できる公開鍵は限定され、bip-tapscriptの現時点では未定義の公開鍵タイプを導入することで適用される。この時の公開鍵タイプは0x00と0x01。NOINPUTフラグはスタック上の任意の公開鍵の署名検証に対して利用可能であるが、ANYPREVOUTはtaproot利用時にtapscripを利用した署名検証にのみ利用可能ので、tapscriptではなくtaprootの内部キーを使ったケースでは使用できず、利用シーンが限定される。NOINPUTは無条件にscriptCodeにもコミットしない形になっていたが、bip-anyprevoutの場合SIGHASH_ANYPREVOUTANYSCRIPTは同様の振る舞いをするが、SIGHASH_ANYPREVOUTは使用するscriptPubkeyとtapscriptにコミットする。ANYPREVOUT利用時にはChaperone署名を適用する＝別途ANYPREVOUT以外にインプットの参照先にコミットする署名検証がされることを保証する必要がある。つまり2-of-2のようなマルチパーティ間の署名はANYPREVOUTを使用して、それだとOutPointへの参照がコミットされないので、1-of-2のような署名をもう１つ用意してそっちでANYPREVOUTでないOutPointへコミットする署名を要求する。
所感
実際、bip-anyprevoutが導入されるか、また別の提案が出てくるかはまだ分からないけど、
- Chaperone署名あたりは署名が余分にもう１つ必要になり複雑かつサイズ増になる気がするんだけど、そこまでの保護が必要か？
- インプットの参照先をダイナミックに変更できるようになるとeltooみたいないユースケースが可能になる反面、Segwitで解消されたtxidのmalleabilityがまた発生するようになるのでよく注意してプロトコル設計する必要がある。
- まだ慣れてないかつデプロイされてない＆bip-tapscriptの仕様上の話になるけど、tapscript上に未定義の公開鍵タイプを使って拡張するの、新しいスクリプトルールを適用できるという意味で拡張の選択肢は広がるものの、結構仕組みとして複雑な構造にシフトしてるように思える。
あたりが気になるところ。
以下、bip-anyprevoutの内容。
概要
このBIPではtapscript（bip-tapscript）トランザクションのための新しい公開鍵タイプについて定義する。これらの新しいタイプの公開鍵、使用するアウトプットについてコミットしなくても良いようになる。アウトプットが互換性のあるスクリプトである場合、これによりトランザクションを異なるUTXOにバインドすることが可能になる。
動機
オフチェーンプロトコルは、オンチェーンで決済する最終状態を再調整するためBitcoinネットワークにブロードキャストされていないトランザクションを利用する。多くの場合、オンチェーン上のトランザクションに対して、別のトランザクション形式で所定の反応を返すのが望ましい。オンチェーンで確認できる可能性がある様々な異なるトランザクションに対して同じ反応が望まれることがよくあるが、アプリケーションは固有の応答トランザクションを作成する必要がある。応答トランザクションのインプットの署名は対応するトランザクションに正確にコミットしているため、そのようなトランザクションを作るためには署名用の秘密鍵を必要とする。
この提案では、署名の作成と検証に使われるトランザクションダイジェストアルゴリズムの振る舞いを、前のアウトプット（オプションでwitness script）へのコミットメントを除外することで修正する新しい公開鍵タイプを導入する。このコミットメントの削除は、署名済みのトランザクションのインプットの参照先を、同じ鍵による認可を必要とする同じコインの量を持つ別のアウトプットへ動的に再バインドすることを可能にする。
動的な再バインドは別の公開鍵タイプを使うことでオプトインされるもので、異なる公開鍵を使ったり、署名内で使用するスクリプトにコミットすること、UTXO間で異なる金額を使用すること、使用するトランザクション内で異なるnSequenceの値を使用すること、codeseparator opcodeを使ってスクリプトの位置にコミットすることなどで、さらに制限される。
仕様
このBIPは、先頭バイトが0x00、0x01である公開鍵のbip-tapscriptの署名opcode（CHECKSIG、CHECKSIGVERIFYおよびCHECKSIGADD）の動作を変更する。これらの鍵はbip-anyprevout keyと呼ばれる。
署名opcodeのルール
署名opcodeのbip-tapscriptのルールを次のように変更する。未知の公開鍵タイプのリストから先頭バイト0x00、0x01の鍵を削除し、未知の公開鍵タイプを処理する前に以下のルールを追加する。
- 公開鍵の先頭バイトが
0x00もしくは0x01の場合それはbip-anyprevout公開鍵とみなされる。
公開鍵
bip-schnorrの公開鍵は0x02もしくは0x03で始まる33バイト列として定義されているため、（0x00もしくは0x01で始まる）bip-anyprevoutの公開鍵は署名検証に使う前に変換する必要がある。変換の手順は以下のとおり：
- bip-anyprevoutの公開鍵が単一バイト
0x01であった場合、bip-taprootの署名検証ルールに使われる公開鍵はtaprootの内部キーになる（つまりbip-taprootの表記でいうとbytes(P)）。 - bip-anyprevoutの公開鍵が33バイトの場合、検証に使われる公開鍵の先頭バイトが
0x02もしくは0x03になるように先頭バイトのbit-1をセットすることで、bip-schnorr互換の公開鍵に変換される。残りの32バイトはスタック上のbip-anyprevout公開鍵と一致する。
hash_type
bip-taprootで許可されているhash_typeの値に加えて、bip-anyprevout公開鍵では、値0x41, 0x42, 0x43, 0xc1, 0xc2,0xc3が有効になる。hash_typeのビット6と7を使って以下の定数を定義する。
0x00 SIGHASH_ALLINPUT0x80 SIGHASH_ANYONECANPAY- 0x40 SIGHASH_ANYPREVOUT``
- 0xc0 SIGHASH_ANYPREVOUTANYSCRIPT``
そして、例えばhash_type & 0xc0 == SIGHASH_ANYPREVOUTの場合、SIGHASH_ANYPREVOUTがセットされていると言える。
トランザクションダイジェスト
署名opcodeの署名検証のメッセージとして、bip-anyprevout公開鍵のトランザクションダイジェストは、bip-tapscriptと以下が異なる。
- 全てのケースにおいて、
key_versionは0x02の代わりに定数値0x00が使われる。 SIGHASH_ANYPREVOUTがセットされている場合、outpointがダイジェストに含まれていないことを除いてSIGHASH_ANYONECANPAYがセットされた場合と同じように計算される。SIGHASH_ANYPREVOUTANYSCRIPTがセットされている場合、outpoint、scriptPubKeyおよびtapleaf_hashがダイジェストに含まれていないことを除いてSIGHASH_ANYONECANPAYがセットされた場合と同じように計算される。
SIGHASH_ANYPREVOUTがセットされている場合、トランザクションダイジェストへのバイト単位の入力は、対応するSIGHASH_ANYONECANPAYトランザクションダイジェストより36バイト短くなる（outpointのサイズ分）。SIGHASH_ANYPREVOUTANYSCRIPTがセットされている場合、トランザクションダイジェストへの入力は、SIGHASH_ANYPREVOUTがセットされている場合と比べてさらに68もしくは56バイト短くなる（tapleaf_hashの32バイト分と、scriptPubKeyの36バイトもしくは24バイト分）。
Chaperone署名
ANYPREVOUT署名が使われる場合、固定のprevout署名（つまり非ANYPREVOUTの署名）で保護されなければならない。
これを実現するため、スクリプトの実行開始時に3つのフラグv0_anyprevout、v0_fixedprevoutおよびv2_fixedprevoutが導入され、最初はすべてfalseがセットされている。これらは以下の場合にtrueになる。
- 公開鍵の先頭バイトが
0x02もしくは0x03で、nullでない署名の署名opcodeが成功した場合、フラグv2_fixedprevoutにtrueがセットされる。 - bip-anyprevout公開鍵とnullでない署名の署名opcodeが成功した場合：
SIGHASH_ANYPREVOUTもしくはSIGHASH_ANYPREVOUTANYSCRIPTがセットされている場合、フラグv0_anyprevoutにtrueがセットされる。- それ以外の場合（
SIGHASH_ALLINPUTもしくはSIGHASH_ANYONECANPAYがセットされている場合）、フラグv0_fixedprevoutにtrueがセットされる。
スクリプトの実行終了時に、v0_anyprevoutにtrueがセットされていても、v2_fixedprevoutとv0_fixedprevoutがfalseのままの場合、スクリプトは失敗しなければならない。
安全性
署名のリプレイ
SIGHASH_ALLINPUTおよびSIGHASH_ANYONECANPAYの署名と比べて、SIGHASH_ANYPREVOUTおよびSIGHASH_ANYPREVOUTANYSCRIPTは、同じ署名が違うトランザクションで再利用される署名リプレイの可能性をもたらす。
SIGHASH_ALLINPUTとSIGHASH_ANYONECANPAYの署名はどちらも１つ以上のインプットにコミットすることで署名のリプレイを防ぐため、同じインプットを複数回使用できる場合のみ署名のリプレイが可能になるが、BIP 30およびBIP 34以降のBitcoinブロックチェーンでは不可能だ。SIGHASH_ANYPREVOUTによる署名のリプレイは、同じscriptPubKeyと同じコインの量を持つ異なるUTXOに対して可能だが、SIGHASH_ANYPREVOUTANYSCRIPTによる署名のリプレイは同じコインの量を持つ異なるUTXOに対して可能で、潜在的なスクリプトの１つで同じbip-anyprevout公開鍵を再利用する。
その結果、署名のリプレイが資金の消失や他の望ましくないケースの原因になる場合、プロトコルの設計者とウォレットはANYPREVOUT署名を使用する際、同じアドレスを再利用しないことを保証しなければならず、SIGHASH_ANYPREVOUTANYSCRIPTを使って署名する場合はスクリプトでbip-anyprevout公開鍵を再利用しないことを保証しなければならない。
Malleability
SIGHASH_ANYPREVOUTまたはSIGHASH_ANYPREVOUTANYSCRIPTを使うと追加のmalleabilityが導入される可能性がある。
特に、ANYPREVOUT署名のみを使って承認されたトランザクションは、署名を満たす代替インプットを提供できる人すべてに対しmalleabilityがある。この方法で変更されたインプットは、同じ受信者に対して支払いをする有効なトランザクションであるがtxidが異なるという新しいトランザクションを生成する。インプットへの変更によって、（一部のインプットが共有されたままの場合）これは元のトランザクションと競合する可能性があり、または（そうでない場合）受信者への二重支払いになる可能性がある。
さらに、（稀な失敗のケースとしてeltooで想定されているように）同じscriptPubkeyとコインの量を使い、ANYPREVOUT署名のみで承認されるトランザクションのチェーンでは、特に中間のトランザクションを省略することで、第三者が秘密鍵にアクセスすることなく、トランザクション（およびそのtxid）を細工する可能性がある。
この形式の細工は、ANYPREVOUT署名を使用する子トランザクションでも対処できる。親トランザクションに細工された場合、その子はインプットとして細工された新しいtxidを参照するように単純に調整でき、ANYPREVOUT署名は有効のままだ。
ただし、SIGHASH_ALLINPUTもしくはSIGHASH_ANYONECANPAYの署名によって承認された子トランザクションでは、そのインプットがこの方法で細工された場合、新しい署名が必要になる。このリスクは、ANYPREVOUTで承認されたUTXOをSIGHASH_ALLINPUTもしくはSIGHASH_ANYONECANPAYで使用する前に、BIP 68/112の相対的タイムロックを使うことで、いくらか軽減できる。相対的なタイムロックは、インプットに十分承認されていることを保証し、大規模なブロックの再編成が起きた場合のみそれらを置き換えることができる。このアプローチには欠点があることに注意すること：相対的なタイムロックはchild-pays-for-parentによる手数料のバンプを妨げ、タイムロックが期限切れになるまで資金を一時的に使用不可能にするという明らかな欠点がある。
Chaperone署名の効果
Chaperone署名の導入は2つの方法で分析できる。
まず、ANYPREVOUT署名とChaperone署名によって署名されたトランザクションの安全性は、Chaperone署名のみで署名されたトランザクションよりも悪くない。これにより、アドレスの秘密鍵が共有されている場合に、トランザクションが既に可能であったよりも悪いセキュリティ特性を持つことがなくなる。二重使用や二重支払いは、秘密鍵の所有者が複数の署名をする場合にのみ可能であり、秘密鍵の所有者が細工されたトランザクションに署名することを選択した場合にのみトランザクションは細工される。Chaperone署名の秘密鍵がマルチシグアドレス用の既存の秘密鍵よりも基本的に安全性の低い方法で共有されていない場合、ANYPREVOUT署名によって承認された支払いを受け取るBitcoinユーザーは他の支払いと比べて追加のセキュリティ対策を講じる必要は無い。
第2に、ANYPREVOUT署名とChaperone署名を使ってトランザクションに署名をする効率は、ANYPREVOUT署名のみを使った場合よりもそれほど悪くはない。特に、ANYPREVOUT署名の秘密鍵は、トランザクションを発行することを承認されたすべての人の間で共有される鍵を介して1-of-Nのマルチシグ要件として扱うことができる。トランザクション公開される準備ができるまでに全てのインプットが既知でなければならないので、Chaperone署名は生成できる。これにより、トランザクション自体とトランザクションを公開するノードの両方に追加のオーバーヘッドが発生することに注意すること。また、トランザクションの複数の潜在的な発行者がそれぞれ異なるChaperone署名を生成する可能性があるため、witnessのmalleabilityに関する別のベクトルも導入される。これにより同じtxidにも関わらず、書く署名に対して異なるwtxidが生成される。これは（64バイトの署名ではなく65バイトの署名を使うことにより）手数料レートを僅かに変更する可能性があり、（ブロックはある署名を持っているが、そのブロックがリレーされたノードのメモリプールには異なる署名がある）ブロックリレーのパフォーマンスを低下させる可能性がある。
そのため、プロトコルの設計者は、Chaperone署名に対して既知の秘密鍵を使用せず、安全な方法でこれらの秘密鍵を生成し、その秘密鍵の配布を制限する必要がある。さらに署名者は、bip-schnorrで定義されているように、Chaperone署名を生成するために安全で決定論的な方法を使用する必要がある。
プライバシーに関する考慮事項
ANYPREVOUT署名は実際にはめったに使用されないことが予想される。プロトコルおよびウォレットの設計者は、トランザクションweightが低いという効率上の理由だけでなく、第三者が他のプロトコルのトランザクションとこのトランザクションを区別できないようにするためにも、できる限りTaprootのキーパスを使うようにする必要がある。
そのため、ANYPREVOUTを使ったトランザクションは、協調が不可能であったことを潜在的に含むトランザクションに関する情報または、（スクリプトの詳細により）使用しているプロトコル、ソフトウェアに関する情報が明らかになる。
プライバシーを最大限にするため、プロトコルの設計者は少なくとも１つのANYPREVOUT署名を使って使われるコインのスクリプト内でbip-anyprevout公開鍵のみを使用し、ANYPREVOUT署名なしで承認可能な使用にはキーパスもしくはマークルツリー内の代替スクリプトを使用することを推奨する。この推奨事項に従うと、追加のスクリプトブランチが必要になる場合がある。つまり推奨事項を無視すると、状況によってはコストとプライバシーの間のトレードオフが向上する可能性がある。
論拠
- どうして新しい公開鍵タイプを作るのか？ tapscriptの新しい公開鍵タイプは、bip-tapscriptで指定されている未知の公開鍵タイプに対して新しいルールを指定することでソフトフォークで導入できる。これは既存の署名opcodeに制限を加えるだけで良いためだ。可能な代替アプローチは、新しいscript opcodeを定義すること、異なるtaprootのleaf versionを使用すること、もしくはbip-taprootで定義されるものとは異なるsegwitアウトプットを使用することくらいだ。しかし、これらのアプローチはすべてより複雑で、これらのアプローチが提供する追加の柔軟性が実際に必要とされる他のアップグレードのために予約される。今回のケースでは、新しいトランザクションダイジェストを定義するが、同じ楕円曲線と署名アルゴリズム（つまりsecp256k1とbip-schnorr）を維持する。
- どうしてwitness scriptへコミットするのか（しないのか） eltooのペーパーは、witness scriptへコミットすることが必ずしも適切でない例を掲載している。署名を非対称に作成するためスクリプトとトランザクションの
nLocktimeを使用する。そのため、より早い番号の署名を持つトランザクションは、より後の番号の署名を持つトランザクションで使用できるが、後の番号の署名を持つトランザクションを、それより早い番号の署名を持つトランザクションで使用することはできない。結果として、さらに後の3番めの単一の署名を持つ後のトランザクションは、前の2つのトランザクションが例え異なるtaprscriptを持っていたとしても、そのトランザクションを使用できなければならない。一方、これらのケースでは、スクリプトにコミットするオプションがある正当な理由もある：各トランザクションには新しいスクリプトがあるため、スクリプトへコミットするとこれらのトランザクションの１つに正確に適用される署名を作成できる。eltooの場合、これにより、以前の任意の更新トランザクションに適用できる更新トランザクションの署名と、対応する更新トランザクションにのみ適用される決済トランザクションの署名が可能になり、両方に同じ鍵を使用する。結果、スクリプトをよりコンパクトにできる。 - キーパスの使用はどうなる？ この提案は、スクリプトパスを介した
ANYPREVOUTの使用のみをサポートし、キーパスを使った使用へのANYPREVOUTの使用はサポートしていない。これには３つの理由がある：最初に、キーパスの使用をサポートしないことで、bip-taprootおよびbip-tapscriptに含まれるコアな変更から独立させることができる。第二に、キーパスでChaperone署名を要求するのは不可能であるということ。第三に、アドレスがANYPREVOUTサポートをオプトインもしくはオプトアウトできるようにすると、使用される前に見分けがつかない。 - 0x00と0x01の使用 プレフィックスには125個のフリーペア（トータル128で、
0x02/0x03は既に使われ、0x04および0x06、0x07は使用不可）があるので、最初に利用可能なものを選択した。これによりtaprootの内部キーの1バイトのプッシュにOP_1を使用することもできる。（1バイトのpush opcodeは、0x08/0x09,0x0a/0x0b,0x0c/0x0d,0x0e/0x0f,0x10,OP_8 - OP_16,0x81,OP_1NEGATE`にも使用可能）。 - taprootの内部キー taprootの内部キーを使って署名することは、taprootのキーパスを使って署名することを意味するが、
SIGHASH_ANYPREVOUTANYSCRIPT署名の場合、これはtaprootアウトプットの鍵もしくはscriptPubkey計算する、もしくは全てのスクリプトを知る前に行うことができる。このキーのショートカットとして単一バイトの0x01を使用すると、単一バイトのOP_1を介してプッシュできるので、スクリプトをエンコードするのが非常に効率的になる。 - なぜkey_versionを変更するのか？
key_versionを変更することで、同じ秘密鍵を使ってbip-tapscriptの鍵とbip-anyprevout鍵の両方を生成した場合、 bip-tapscriptの鍵の署名はbip-anyprevoutの鍵の署名に対して有効ではなくなる（その逆もしかり）。 - Chaperone署名は必要？ 署名のリプレイや、追加のmalleabilityのリスクが単にウォレットや2ndレイヤーのプロトコルレベルではなく、コンセンサスレイヤーで実際の影響を与えるか、あるいは防止が必要かどうかについてはいくつかの論争がある*1。この提案が採用する設計の哲学は、コンセンサスの変更は、物事を危険にする証拠が不十分であるという否定的な議論ではなく、物事が安全でなくなることはないという肯定的な議論と一緒に検討すべきだ。Chaperone署名を追加しない限り、
ANYPREVOUTの安全性に対する肯定的な議論はない。実際には、ANYPREVOUT署名のみでも安全かもしれないが、それに対して理論的な証明も、実際にそれを実証する大規模な経験もない。安全性のセクションの議論は、ChaperoneANYPREVOUT署名の安全性が現在の署名と実質的に同等であることを示すのを目的にしている。つまり物事がそれほぞ安全でないことを示している。 - 常に固定のprevoutを必要とする署名にしないのはなぜ？ 別のアプローチは、
ANYPREVOUT署名が使われているかどうかに関わらず、常に固定のprevout署名を要求するというもので、つまりスクリプトの実行終了時にv2_fixedprevoutがtrueになり、v0_anyprevoutやv0_fixedprevoutをまったく追跡しないというものだ。これにより強い保証が提供される。トランザクションを検証するどんなノードもそれが認識する方法でインプットが署名されていることを確認するか、（将来の署名アップグレードが使われいるなら）トランザクションを完全に妨げられないと考えるだろう（アップグレードを有効にするOP_SUCCESSxの存在があるため）。欠点は、このような将来の変更にはbip-tapscript署名を伴う必要があるため、未知の公開鍵タイプを使って新しいトランザクションダイジェスト、もしくは潜在的に新しい署名アルゴリズム（別の楕円曲線への変更など）を導入する能力を大幅に制限する点だ。対照的に、Chaperone署名を必要とするかどうか選択するのは、新しい公開鍵タイプもしくは安全でないことが知られている署名を導入する場合のみである。つまり何か新しいものを導入する際に、我々が安全だと確認しているなら、不要なChaperone署名を要求することは強制されない。
展開
これは、bip-scnorr、bip-taproot、bip-tapscriptの展開と同時もしくはその後にソフトフォークとして展開できる。
後方互換正
ソフトフォークとして、古いソフトウェアは変更なく動作し続ける。bip-taprootをサポートするためにアップグレードしていないノードは全てのtaprootのwitness programを誰でも使用可能なスクリプトとして認識し、bip-taprootおよびbip-tapscriptをサポートするためにアップグレードしたがこのBIPには対応していないノードは単にbip-anyprevout公開鍵に対して空でない署名を有効なものとして扱う。ただし、bip-tapscript公開鍵に対するものである場合は、Chaperone署名を検証する。そのため、新しい公開鍵タイプの署名を完全に検証するためにはアップグレードすることを強く推奨する。
アップグレードされていないウォレットは、segwit version 0 programや従来のpay-to-pubkey-hashを使って、アップグレードされていないウォレットおよびアップグレードされたウォレットからBitcoinを送受信できる。実装によってはアップグレードされていないウォレットも、BIP 173 のBech32アドレスの送金をサポートしている場合、segwit version 1プログラムへの送金が可能である。アップグレードされていないウォレットはBIP 16のP2SHでネストされているsegwit version 1 programを使って、アップグレードされたウォレットにBitcoinを送金できる。
BIP 118との違い
segwit v0ではなくTaprootに基づいていることを除けば、BIP 118の主なセマンティクスの違いは以下のとおり：
- BIP 118
NOINPUT署名は、scriptPubkeyもしくはredeem/witness scriptのいずれかでアウトプットの使用条件にコミットしない。この提案は、SIGHASH_ANYPREVOUTANYSCRIPTが使用される場合は同じ振る舞いをするが、SIGHASH_ANYPREVOUTが使用される場合は、scriptPubkeyとtapscriptにコミットする。 - スクリプト内の
OP_CODESEPARATORは、この提案のSIGHASH_ANYPREVOUTおよびSIGHASH_ANYPREVOUTANYSCRIPTの両方の署名に影響するが、BIP 118のNOINPUT署名には影響しない。 - BIP 118は、（展開がBIP 141のP2WPKHおよびP2WSHと同様の方法で具体化されている仮定した場合）直接的な公開鍵の使用に対して有効に機能するはずだが、この提案では、tapscriptを介した署名にのみ適用され、キーパスを使った直接的な使用には適用されない。
- この提案ではChaperone署名を必要とするとが、BIP 118では必要としない。
- この提案では、
NOINPUTではなくANYPREVOUTという名称を使用する。これは前のアウトプットのコインの量は署名に使われる、つまり前のアウトプットのvalueやインプットのnSequenceの値および（オプションで）使用条件など、インプットのいくつかはまだコミットされるためである。
