BIP 112 Support (CSV)

[colatkinson]

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.

[dcousens]

PRs accepted to https://github.com/bitcoinjs/bitcoin-ops for the OP code.

100% we want this, but haven't added it yet.

[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 :)

[afk11]

This might be the first logical step towards this, and getting CSV support sooner rather than later..

The first means adding signSteps to transaction_builder (for each input), and expecting a script to be well formed from templates. Inputs no longer have signatures/pubkeys directly, but objects for a checksig operation do.

• Deal with scripts with only execution pathway, with multiple templates, such as

  • 100 CSV DROP [Alice] CHECKSIG
  • [Alice] CHECKSIG 100 CSV DROP
  • DUP HASH160 [AliceHash] EQUALVERIFY CHECKSIG [Bob] CHECKSIG 2 [Carol] [Mallory] 3 CHECKMULTISIG
  • and so on

• Later: Deal with scripts with multiple branches, and multiple templates, so long as they match templates

  • IF [P2PKH] ELSE [multisig] ENDIF
  • DUP HASH160 [hash] EQUAL IF [P2PKH1] ELSE [P2PKH2]

• Much later: remove some constraints from using the template model, so we can deal with really weird stuff:

  • DUP DROP DUP DROP DUP HASH160 [hash] EQUALVERIFY CHECKSIG

[dabura667]

but what happens if we move the CSV part outside?

@afk11 The OP_IF won't run at all because the CSV fails and OP_VERIFY contained in it fails.

personally I am against CSV templates....... There's just too many options for height values, and those height values need to be stored by the wallets adding complexity...

We could add templates for fixed CSV/CLTV values (144 blocks = 1 day) for 1 day, one week, one month...

Or we could change it so that the library only uses 144 block granularity and add a function that takes a P2SH address and a ECPair and brute forces to check how many days the address waits for...

otherwise I don't recommend it...

[dcousens]

@dabura667 I think CSV templates will be worthwhile, but maybe not as part of this library to start. Modules!

[afk11]

@dabura667 I'm aware - the point is you can have random IF's in the middle of your 'templates', so you do need to parse out mutually exclusive opcodes to see what the templates are (if IF support is desirable, which is is for LN). It does look valid to me, but it's only for illustrating that point :)

And, I wouldn't propose a template for each script type and interval (such as 144D_CSV_P2PK) as a template.. I'd just have the transaction_builder look for several templates in the script. Our signer only deals with signature operations, but there are more to consider.. HashLocks, SequenceLocks, TimeLocks, etc, all informed by the script the user provides.

For the heights.. those are embedded in the scriptPubKey/rs/ws (just like hashes are in P2PKH), so you can check the transaction being signed satisfies it.

[dcousens]

Added BIP68 encoding library to README (#943), with intentions to add some BIP112 integration examples.

[dcousens]

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