Clarify simple_close and upfront_shutdown_script compatibility - #1348
Clarify simple_close and upfront_shutdown_script compatibility#1348tnull wants to merge 1 commit into
simple_close and upfront_shutdown_script compatibility#1348Conversation
The `option_upfront_shutdown_script` feature mandates that a node fails the connection if the counterparty provides a shutdown script that doesn't match what was previously negotiated during channel open. However, `option_simple_close` allows the counterparty to change its shutdown script to a 0-value `OP_RETURN` if it doesn't deem its output economical to still meet the dust threshold. Here we simply clarify that both are compatible, i.e., the `OP_RETURN` special case for `option_simple_close` shouldn't be rejected even if `option_upfront_shutdown_script` was negotiated.
| - MAY send a `warning`. | ||
| - MUST fail the connection. | ||
| - if both nodes advertised the `option_upfront_shutdown_script` feature, and the receiving node received a non-zero-length `shutdown_scriptpubkey` in `open_channel` or `accept_channel`, and that `shutdown_scriptpubkey` is not equal to `scriptpubkey` | ||
| - if not both nodes advertised `option_simple_close` and the `shutdown_scriptpubkey` is `OP_RETURN`: |
There was a problem hiding this comment.
A negation at the beginning of a statement is hard to parse without the right parenthesis 🤓
Is this not ( (both nodes advertised option_simple_close) AND (shutdown_scriptpubkey is OP_RETURN) ) or not ( both nodes advertised option_simple_close ) AND (shutdown_scriptpubkey is OP_RETURN)?
I'd rather rewrite it without boolean gates, explicitly separating simple close from legacy close (it's more verbose but easier to parse IMHO):
- if both nodes advertised `option_simple_close`:
- if the `shutdown_scriptpubkey` received is not using `OP_RETURN`:
- MAY send a `warning`.
- MUST fail the connection.
- otherwise:
- MAY send a `warning`.
- MUST fail the connection.
Does that correctly capture what you meant?
There was a problem hiding this comment.
Hmm, agree it could be formulated better. The wording you propose doesn't mention option_upfront_shutdown_script though, so it would make more sense in the section on option_upfront_shutdown_script where this context is implied, no?
The main edge case that I want to clarify is the case where both nodes negotiate option_upfront_shutdown_script and option_simple_close. In that case, we should permit counterparties to send a shutdown script that is different from the pre-negotiated shutdown script if the new one is OP_RETURN etc. Otherwise option_upfront_shutdown_script and option_simple_close would simply be incompatible IIUC.
There was a problem hiding this comment.
The main edge case that I want to clarify is the case where both nodes negotiate option_upfront_shutdown_script and option_simple_close. In that case, we should permit counterparties to send a shutdown script that is different from the pre-negotiated shutdown script if the new one is OP_RETURN etc. Otherwise option_upfront_shutdown_script and option_simple_close would simply be incompatible IIUC.
Yes, I agree that this can be clarified, I was just pointing out that the current clarification is a bit hard to read and may be misinterpreted.
The wording you propose doesn't mention option_upfront_shutdown_script though, so it would make more sense in the section on option_upfront_shutdown_script where this context is implied, no?
True, feel free to move this somewhere else or change it however you think makes sense!
2 participants
The
option_upfront_shutdown_scriptfeature mandates that a node fails the connection if the counterparty provides a shutdown script that doesn't match what was previously negotiated during channel open.However,
option_simple_closeallows the counterparty to change its shutdown script to a 0-valueOP_RETURNif it doesn't deem its output economical to still meet the dust threshold. Here we simply clarify that both are compatible, i.e., theOP_RETURNspecial case foroption_simple_closeshouldn't be rejected even ifoption_upfront_shutdown_scriptwas negotiated.