BIP 112 Support (CSV)

I notice that there is no explicit OP_CHECKSEQUENCEVERIFY support. While scripts using this operation can still be constructed by using OP_NOP3, I was wondering if there were any plans to add support and tests.

[afk11]

This is not an easy task… All our templates to date are static in terms of the opcodes used. But CSV is an opcode that is never used by itself - it’s always with signature checks, hashlocks, etc. I would say our biggest blocker to this is having to pivot from static templates, to dynamic templates.

Eg:

[height] CSV DROP DUP HASH160 [hash] EQUALVERIFY CHECKSIG

This one is easy, and we could add a template… Moreso however, it should probably be two templates: CSV || P2PKH. But most usages of CSV actually are inside IF ELSE ENDIF branches such as this:

IF 
    [height] CSV DROP DUP HASH160 [hash] EQUALVERIFY CHECKSIG
ELSE
    2-of-2 CHECKMULTISIG
ENDIF

Here the first script is inside an IF branch… but what happens if we move the CSV part outside?

[height] CSV DROP
IF 
    DUP HASH160 [hash] EQUALVERIFY CHECKSIG
ELSE
    2-of-2 CHECKMULTISIG
ENDIF

Anyways, just generalizing here, this applies for CLTV, and others too, but it highlights the ground work needed… The actual code for “signing” or “verifying” CSV isn’t that much work - just check the txins sequence >= CSV stack value - but learning that your script has a CSV element, and forming a strategy for the whole script is harder 😃

Also, checking the signatures on such things is also a worthwhile question. We don’t check signatures in any way here, even for the static types (P2PK, P2PKH, multisig)… but if we start to deal with IF, CSV, CLTV, etc… we really need to look at writing a script interpreter, since it can also verify signatures for scripts we don’t know how to sign!

This comment turned out longer than expected, but overall the thesis is: Undestanding a scripts requirements for signing is always the hardest part. It’s easier when the scripts can be considered atomic such as the cases we support now, but in principle what we’re talking about here is scripts with multiple stages, and potentially multiple branches also.

It’s definitely something I see bitcoinjs working towards in the future, because otherwise for LN, etc, we’d be forced to write our own hacky template checking, and use sighash operations in userland code, etc… and really I think the value in a library like bitcoinjs is preventing unsafe usage, not encouraging people to do that second option 😃

[dcousens]

Closing in favour of https://github.com/bitcoinjs/bitcoinjs-lib/compare/csv?expand=1