forked from bitcoin/bips
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
9c57fac
commit c76263a
Showing
1 changed file
with
105 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,105 @@ | ||
<pre> | ||
BIP: TBD | ||
Layer: Consensus (soft fork) | ||
Title: CHECKSIGFROMSTACK | ||
Author: Brandon Black <[email protected]> | ||
Comments-Summary: No comments yet. | ||
Status: Draft | ||
Type: Standards Track | ||
Created: 2023-12-22 | ||
License: PD | ||
</pre> | ||
|
||
==Abstract== | ||
|
||
This BIP describes two new opcode for the purpose of checking cryptographic | ||
signatures in bitcoin scripts against data other than bitcoin transactions. | ||
|
||
==Specification== | ||
|
||
We propose replacing OP_NOP5 in bitcoin script with | ||
'''OP_CHECKSIGFROMSTACKVERIFY'''. When verifying taproot script spends having | ||
leaf version 0xc0 (as defined in BIP342), we propose '''OP_CHECKSIGFROMSTACK''' | ||
to replace '''OP_SUCCESS188''' (0xbc). | ||
|
||
'''OP_CHECKSIGFROMSTACK''' and '''OP_CHECKSIGFROMSTACKVERIFY''' have identical | ||
semantics to '''OP_CHECKSIG''' and '''OP_CHECKSIGVERIFY''' respectively, | ||
except: | ||
|
||
* On success the arguments to '''OP_CHECKSIGFROMSTACKVERIFY''' are left unchanged on the stack. | ||
* They pop (or read, respectively) 3 arguments (rather than 2) from the stack in the following order: '''<pubkey> <data> <sig>''' | ||
* Signatures must not have a sighash byte appended | ||
* The message being verified is '''<data>''' | ||
** '''<data>''' may be any length. | ||
** For ECDSA signature verification '''<data>''' is SHA256 hashed before being used as the message. | ||
==Design Considerations== | ||
|
||
# Message hashing: ECDSA requires the message to be securely hashed to 32-bytes before being used in the signing protocol, so a SHA256 hash is taken before the message is passed for ECDSA signing. BIP340 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 BIP340 signing. | ||
# Verify NOP upgrade: To bring both ECDSA and BIP340 signing to bitcoin script, a NOP upgrade path was chosen for '''OP_CHECKSIGFROMSTACKVERIFY'''. This necessarily means leaving the 3 arguments on the stack when executing '''OP_CHECKSIGFROMSTACKVERIFY'''. Scripts will need to drop or otherwise manage these stack elements. | ||
# 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 OP_TOALTSTACK'''). | ||
# Splitting R/S on the stack: Implementing split/separate signatures is left as an exercise for future bitcoin upgrades, such as '''OP_CAT'''. | ||
# BIP118-style Taproot internal key: Rather than introducing an additional key type in this change, we suggest implementing OP_INTERNALKEY or separately introducing that key type for all Tapscript signature checking operations in a separate change. | ||
# Unknown key lengths: The semantics of other signature checking opcodes in their respective script types (legacy, segwit, tapscript) are applied. | ||
==Resource Limits== | ||
|
||
These opcodes are treated identically to other signature checking opcodes and | ||
count against the various sigops limits in their respective script types. | ||
|
||
==Motivation== | ||
|
||
===LN Symmetry=== | ||
|
||
When combined with '''OP_CHECKTEMPLATEVERIFY''' (BIP119/CTV), | ||
'''OP_CHECKSIGFROMSTACK''' (CSFS) can be used in Lightning Symmetry channels. | ||
The construction '''OP_CHECKTEMPLATEVERIFY <pubkey> OP_CHECKSIGFROMSTACK''' is | ||
logically equivalent to '''<bip118_pubkey> OP_CHECKSIG''' and a signature over | ||
'''SIGHASH_ALL|SIGHASH_ANYPREVOUTANYSCRIPT'''. The '''OP_CHECKSIGFROMSTACK''' | ||
construction is 8 vBytes larger. | ||
|
||
===Delegation=== | ||
|
||
Using a script like: | ||
'''OP_DUP <pubkey> OP_CHECKSIGFROMSTACK OP_DROP OP_CHECKSIG''' | ||
A script can delegate signing to another key. | ||
|
||
==Reference Implementation== | ||
|
||
A reference implementation is provided in provided here: | ||
|
||
https://github.com/brandonblack/bitcoin/commit/bf375614f7bd73a2a84cdd4b660e6c02ad4bcbc3 | ||
|
||
==Backward Compatibility== | ||
|
||
By constraining the behavior of an OP_SUCCESS opcode and an OP_NOP 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_SUCCESS188, | ||
OP_CHECKSIGFROMSTACk would invalidate their spend. | ||
|
||
==Deployment== | ||
|
||
TBD | ||
|
||
==Credits== | ||
|
||
Reference implementation was made with reference to the implementation in | ||
Elements and started by moonsettler. | ||
|
||
==References== | ||
|
||
[https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki BIP 119] CHECKTEMPLATEVERIFY | ||
|
||
[https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki BIP 118] SIGHASH_ANYPREVOUT | ||
|
||
[https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP 340] Schnorr Signatures | ||
|
||
[https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP 341] Taproot | ||
|
||
[https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki BIP 342] Tapscript | ||
|
||
[https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki OP_CAT] | ||
|
||
==Copyright== | ||
|
||
This document is placed in the public domain. |