Conversation
| - 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!
The `option_upfront_shutdown_script` feature requires the shutdown script to match the script agreed during channel opening. However, `option_simple_close` allows a zero-value `OP_RETURN` output when a node considers its output uneconomical. Allow this exception in both the sender and receiver requirements so the features can be used together. Other script mismatches still fail the connection, and the zero-value output prevents this exception from redirecting funds to another address. Co-Authored-By: HAL 9000
20cf8a7 to
2b2aa9d
Compare
|
Excuse the delay here. Amended with some changes. @t-bast let me know if that reads better. |
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.