Published on: 2018-01-22T10:45:58+00:00
In a discussion on the Lightning-dev mailing list, ZmnSCPxj proposed a new message called `funding_cancelled` that would inform the fundee node that the funder node is certain that the channel funding transaction cannot be confirmed. The purpose of this message is to address the lack of a protocol-required minimum timeout for unopened channels and to allow replace-by-fee funding transactions and multi-channel funding transactions.The proposal suggests that implementing this message should not be difficult if the node software already has code to forget the channel after a timeout. To explain how the message would work, ZmnSCPxj provided examples of different scenarios. In one scenario, if the funder needs to replace a replace-by-fee (RBF) funding transaction, they would re-initiate the opening protocol and broadcast the replacement funding transaction. Once one of the transactions is confirmed deeply enough, the funder would cancel the other funding transaction using the `funding_cancelled` message.In another scenario, if the funder wants to fund multiple channels from a single transaction, they would initiate the opening protocol with each fundee separately. However, if some fundees complete the protocol up to `funding_signed` while others time out or fail to contact, the funder cannot safely broadcast the funding transaction. In this case, the funder can use the `funding_cancelled` message to free up resources on the completed fundee nodes.While the proposal suggests that the `funding_cancelled` message may not be necessary if funding timeout is implemented by the fundee node, it emphasizes that the message would allow the funder node to free up resources on the fundee node. This proposal opens a discussion for adding the `funding_cancelled` message to the v1.1 specification.A contributor to the Lightning Network's RFC repository has proposed a new message called `funding_cancelled` in a pull request. This proposed message is designed to inform the fundee node that the funder node is certain that the channel funding transaction can never confirm. The purpose of including this message is to facilitate replace-by-fee (RBF) funding transactions and multi-channel funding transactions.Implementing the `funding_cancelled` message should not be burdensome as it triggers the code that forgets the channel after a timeout if the channel funding transaction times out or if the message is received. If the funder wishes to replace an RBF funding transaction, they can re-initiate the opening protocol from `open_channel` -> `accept_channel` -> `funding_created` -> `funding_signed`, and then broadcast the replacement funding transaction. Once one of the transactions is confirmed deeply enough, the funder cancels the other funding transaction via `funding_cancelled`.In addition to facilitating RBF funding transactions, the `funding_cancelled` message also allows for multi-channel funding transactions. In this scenario, the funder initiates the opening protocol with each node separately and must not broadcast the funding transaction until all fundees reply `funding_signed`. If some fundees complete the protocol up to `funding_signed` but others do not, the funder cannot safely broadcast the funding transaction at all. Consequently, the funder node can send `funding_cancelled` to each fundee that completed up to `funding_signed` to free up the resources of those nodes.While the `funding_cancelled` message may not be necessary if funding timeout is implemented by the fundee node, it offers benefits such as allowing the funder node to free up resources on the fundee node. On the other hand, implementing RBF funding transactions and multi-channel funding transactions is more involved compared to implementing the `funding_cancelled` message.
Updated on: 2023-07-31T19:38:02.993222+00:00