Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-08 📝 Original message: I have to say I'm rather ...

📅 Original date posted:2018-01-08
📝 Original message:
I have to say I'm rather not a fan of this idea. Adding messages which do not result in different node behavior other then waiting for the timeout with little overhead on the node to simply keep watching for the funding transaction is a recipe for ending up with a needlessly complex protocol and misimplementation.

On January 8, 2018 3:26:23 AM UTC, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>Good morning Lightning world,
>
>https://github.com/lightningnetwork/lightning-rfc/pull/349
>
>I propose in the above pull request a new `funding_cancelled` message
>intended to inform the fundee node that the funder node is definitely
>sure that the channel funding transaction can never confirm.
>
>This thread is intended to open a discussion for this proposed message,
>to be added to v1.1 spec.
>
>The reason for including this message is the below:
>
>1. Implementing this message should not be onerous, if the node
>software already implements code to forget the channel after a timeout.
>We simply trigger this code if the channel funding transaction times
>out or if this message is received.
>2. It allows replace-by-fee funding transactions. To replace an RBF
>funding transaction, the funder simply re-initiates the opening
>protocol from `open_channel` -> `acccept_channel` -> `funding_created`
>-> `funding_signed`, then broadcasts the replacement funding
>transaction. Then both funder and fundee wait for either the old or
>the new funding transaction to confirm (miners might reject
>replacements, or the new funding transactions might simply not have
>propagated to the miner at the time of mining a new block), and once
>one of the transactions is confirmed deeply enough, the funder cancels
>the other funding transaction via `funding_cancelled`.
>3. It allows multi-channel funding transactions. To fund multiple
>channels from a single transaction, the funder initiates the opening
>protocol to each node separately. However, the funder must not
>boradcast the funding transaction until all fundees reply
>`funding_signed`. If some fundees complete the protocol up to
>`funding_signed` but some fundees time out or fail/cannot contact, then
>the funder cannot safely broadcast the funding transaction at all. The
>funder node can then send `funding_cancelled` to each fundee that
>completed up to `funding_signed` to free resources of those nodes.
>
>In principle the message is unnecessary if funding timeout is
>implemented by the fundee node. However, this message lets the funder
>node free up resources on the fundee node.
>
>Admittedly, implementing RBF funding transactions and multi-channel
>funding transactions is more involved than implementing
>`funding_cancelled`,
>
>Regards,
>ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180108/de444926/attachment.html>;