bitcoin
Add bip-csfs OP_CHECKSIGFROMSTACK(VERIFY)
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.
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.
@reardencode: If you feel that your proposal is not ready to be merged, please convert the pull request to a Draft.
I converted this to draft since @reardencode indicated that this would likely need more changes before being ready for number assignment and merge. Given that this hasn’t been updated in half a year, is this still in progress?
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?
@reardencode per your question in https://github.com/bitcoin/bips/pull/1535#issuecomment-2111195930 and above, the current process is that of BIP 2. Iteration while in Draft status seems to be expected, but a BIP may only change status from Draft to Proposed when the author deems it is complete. An incomplete and unofficial simplified requirement list might be: (for number assignment) dev ML discussion, is high-quality, technically sound and complete, keeps with Bitcoin philosophy, well-scoped, has motivation, accurate title, addresses backwards compatibility, no BIP number conflicts, and (for draft merge): preamble, acceptable copyright, complete header (with status and type, correct layer if provided).
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
Can we change the name of this PR and remove (VERIFY) to more accurately reflect the latest state of the proposal?
Updated with an additional example, removed CSFSV, and all earlier review comments addressed.
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
-`OP_CHECKSIGFROMSTACK` (CSFS) can be used in Lightning Symmetry channels.
-The construction `OP_CHECKTEMPLATEVERIFY <pubkey> OP_CHECKSIGFROMSTACK` with a
-spend stack containing the CTV hash and a signature for it is logically
-equivalent to `<bip118_pubkey> OP_CHECKSIG` and a signature over
-`SIGHASH_ALL|SIGHASH_ANYPREVOUTANYSCRIPT`. The `OP_CHECKSIGFROMSTACK`
-construction is 8 vBytes larger.
+`OP_CHECKSIGFROMSTACK` (CSFS) can be used to implement Lightning Symmetry
+channels. The construction `OP_CHECKTEMPLATEVERIFY <pubkey>
+OP_CHECKSIGFROMSTACK` with a spend stack containing the CTV hash and a
+signature for it is logically equivalent to `<bip118_pubkey> OP_CHECKSIG` and
+a signature over `SIGHASH_ALL|SIGHASH_ANYPREVOUTANYSCRIPT`. The
+`OP_CHECKSIGFROMSTACK` construction is 8 vBytes larger.
than in
-`OP_CHECKSIGFROMSTACK` (CSFS) can be used in Lightning Symmetry channels.
+`OP_CHECKSIGFROMSTACK` (CSFS) can be used to implement Lightning Symmetry channels.
@murchandamus I believe moon and a couple others will take a look today, then I think this is G2G.