This BIP is based on the BCH OP_CHECKDATASIG work, as well as postings from the bitcoin dev mailing list in this thread. Some differences appear due to the activation of bips 340, 341, and 342 (taproot) since those were developed.
OP_CHECKSIGFROMSTACKVERIFY is a NOP upgrade available in all script types. OP_CHECKSIGFROMSTACK is an OP_SUCCESS upgrade available only in BIP342 tapscript.
5+ Author: Brandon Black <freedom@reardencode.com>
6+ Comments-Summary: No comments yet.
7+ Status: Draft
8+ Type: Standards Track
9+ Created: 2023-12-22
10+ License: PD
Why is Public Domain no longer acceptable for new BIPs?
- In some jurisdictions, public domain is not recognised as a legitimate legal action, leaving the BIP simply copyrighted with no redistribution or modification allowed at all.
16+signatures in bitcoin scripts against data other than bitcoin transactions.
17+
18+==Summary==
19+
20+We propose replacing OP_NOP5 (0xb4) in bitcoin script with
21+<code>OP_CHECKSIGFROMSTACKVERIFY</code>. When verifying taproot script spends having
Checking signatures from the stack is something that can be supported on all script types (i.e. is compatible with NOP upgrade), and there are use cases where segwit v0 scripts still make the most sense vs. tapscripts.
If supporting legacy and segwitv0 where possible for new opcodes is not something that others value, switching CSFSV to an OP_SUCCESS upgrade would make sense.
35+* The public key (top element), message (second to top element), and signature (third from top element) are read from the stack.
36+* For <code>OP_CHECKSIGFROMSTACK</code> the top three elements are popped from the stack.
37+* If the public key size is zero, the script MUST fail and terminate immediately.
38+* If the public key size is 32 bytes, it is considered to be a public key as described in BIP340:
39+** If the signature is not the empty vector, the signature is validated against the public key and message according to BIP340. Validation failure in this case immediately terminates script execution with failure.
40+* For legacy and segwit v0 scripts, if the public key size is 33 bytes and its first byte is 0x02 or 0x03, it is considered a compressed public key as described in BIP137:
37+* If the public key size is zero, the script MUST fail and terminate immediately.
38+* If the public key size is 32 bytes, it is considered to be a public key as described in BIP340:
39+** If the signature is not the empty vector, the signature is validated against the public key and message according to BIP340. Validation failure in this case immediately terminates script execution with failure.
40+* For legacy and segwit v0 scripts, if the public key size is 33 bytes and its first byte is 0x02 or 0x03, it is considered a compressed public key as described in BIP137:
41+** If the signature is not the empty vector, the signature is validated against the public key and message using ECDSA. Validation failure in this case immediately terminates script execution with failure.
42+* If the public key size is not zero, and it is not a BIP340 public key, nor a BIP137 compressed public key; the public key is of an unknown public key type, and no actual signature verification is applied. During script execution of signature opcodes they behave exactly as known public key types except that signature validation is considered to be successful.
44+** If the signature is the empty vector:
45+*** For <code>OP_CHECKSIGFROMSTACKVERIFY</code>, the script MUST fail and terminate immediately.
46+*** For <code>OP_CHECKSIGFROMSTACK</code>, an empty vector is pushed onto the stack, and execution continues with the next opcode.
47+** If the signature is not the empty vector:
48+*** For tapscript 0xc0, the opcode is counted towards the sigops budget as described in BIP341.
49+*** For legacy and segwit v0, the opcode is counted towards the sigops limit, as described in BIP141
46+*** For <code>OP_CHECKSIGFROMSTACK</code>, an empty vector is pushed onto the stack, and execution continues with the next opcode.
47+** If the signature is not the empty vector:
48+*** For tapscript 0xc0, the opcode is counted towards the sigops budget as described in BIP341.
49+*** For legacy and segwit v0, the opcode is counted towards the sigops limit, as described in BIP141
50+*** For <code>OP_CHECKSIGFROMSTACKVERIFY</code>, execution continues without any further changes to the stack.
51+*** For <code>OP_CHECKSIGFROMSTACK</code>, a 1-byte value 0x01 is pushed onto the stack.
I wonder if there’s a use for a OP_CHECKSIGFROMSTACKADD variant…
So something that would be compatible with usage of OP_CHECKSIGADD. On the other hand, it is possible to replicate such behavior with OP_CHECKSIGFROMSTACK in combination with other existing op codes, eg:
0OP_TOALTSTACK (assuming the number N is on the top of the stack)
1<pubkey> OP_CHECKSIGFROMSTACK
2OP_IF
3 OP_DROP (drop the 0x01 pushed in the success case)
4 OP_FROMALTSACK (bring back the accumulator)
5 1 OP_ADD (acc += 1)
6OP_ELSE
7 OP_DROP (drop the empty vector)
8 OP_FROMALTSACK (put unchanged accumulator back on the stack)
9OP_ENDIF
Yep. I had the same internal conversation and concluded that the rare cases where CSFSA behavior is needed using the altstack is an acceptable alternative.
Compared to standard CHECKSIG where CHECKMULTISIG was in active use on legacy/segwitv0 wallets, new wallets or protocols built on CSFS are much more likely to use MuSig2 or FROST when multiple signers are insolved, or (as BitGo’s 2-of-3 MuSig2/tapscript wallet does) to have the different signing combinations split between tapscript paths where CSFSV+CSFS are more efficient than CSFSA.
100+
101+TBD
102+
103+==Credits==
104+
105+Reference implementation was made with reference to the implementation in
0@@ -0,0 +1,122 @@
1+| BIP-XXXX | `CHECKSIGFROMSTACK`
2+| :--------- | :------------------
3+| Layer | Consensus (soft fork)
4+| Author | Brandon Black <freedom@reardencode.com>, Jeremy Rubin <j@rubin.io>
5+| Discussion | https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376/9
6+| Status | Draft
7+| Type | Standards Track
8+| Created | 2023-12-22
9+| License | BSD-3-CLAUSE
Fixed preamble.
There’s still 2 open conversations around this one:
I’ll post on the mailing list for additional opinions on these topics, but not sure whether it makes sense for the BIP to get numbered and merged as is while still potentially subject to those revisions.
30+other key lengths no signature verification is performed.
31+
32+## Specification
33+
34+* If fewer than 3 elements are on the stack, the script MUST fail and terminate immediately.
35+* The public key (top element), message (second to top element), and signature (third from top element) are read from the stack.
nit: I’d like to offer the suggestion that the push order goes:
<msg> <sig> <key> instead of <sig> <msg> <key>. The current CHECKSIG ordering is <sig> <key> and it seems odd to me that we would make the CSFS opcode put the msg between these other pushes. Alternatively you could go <sig> <key> <msg> and it would seem to me as equally intuitive. As is though it feels like a gotcha.
Is there a specific reason this choice was made that I hadn’t considered?
Anything that comes from the input stack should be before things that are provided by the locking script, so sig definitely comes first. Depending on particulars msg might come from the input stack or the locking script, and key always comes from the locking script. Examples:
<delegate-sig> <sig> <delegate-key> || DUP TOALT <key> CSFS VERIFY FROMALT CHECKSIG<sig> <hash> || CTV <key> CSFS<sig> || <flags> TXHASH <key> CSFS<sig> <settlement-hash> <update-hash> || CTV SHA256 CAT <key> CSFS
Retracted.
I understand the general direction of what you’re getting at but I have to admit that I’m not following the specific use cases where <msg> might come from the witness instead of the script. It makes sense to me why you’d want <msg> in the script, what’s lest clear is under what conditions it is useful to let the witness define it.
In any kind of delegation (see the first example above) the message is provided by the witness (i.e. the thing you’re delegating to by signing). Here’s a powerful example:
<delegate_sig> <sig> <delegate_pubkey> <locktime> || CLTV SHA256 CAT <pubkey> CSFS VERIFY CHECKSIG
Delegate to a key but only after <locktime>, with different locktimes per delegate key.
Forgive me but I have to expand this out because it doesn’t make sense to me:
Witness:
<delegate_sig><delegate_sig> <authorizing_sig><delegate_sig> <authorizing_sig> <delegate_pubkey><delegate_sig> <authorizing_sig> <delegate_pubkey> <locktime>Script:
5. locktime is checked: <delegate_sig> <authorizing_sig> <delegate_pubkey> <locktime>
6. locktime is hashed: <delegate_sig> <authorizing_sig> <delegate_pubkey> <locktime_hash>
7. locktime hash combined with delegate pubkey: <delegate_sig> <authorizing_sig> <delegate_pubkey || locktime_hash>
8. authorizing pubkey is pushed: <delegate_sig> <authorizing_sig> <delegate_pubkey || locktime_hash> <authorizing_pubkey>
9. CSFS(V) operation(s) checks that the delegate pubkey is authorized after the locktime by checking the key || locktime message was signed by authorizing_sig: <delegate_sig>
10. CHECKSIG operation fails because we don’t have a key? Maybe you forgot a dup somewhere? Maybe I don’t understand script as well as I thought? idk.
Assuming this is roughly what you meant, then I’d imagine in this case the authorizing signature would be pre-signed and distributed. Then at transaction time the delegate presents the authorizing signature along with their key and assigned locktime.
Assuming all of this is a fair reading, then I think I get what you mean with <msg> having an interesting use case wherein it could be:
… which seems pretty cool. I’d love if you can correct either my understanding or your example for completeness, but otherwise I’m satisfied with this and this thread can be resolved.
Definitely still WIP. Just hasn’t been much reason to advance the conversation around the two specific questions I mentioned given the state of the broader conversation around bitcoin’s future consensus changes.
I am a bit confused about the need to have those questions answered before merging. Is the intention of the BIPs repository only to hold final specifications for consensus changes, or to enable iterating on consensus changes before proposing a document for numbering and merging?
I am a bit confused about the need to have those questions answered before merging. Is the intention of the BIPs repository only to hold final specifications for consensus changes, or to enable iterating on consensus changes before proposing a document for numbering and merging?
You had written above
I’ll post on the mailing list for additional opinions on these topics, but not sure whether it makes sense for the BIP to get numbered and merged as is while still potentially subject to those revisions.
which I interpreted as a request to hold off while the situation might still be developing. I take it that I misunderstood you?
which I interpreted as a request to hold off while the situation might still be developing. I take it that I misunderstood you?
Gotcha. Yeah, I honestly just don’t know whether it makes sense to number and merge the BIP with outstanding questions like those or not. Since we’re back in motion LNHANCE, I’ll follow through and see what opinions appear :)
Thanks!
@reardencode: Preferably, as much as possible of the proposal is in place before it is put forth for an Editor review. Open questions tend to signal that a BIP may still be developing directionally and editors may be holding off due to that. ;)
If the open questions concern minor details, or have been resolved, please let us know that it is ready for an editor review.
There’s still 2 open conversations around this one:
* Should it add CSFSA (after discussions in ATX with Rusty and Rob, I'm inclined to add it) * Should CSFSV be tapscript only (I'm inclined to add this functionality to legacy scripts as well, but may be in the minority there)
For what it’s worth, I also think signature aggregation will be the dominant form of CSFS use. LNhance at it’s core is CTV + CSFS, and so it makes sense to have both of those available in pre-tapscript.
No strong opinion on CHECKSIGFROMSTACKADD, agree with the general reasoning.
It’s a bit weird to backport Schnorr this way, and the NOP upgrade path leaving 3 elements on the stack is also unfortunate. On the other hand, reverting CSFSV to use ECDSA in pre-tapscript would force us to consider implementing script multisig, to do anything really worthwhile there.
