-
Notifications
You must be signed in to change notification settings - Fork 493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BOLT 2: allow multiple shutdown message from the sender side. #976
BOLT 2: allow multiple shutdown message from the sender side. #976
Conversation
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
2be3f10
to
2b919c9
Compare
I don't see a reason to make this explicit. I don't think we bother verifying it but if anything I'd think we'd make it explicit you can't send a redundant one but not bother specifying it for the receiver end. |
This is a second proposal different from lightning#976 where it is not allowed to send multiple shutdown messages from the receiver viewpoint. The rationale for this is to avoid bad cases like the following one that is permitted by the spec ``` ____________________________________________ | sender -> shutdown(script_one) -> receiver | | sender -> shutdown(script_two) -> receiver | | sender <- shutdown(script_one) <- receiver | -------------------------------------------- ``` Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
This is a second proposal different from lightning#976 where it is not allowed to send multiple shutdown messages from the receiver viewpoint. The rationale for this is to avoid bad cases like the following one that is permitted by the spec ``` ____________________________________________ | sender -> shutdown(script_one) -> receiver | | sender -> shutdown(script_two) -> receiver | | sender <- shutdown(script_one) <- receiver | -------------------------------------------- ``` Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
@vincenzopalazzo we should probably close this PR as we're going with #977 instead? |
Yes @t-bast, I was planning to jump inside the spec today to align all the details about the close, so we can conclude the conversation from this side |
This is a second proposal different from lightning#976 where it is not allowed to send multiple shutdown messages from the receiver viewpoint. The rationale for this is to avoid bad cases like the following one that is permitted by the spec ``` ____________________________________________ | sender -> shutdown(script_one) -> receiver | | sender -> shutdown(script_two) -> receiver | | sender <- shutdown(script_one) <- receiver | -------------------------------------------- ``` Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
This is a second proposal different from lightning#976 where it is not allowed to send multiple shutdown messages from the receiver viewpoint. The rationale for this is to avoid bad cases like the following one that is permitted by the spec ``` ____________________________________________ | sender -> shutdown(script_one) -> receiver | | sender -> shutdown(script_two) -> receiver | | sender <- shutdown(script_one) <- receiver | -------------------------------------------- ``` Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
This is something that I'm reasoning about during my lnprototest work, and maybe opening a PR gives me more opportunities to get feedback.
What happens if, during a Close Channel operation, the sender sent multiple shutdowns?
At this moment, the spec doesn't tell anything about this case, but I think this is information to add. In my opinion, we need to allow multiple shutdown message from the sender (maybe after a timeout if we have no answer back), but in this case, there is some problem to resolve:
scriptpubkey
in the message? accept any of thescriptpubkey
sent? or accept only the last one? In the last case, we can have more control over what we are doing but we can fall into a loop if the received is slow to answer again.Think that this may introduce a complicated state machine in the spec, which I want to avoid!