Add bip-csfs OP_CHECKSIGFROMSTACK(VERIFY) #1535

pull reardencode wants to merge 1 commits into bitcoin:master from reardencode:csfs changing 2 files +131 −0
  1. reardencode commented at 6:32 pm on January 7, 2024: none

    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.

  2. reardencode force-pushed on Jan 13, 2024
  3. in bip-csfs.mediawiki:10 in 5df867cb87 outdated
     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
    


    ajtowns commented at 5:41 am on January 18, 2024:

    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.
  4. in bip-csfs.mediawiki:21 in 5df867cb87 outdated
    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
    


    Roasbeef commented at 1:29 am on April 23, 2024:
    Why split across two extension mechanisms instead of just focusing on the modern path (op success)?

    reardencode commented at 9:53 pm on April 24, 2024:

    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.

  5. in bip-csfs.mediawiki:40 in 5df867cb87 outdated
    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:
    


    Roasbeef commented at 1:32 am on April 23, 2024:
    Is the ref to BIP 137 here a typo? 137 is primarily about the old Bitcoin signed message scheme.

    reardencode commented at 9:44 pm on April 24, 2024:
    These legacy keys are no longer supported - sorry for the waste of time, this PR had gotten out of date while I was working on this document as a BIN
  6. in bip-csfs.mediawiki:42 in 5df867cb87 outdated
    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.
    


    Roasbeef commented at 1:34 am on April 23, 2024:
    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.

    reardencode commented at 9:43 pm on April 24, 2024:
    Signature verification for CHECKSIGFROMSTACK is done the same regardless of the script context.
  7. in bip-csfs.mediawiki:49 in 5df867cb87 outdated
    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
    


    Roasbeef commented at 1:36 am on April 23, 2024:
  8. in bip-csfs.mediawiki:51 in 5df867cb87 outdated
    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.
    


    Roasbeef commented at 1:43 am on April 23, 2024:

    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
    

    reardencode commented at 9:56 pm on April 24, 2024:

    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.

  9. jonatack added the label New BIP on Apr 23, 2024
  10. in bip-csfs.mediawiki:105 in 5df867cb87 outdated
    100+
    101+TBD
    102+
    103+==Credits==
    104+
    105+Reference implementation was made with reference to the implementation in
    


    Roasbeef commented at 2:08 am on April 24, 2024:
    Perhaps this should also credit Jeremy (as he made a mailing list post soliciting feedback for a design in 2021), and also the authors of the proposal he directly references in the ML?
  11. reardencode force-pushed on Apr 24, 2024
  12. reardencode force-pushed on Apr 24, 2024
  13. reardencode force-pushed on Apr 24, 2024
  14. reardencode commented at 9:59 pm on April 24, 2024: none
    Updated to match the BIN, and with @Roasbeef ’s comments. TYVM!
  15. jonatack added the label Needs number assignment on Apr 24, 2024
  16. reardencode force-pushed on Apr 25, 2024
  17. reardencode force-pushed on Apr 25, 2024
  18. in bip-csfs.md:9 in 0267f3fe47 outdated
    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
    


    murchandamus commented at 7:18 pm on May 1, 2024:
    Please use the preamble format specified in BIP2.
  19. murchandamus added the label PR Author action required on May 8, 2024
  20. Add bip-csfs. a15c86aab2
  21. reardencode force-pushed on May 14, 2024
  22. reardencode commented at 9:50 pm on May 14, 2024: none

    Fixed preamble.

    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)

    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.

  23. murchandamus commented at 3:06 pm on May 22, 2024: contributor
    @reardencode: If you feel that your proposal is not ready to be merged, please convert the pull request to a Draft.
  24. murchandamus removed the label Needs number assignment on May 22, 2024

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-31 23:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me