Updated to match the BIN, and with @Roasbeef 's comments. TYVM!

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 #1535 (comment) 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.

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. 🤓

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.