Bitcoin Cash 2019 May Update

Bitcoin-ABC/bitcoin-abc

Bitcoin ABC 0.19.0が公開されました。JST 2019/05/15夜頃に適用となるBitcoin Cash 2019 Mayのハードフォークアップデートを含むものです。

Summary

主な変更点は以下の通りです。

P2SH-Segwitアドレスへの送金コインの回収
Bitcoin CashではSegwitアドレスに送付されたUTXOはAnyone Can Payに誰でも使用出来る状態と認識され、実際に度々マイナーによってそれらのUTXOが回収されていました。
しかし、2018 Novに実施されたハードフォークアップデートのTx展性への対策として追加されたCleanStackルールの副作用として、P2SHなSegwitアドレスに送られたUTXOの回収がどうやっても出来なくなった為、今回の変更でP2SH Segwitアドレスへ送られたUTXOは例外としてCleanStackルールを無視するよう変更し、取り出しが可能となります。

Schnorr署名対応
一般にP2PKHで使用されているCHECKSIG及び2018 Novのハードフォークで追加されたCHECKDATASIGでSchnorr署名が利用出来るようになります。
ECDSAが使えなくなるということではなく、Schnorr署名も使えるようになる形で、ウォレット目線では軽微ながらデータサイズの削減によるFeeの削減、ノード目線ではTransactionの検証コストの軽減のメリットがあります。

影響と具体的な内容

P2SH-Segwitアドレスへの送金コインの回収
CleanStackはBitcoin Scriptの評価終了時、Stackとして2つ以上のアイテムが残った場合に不正なTxとするルールです。自作のScriptで認証を行うような、特殊なトランザクションでない限り、通常は全く問題となりませんが、BIP141(Segwit)を使ったトランザクションは数少ない問題となるケースになっています。

Segwit では、非Segwitのトランザクションとの区別を先頭に余剰なPUSHオペレータを入れることで行っています。

witness: <signature> <pubkey>
scriptSig: <0 <20-byte-key-hash>>
(0x160014{20-byte-key-hash})
scriptPubKey: HASH160 <20-byte-script-hash> EQUAL
(0xA914{20-byte-script-hash}87)
BIP141

上記でのscriptSigの先頭0が相当します。Segwitが動かないBitcoin Cashでは、これをただのBIP16と認識し、

0 <20-byte-key-hash>  HASH160 <20-byte-script-hash> EQUAL
上記を実行し、Hashの一致が確認出来た場合
0 20-byte-key-hash

として動作します。スタックを操作するオペレーターは残っていない為、そのままスタックのTOPが評価されNon Zeroとして有効なTxと判断されます。この時、余剰な0が残ることがCleanStackによりP2SH-Segwitアドレスへの送金コインが使えなくなった理由です。

唯一必要なHASH160でscriptPubKeyのハッシュ値と一致する<0 <20-byte-key-hash>>についても、Bitcoinで一度でもそのアドレスが使用されていれば周知の事実となる為、アドレスの所有者以外でも秘密鍵を要さず使用が可能です。
とはいえBitcoinではおかしなTxがリレーされて広まることを防ぐ為、一般的なスクリプトをStandard、そうでないものをNon-Standardとして、Non-StandardなTxは他のノードにリレーしないように出来ており、Bitcoin Cashにおいて上記のようなトランザクションはNon-Standardとしてマイナー以外の一般の利用者がTxを作成しても誰もリレーしてくれません。
本アップデートが適用されても、事実上はマイナーだけが直接ブロックに含めることで回収することが可能なものであり、このことから公式のspecでも「マイナーによる」といった主体を限定した表現になっています。

Schnorr署名対応
OP_CHECKDATASIG、OP_CHECKSIGのオペレーターでSchnorr署名が利用出来るようになります。Bitcoinを祖先としたブロックチェーンの中では最初の採用となります。
効果が期待されるOP_CHECKMULTISIGでは今アップデートでは対応されない為、Feeの削減という意味では限定的な効果となりますが、今まで1署名辺り最大73bytes要していたものが65bytes(OP_CHECKDATASIGではSigHashがない為64bytes)まで縮小出来ることで数％取引可能数量のスケールとなります。

それぞれ共通のオペレータで、署名の種類を示すPrefix等は導入されない為、データサイズでECDSA/Schnorrの区別がされることになる為、偶然にもECDSAで65bytes署名が生成されてしまった場合は、アップデート後は無効なTxと判断されるようになってしまい、RFC6979等による決定的kの算出を行っている場合は対応が難しくなりますが、発生確率としては2^-49およそ1京分の1と完全無視とまでは行かないものの、特段対応を取らないで良いぐらいの確率となっています。