Add bip-csfs OP_CHECKSIGFROMSTACK(VERIFY) #1535
Conversation
bip-csfs.mediawiki
Outdated
| ==Summary== | ||
|
|
||
| We propose replacing OP_NOP5 (0xb4) in bitcoin script with | ||
| <code>OP_CHECKSIGFROMSTACKVERIFY</code>. When verifying taproot script spends having |
There was a problem hiding this comment.
Why split across two extension mechanisms instead of just focusing on the modern path (op success)?
There was a problem hiding this comment.
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.
bip-csfs.mediawiki
Outdated
| ** 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. | ||
| * 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: | ||
| ** 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. | ||
| * 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. |
There was a problem hiding this comment.
Public key types were only introduced in segwit v1 (BIP 342), so this wouldn't apply to a version of this op code that also exists under the segwit v0 paradigm.
There was a problem hiding this comment.
Signature verification for CHECKSIGFROMSTACK is done the same regardless of the script context.
bip-csfs.mediawiki
Outdated
| *** For <code>OP_CHECKSIGFROMSTACK</code>, an empty vector is pushed onto the stack, and execution continues with the next opcode. | ||
| ** If the signature is not the empty vector: | ||
| *** For tapscript 0xc0, the opcode is counted towards the sigops budget as described in BIP341. | ||
| *** For legacy and segwit v0, the opcode is counted towards the sigops limit, as described in BIP141 |
There was a problem hiding this comment.
The sig ops budget is described in BIP 342: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#resource-limits
bip-csfs.mediawiki
Outdated
| *** For tapscript 0xc0, the opcode is counted towards the sigops budget as described in BIP341. | ||
| *** For legacy and segwit v0, the opcode is counted towards the sigops limit, as described in BIP141 | ||
| *** For <code>OP_CHECKSIGFROMSTACKVERIFY</code>, execution continues without any further changes to the stack. | ||
| *** For <code>OP_CHECKSIGFROMSTACK</code>, a 1-byte value 0x01 is pushed onto the stack. |
There was a problem hiding this comment.
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:
OP_TOALTSTACK (assuming the number N is on the top of the stack)
<pubkey> OP_CHECKSIGFROMSTACK
OP_IF
OP_DROP (drop the 0x01 pushed in the success case)
OP_FROMALTSACK (bring back the accumulator)
1 OP_ADD (acc += 1)
OP_ELSE
OP_DROP (drop the empty vector)
OP_FROMALTSACK (put unchanged accumulator back on the stack)
OP_ENDIF
There was a problem hiding this comment.
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.
reardencode
force-pushed
the
csfs
branch
3 times, most recently
from
b1cb659
to
f6e50d1
Compare
|
Updated to match the BIN, and with @Roasbeef 's comments. TYVM! |
| | BIP-XXXX | `CHECKSIGFROMSTACK` | ||
| | :--------- | :------------------ | ||
| | Layer | Consensus (soft fork) | ||
| | Author | Brandon Black <freedom@reardencode.com>, Jeremy Rubin <j@rubin.io> | ||
| | Discussion | https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376/9 | ||
| | Status | Draft | ||
| | Type | Standards Track | ||
| | Created | 2023-12-22 | ||
| | License | BSD-3-CLAUSE |
There was a problem hiding this comment.
Please use the preamble format specified in BIP2.
murchandamus
added
the
PR Author action required
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.