Closing Signed Message Update wire #182
Conversation
bmancini55
left a comment
bmancini55
left a comment
There was a problem hiding this comment.
Code structure looks good! Couple minors on commenting the protocol.
| "0027"+ // type | ||
| "0000000000000000000000000000000000000000000000000000000000000000" + // Channel ID | ||
| "0000000000030d40" + // feeSatoshi | ||
| "22222222222222222222222222222222222222222222222222222222222222223333333333333333333333333333333333333333333333333333333333333333" //signature |
|
|
||
|
|
||
| /** | ||
| */ |
There was a problem hiding this comment.
Add comment on the purpose of this message and include when we send it and when we expect to receive it.
There was a problem hiding this comment.
Looks good, but let's add two more things:
- purpose of fee negotiation
- how fee rate is convergent
There was a problem hiding this comment.
- Maybe I am wrong, isn't the purpose for fee negotiation is that how fast one of the two side wants the transaction to be included in the block?
- As for the Fee rate convergence, On every negotiation step we must give up some amount from our proposal towards the other peer’s proposal. Eg. assuming the peer proposes a closing fee of 3000 satoshi and our estimate shows it must be 4000. “10”: our next proposal will be 4000-10=3990. This exchange continues using the channelID until both agree on the same fee or when one side fails the channel.
Should I update the nxt commit using the above points?
References :
There was a problem hiding this comment.
Re 1: For mutual close both sides want the transaction in with minimal fees. Without anchors, the feerate_per_kw set at open or through update_fee is suggested to be 5x the amount that will get the transaction included in the block, which is extremely expensive. One of the benefits of mutual close is that the fee rate can be negotiated down from the existing fee rate to a more reasonable one.
Re 2: Correct, though you may want to say that it is convergent by requiring the fee rate to be strictly between the last proposed and the counterparty's last proposed value. The back and forth continues until values are equal, at which point both sides can broadcast the closing tx.
There was a problem hiding this comment.
That's very informative. Wasn't aware that initial fee kept or suggested is that high! Thanks
| public static type: MessageType = MessageType.ClosingSigned; | ||
|
|
||
| /** | ||
| * Deserializes the funding_signed message |
| public channelId: ChannelId; | ||
|
|
||
| /** | ||
| * fee_satoshis is set according to its estimate of cost of inclusion in a block. |
There was a problem hiding this comment.
Include comments about the expected value when sending or receiving.
bmancini55
left a comment
bmancini55
left a comment
There was a problem hiding this comment.
Looking good with a couple small changes
|
|
||
|
|
||
| /** | ||
| */ |
There was a problem hiding this comment.
Looks good, but let's add two more things:
- purpose of fee negotiation
- how fee rate is convergent
| /** | ||
| * Expected value for fee_satoshis could vary how fast either side wants the transaction | ||
| * to be included in the block. So changes are made accordingly on both ends and communicated | ||
| * between the channel untill both of them comes to an agreement or when one side fails the |
2 participants
wire: create closing_signed message type #180
BOLT #2
closing_signedin BOLT #2@bmancini55