From d2932bd00d16992d90df82d2a37db79c355046c4 Mon Sep 17 00:00:00 2001 From: Brandon Black Date: Wed, 24 Apr 2024 14:40:53 -0700 Subject: [PATCH] Add BIP 0348 - CHECKSGIFROMSTACK --- README.mediawiki | 7 +++ bip-0348.md | 142 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 149 insertions(+) create mode 100644 bip-0348.md diff --git a/README.mediawiki b/README.mediawiki index 5adc1555c4..cae9eb7a4d 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1121,6 +1121,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0348.md|348]] +| Consensus (soft fork) +| CHECKSIGFROMSTACK +| Brandon Black, Jeremy Rubin +| Standard +| Draft +|- | [[bip-0349.md|349]] | Consensus (soft fork) | OP_INTERNALKEY diff --git a/bip-0348.md b/bip-0348.md new file mode 100644 index 0000000000..8d13ef1606 --- /dev/null +++ b/bip-0348.md @@ -0,0 +1,142 @@ +
+  BIP: 348
+  Layer: Consensus (soft fork)
+  Title: CHECKSIGFROMSTACK
+  Author: Brandon Black 
+          Jeremy Rubin 
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0348
+  Status: Draft
+  Type: Standards Track
+  Created: 2024-11-26
+  License: BSD-3-Clause
+
+ +## Abstract + +This BIP describes a new opcode for the purpose of checking cryptographic +signatures in bitcoin scripts against data from the stack. + +## Summary + +When verifying taproot script spends having leaf version 0xc0 (as defined in +[BIP 342]), we propose `OP_CHECKSIGFROMSTACK` to replace `OP_SUCCESS204` +(0xcc). + +`OP_CHECKSIGFROMSTACK` has semantics similar to `OP_CHECKSIG`, as specified +below. Briefly, it pops 3 elements from the stack: a 32-byte public key, a +message, and a signature. If the signature is valid for that public key and +message, 1 is pushed to the stack. If the signature is the empty vector, 0 is +pushed to the stack, and otherwise script execution fails. + +Only 32-byte keys are constrained. Similar to [BIP 341] unknown key types, for +other key lengths no signature verification is performed and it is considered +successful. + +## Specification + +* If fewer than 3 elements are on the stack, the script MUST fail and terminate immediately. +* The public key (top element), message (second to top element), and signature (third from top element) are read from the stack. +* The top three elements are popped from the stack. +* If the public key size is zero, the script MUST fail and terminate immediately. +* If the public key size is 32 bytes, it is considered to be a public key as described in [BIP 340]: + * 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. +* If the public key size is not zero 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. +* If the script did not fail and terminate before this step, regardless of the public key type: + * If the signature is the empty vector: An empty vector is pushed onto the stack, and execution continues with the next opcode. + * If the signature is not the empty vector: + * The opcode is counted towards the sigops budget as described in [BIP 342]. + * A 1-byte value 0x01 is pushed onto the stack. + +## Design Considerations + +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. +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. +3. 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`). +4. 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`). +5. 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. + +## Resource Limits + +These opcodes are treated identically to other signature checking opcodes and +count against the sigops and budget. + +## Motivation + +### LN Symmetry + +When combined with [BIP 119] (`OP_CHECKTEMPLATEVERIFY`/CTV), +`OP_CHECKSIGFROMSTACK` (CSFS) can be used to implement Lightning Symmetry +channels. The construction `OP_CHECKTEMPLATEVERIFY +OP_CHECKSIGFROMSTACK` with a spend stack containing the CTV hash and a +signature for it is logically equivalent to ` OP_CHECKSIG` and +a signature over `SIGHASH_ALL|SIGHASH_ANYPREVOUTANYSCRIPT`. The +`OP_CHECKSIGFROMSTACK` construction is 8 vBytes larger. + +Summary of alternatives: +* CTV+CSFS is the minimal functionality needed for Lightning Symmetry but requires the use of an `OP_RETURN` for data availability +* APO is the original design for Lightning Symmetry and uses the taproot annex for data availability. +* LNHANCE (CTV+CSFS+IKEY+PC) is the most efficient and direct way currently designed to implement Lightning Symmetry. + +### Delegation + +Using a script like: +` SWAP IF 2 PICK SWAP CSFS VERIFY ENDIF CHECKSIG` +either direct verification or delegation can be achieved by the following +unlock stacks: ` 0` or ` 1` + +### Advanced delegation when combined with [OP_PAIRCOMMIT] or OP_CAT + +Using a script like: +`CLTV OVER PAIRCOMMIT TOALT CHECKSIGVERIFY FROMALT CSFS` +or: +`CLTV SHA256 OVER CAT TOALT CHECKSIGVERIFY FROMALT CSFS` +with the unlock stack: +` ` + +Delegates to a public key after a lock time, enabling delegation to various +keys after various associated times. + +## Reference Implementation + +A reference implementation is provided in provided here: + +https://github.com/bitcoin/bitcoin/pull/29270 + +## Backward Compatibility + +By constraining the behavior of an OP_SUCCESS opcode, +deployment of the BIP can be done in a backwards compatible, soft-fork manner. +If anyone were to rely on the OP_SUCCESS behavior of +`OP_SUCCESS204`, `OP_CHECKSIGFROMSTACK` would invalidate +their spend. + +## Deployment + +TBD + +## Credits + +Reference implementation was made with reference to the implementation in +Elements and started by moonsettler. + +## Copyright + +This document is licensed under the 3-clause BSD license. + +[BIP 119]: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki + +[BIP 118]: https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki + +[BIP 340]: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki + +[BIP 341]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki + +[BIP 342]: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki + +[BIP 349]: https://github.com/bitcoin/bips/blob/master/bip-0349.md + +[BIP 347]: https://github.com/bitcoin/bips/blob/master/bip-0347.mediawiki + +[OP_PAIRCOMMIT]: https://github.com/bitcoin/bips/pull/1699 + +[mailing list]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019192.html