You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I realized that the solution could be specified what we must disallow, so I open the PR (BOLT 2: forget the check about update_* messages, and check what must not happens during shutdown #972) where it is specified only the message that we must not receive, in this case, an add htlc msg
3.1. Not in the PR but discussed, we should send a commitment_signed when there is no pending htlc
3.2 We should keep the constraint of update fee msg, like : if the update_fee is too low for timely processing, OR is unreasonably large: MUST send a warning and close the connection, or send an error and fail the channel
During the adventure in lnprototest I realized that we can send multiple shutdown with different scriptpubkey and my claim here is the same of before, we should specify if this behavior is wrong what a node should not do, and not what we should do in the case of multiple shutdown with different scriptpubkey
4.1: We should allow it? (BOLT 2: allow multiple shutdown message from the sender side. #976)
4.2: We should add a rule to ban multiple shutdowns? (BOLT 2: disallow sending multiple shutdown msg #977)
The text was updated successfully, but these errors were encountered:
With this issue, I would like to clarify and put the timeline on coop-close PRs that we discuss in the last meeting.
In particular, the discussion started with the following issue #964 :
commitment_signed
(BOLT#02: clarify coop close requirements #970)update_*
messages, and check what must not happens duringshutdown
#972) where it is specified only the message that we must not receive, in this case, an add htlc msg3.1. Not in the PR but discussed, we should send a
commitment_signed
when there is no pending htlc3.2 We should keep the constraint of update fee msg, like :
if the update_fee is too low for timely processing, OR is unreasonably large: MUST send a warning and close the connection, or send an error and fail the channel
scriptpubkey
and my claim here is the same of before, we should specify if this behavior is wrong what a node should not do, and not what we should do in the case of multiple shutdown with differentscriptpubkey
4.1: We should allow it? (BOLT 2: allow multiple shutdown message from the sender side. #976)
4.2: We should add a rule to ban multiple shutdowns? (BOLT 2: disallow sending multiple
shutdown
msg #977)The text was updated successfully, but these errors were encountered: