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_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.
Sorry for the long delay. You’re quite correct that the example I gave does not work. Apparently I should have waited for Taproot Wizards new neovim script plugin. I believe this works for 3 more opcodes :(
<sig> <delegate_sig> <delegate_pubkey> <locktime> || CLTV SHA256 OVER CAT TOALT CHECKSIGVERIFY FROMALT <pubkey> CSFS
<authorizing_sig><authorizing_sig> <delegate_sig><authorizing_sig> <delegate_sig> <delegate_pubkey><authorizing_sig> <delegate_sig> <delegate_pubkey> <locktime><authorizing_sig> <delegate_sig> <delegate_pubkey> <locktime><authorizing_sig> <delegate_sig> <delegate_pubkey> <locktime_hash><authorizing_sig> <delegate_sig> <delegate_pubkey> <locktime_hash> <delegate_pubkey><authorizing_sig> <delegate_sig> <delegate_pubkey> <locktime_hash || delegate_pubkey><authorizing_sig> <delegate_sig> <delegate_pubkey><authorizing_sig><authorizing_sig> <locktime_hash || delegate_pubkey><authorizing_sig> <locktime_hash || delegate_pubkey> <authorizing_pubkey>locktime || key message was signed by authorizing_sig: TRUEThanks for checking the script.
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.
Posted this on the ML, but also adding here too. I think we are getting very close to finalizing this proposal.
Can anyone think of a reason to keep OP_CHECKSIGFROMSTACKVERIFY as NOP5 available in legacy script?
Currently Brandon and I are leaning towards simply removing CSFSV from LNhance and from the CSFS BIP.
Reasoning:
- CSFS is more likely to be used in Symmetry
- In case where CSFSV is desired OP_CSFS OP_VERIFY is perfectly workable.
- Simplifies code
- Don’t have an actual use case for CSFSV in legacy rn
- Upgradeable NOPs are scarce
- Backporting tapscript would bring all functionality to legacy
10+License: BSD-3-CLAUSE
11+```
12+
13+## Abstract
14+
15+This BIP describes two new opcodes for the purpose of checking cryptographic
I think this was overlooked after CSFSV got removed:
0This BIP describes a new opcode for the purpose of checking cryptographic
19+
20+When verifying taproot script spends having leaf version 0xc0 (as defined in
21+[BIP 342]), we propose `OP_CHECKSIGFROMSTACK` to replace `OP_SUCCESS204`
22+(0xcc).
23+
24+`OP_CHECKSIGFROMSTACKVERIFY` has semantics similar to `OP_CHECKSIG`, as
OP_CHECKSIGFROMSTACK or is this sentence obsolete?
44+
45+## Design Considerations
46+
47+1. Message hashing: [BIP 340] is compatible with any size of message and does not require it to be a securely hashed input, so the message is not hashed prior to [BIP 340] verification.
48+2. Lack of verify semantics: Adding a single opcode for this purpose keeps the implementation and design simple. An earlier draft had a verify variant as a NOP upgrade, and if this funcationality is later brought to legacy scripts, that would be a good time to add a verify variant.
49+3. Add/multisig: No concession is made to `OP_CHECKMULTISIG` or `OP_CHECKSIGADD` semantics with `OP_CHECKSIGFROMSTACK(VERIFY)`. In Tapscript, add semantics can be implemented with 1 additional vByte per key (`OP_TOALTSTACK OP_CHECKSIGFROMSTACK OP_FROMALTSTACK OP_ADD`).
Is this “(VERIFY)” obsolete or shorthand for OP_CSFS OP_VERIFY here?
03. Add/multisig: No concession is made to `OP_CHECKMULTISIG` or `OP_CHECKSIGADD` semantics with `OP_CHECKSIGFROMSTACK`. In Tapscript, add semantics can be implemented with 1 additional vByte per key (`OP_TOALTSTACK OP_CHECKSIGFROMSTACK OP_FROMALTSTACK OP_ADD`).
23+
24+`OP_CHECKSIGFROMSTACKVERIFY` has semantics similar to `OP_CHECKSIG`, as
25+specified below.
26+
27+Only 32-byte keys are constrained. Similar to [BIP 341] unknown key types, for
28+other key lengths no signature verification is performed.
33+* The public key (top element), message (second to top element), and signature (third from top element) are read from the stack.
34+* The top three elements are popped from the stack.
35+* If the public key size is zero, the script MUST fail and terminate immediately.
36+* If the public key size is 32 bytes, it is considered to be a public key as described in [BIP 340]:
37+ * If the signature is not the empty vector, the signature is validated against the public key and message according to [BIP 340]. Validation failure in this case immediately terminates script execution with failure.
38+* If the public key size is not zero, and it is not a [BIP 340] 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.
I’m not sure whether this is intentional, but previously we treat a 32-byte key as a BIP 340 public key. I assume if it were out-of-range, the signature validation would fail. However here, rather than repeating that the lengths 0-byte and 32-byte are excluded, the criterion appears to be “not zero and not a BIP 340 public key”. I assume this is covered by the previous line, but what if a 32-byte value were provided that is out of range, would this line apply or not?
Is it possible that this should read:
0* If the public key size is not zero bytes and not 32 bytes; the public key is of an unknown public key type. Signature verification for unknown public key types succeeds as if signature verification for a known public key type had succeeded.
45+## Design Considerations
46+
47+1. Message hashing: [BIP 340] is compatible with any size of message and does not require it to be a securely hashed input, so the message is not hashed prior to [BIP 340] verification.
48+2. Lack of verify semantics: Adding a single opcode for this purpose keeps the implementation and design simple. An earlier draft had a verify variant as a NOP upgrade, and if this funcationality is later brought to legacy scripts, that would be a good time to add a verify variant.
49+3. Add/multisig: No concession is made to `OP_CHECKMULTISIG` or `OP_CHECKSIGADD` semantics with `OP_CHECKSIGFROMSTACK(VERIFY)`. In Tapscript, add semantics can be implemented with 1 additional vByte per key (`OP_TOALTSTACK OP_CHECKSIGFROMSTACK OP_FROMALTSTACK OP_ADD`).
50+4. Splitting R/S on the stack: Implementing split/separate signatures is left as an exercise for other bitcoin upgrades, such as `[BIP 347]`.
It would be easier to follow if the title of BIP 347 were mentioned:
04. Splitting R/S on the stack: Implementing split/separate signatures is left as an exercise for other bitcoin upgrades, such as [BIP 347] (OP_CAT).
It also isn’t clear to me why this link text is code formatted.
46+
47+1. Message hashing: [BIP 340] is compatible with any size of message and does not require it to be a securely hashed input, so the message is not hashed prior to [BIP 340] verification.
48+2. Lack of verify semantics: Adding a single opcode for this purpose keeps the implementation and design simple. An earlier draft had a verify variant as a NOP upgrade, and if this funcationality is later brought to legacy scripts, that would be a good time to add a verify variant.
49+3. Add/multisig: No concession is made to `OP_CHECKMULTISIG` or `OP_CHECKSIGADD` semantics with `OP_CHECKSIGFROMSTACK(VERIFY)`. In Tapscript, add semantics can be implemented with 1 additional vByte per key (`OP_TOALTSTACK OP_CHECKSIGFROMSTACK OP_FROMALTSTACK OP_ADD`).
50+4. Splitting R/S on the stack: Implementing split/separate signatures is left as an exercise for other bitcoin upgrades, such as `[BIP 347]`.
51+5. [BIP 118]-style Taproot internal key: Rather than introducing an additional key type in this change, we suggest implementing [BIP 349] or separately introducing that key type for all Tapscript signature checking operations in a separate change.
I expect that not all readers know all BIP numbers by heart, so it might be easier to follow if proposals were referred to by name rather than just number:
05. APO-style ([BIP 118]) Taproot internal key: Rather than introducing an additional key type in this change, we suggest implementing `OP_INTERNALKEY` ([BIP 349]) or separately introducing that key type for all Tapscript signature checking operations in a separate change.
Note that the latter link is currently broken, because BIP 349 is not merged yet.
md
59+## Motivation
60+
61+### LN Symmetry
62+
63+When combined with [BIP 119] (`OP_CHECKTEMPLATEVERIFY`/CTV),
64+`OP_CHECKSIGFROMSTACK` (CSFS) can be used in Lightning Symmetry channels.
What do you mean with “can be used in Lightning Symmetry channels”? Do you mean that the two opcodes together can replicate the behavior of APO?
0When combined with [BIP 119] (`OP_CHECKTEMPLATEVERIFY`/CTV),
1`OP_CHECKSIGFROMSTACK` (CSFS) can be used to implement Lightning Symmetry channels.
0When combined with [BIP 119] (`OP_CHECKTEMPLATEVERIFY`/CTV),
1`OP_CHECKSIGFROMSTACK` (CSFS) can be used to replicate Lightning Symmetry channels.
11+```
12+
13+## Abstract
14+
15+This BIP describes two new opcodes for the purpose of checking cryptographic
16+signatures in bitcoin scripts against data other than bitcoin transactions.
I’m not sure “other than bitcoin transactions” is accurate. Would perhaps this fit better?
0signatures in bitcoin scripts against data on the stack.
0@@ -0,0 +1,133 @@
1+```
2+BIP: XXX
3+Layer: Consensus (soft fork)
4+Title: CHECKSIGFROMSTACK
5+Author: Brandon Black <freedom@reardencode.com>, Jeremy Rubin <j@rubin.io>
6+Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXXX
7+Status: Draft
8+Type: Standards Track
9+Created: 2023-12-22
0Created: 2024-11-26
122+
123+[BIP 341]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
124+
125+[BIP 342]: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
126+
127+[BIP 349]: https://github.com/bitcoin/bips/blob/master/bip-0349.mediawiki
0[BIP 349]: https://github.com/bitcoin/bips/blob/master/bip-0349.md
I believe I’ve addressed your comments. Thanks much!
Would love you to read over the new text I added in the Lightning Symmetry section.
Would love you to read over the new text I added in the Lightning Symmetry section.
LGTM
Nit: In the future, if you don’t reposition all the linebreaks, it’s much easier to see what was changed in text. :nerd_face:
I.e. it’s harder to discern what all the changes are in
0-`OP_CHECKSIGFROMSTACK` (CSFS) can be used in Lightning Symmetry channels.
1-The construction `OP_CHECKTEMPLATEVERIFY <pubkey> OP_CHECKSIGFROMSTACK` with a
2-spend stack containing the CTV hash and a signature for it is logically
3-equivalent to `<bip118_pubkey> OP_CHECKSIG` and a signature over
4-`SIGHASH_ALL|SIGHASH_ANYPREVOUTANYSCRIPT`. The `OP_CHECKSIGFROMSTACK`
5-construction is 8 vBytes larger.
6+`OP_CHECKSIGFROMSTACK` (CSFS) can be used to implement Lightning Symmetry
7+channels. The construction `OP_CHECKTEMPLATEVERIFY <pubkey>
8+OP_CHECKSIGFROMSTACK` with a spend stack containing the CTV hash and a
9+signature for it is logically equivalent to `<bip118_pubkey> OP_CHECKSIG` and
10+a signature over `SIGHASH_ALL|SIGHASH_ANYPREVOUTANYSCRIPT`. The
11+`OP_CHECKSIGFROMSTACK` construction is 8 vBytes larger.
than in
0-`OP_CHECKSIGFROMSTACK` (CSFS) can be used in Lightning Symmetry channels.
1+`OP_CHECKSIGFROMSTACK` (CSFS) can be used to implement Lightning Symmetry channels.
ACK on the current content.
Might want to consider mentioning the deleted key function verification scheme we learned from @bigspider?
edit: Will add to PAIRCOMMIT instead! Since it needs multiple elements signed to work.
I’m not sure whether you were still waiting for the other couple reviewers, but they can also take a look when it is a merged draft. The Rationale seems a bit concise, I would like to suggest that relevant questions and comments may still be added to this as they are brought up per coming review.
Gonna merge this now, if you want to make further changes, please open another pull request.
