[Lightning-dev] [1.1] Proposed `funding_cancelled` message

[ZmnSCPxj]

Good morning,

> -------- Original Message --------
> Subject: Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message
> Local Time: January 9, 2018 2:28 AM
> UTC Time: January 8, 2018 6:28 PM
> From: pm+lists at acinq.fr
> To: ZmnSCPxj <ZmnSCPxj at protonmail.com>
> lightning-dev\\@lists.linuxfoundation.org <lightning-dev at lists.linuxfoundation.org>
>
> Hello,
>
>> intended to inform the fundee node that the funder node is definitely sure that the channel funding transaction can never confirm
>
> If the deprecated tx initially sent funds to the fundee via push_msat,
> then the fundee may not want to trust the funder on this. One way to
> do it trustlessly would be for the funder to attach the actual
> deprecated funding tx (not necessarily signed, but still could be big)
> to the funding_cancelled message, then the fundee would be able to
> verify that its inputs have indeed been spent by the overriding tx.

This will not work easily for the multi-channel funding transaction case.

Suppose the funder node A wants to make two channels to two other nodes B and C using a single funding transaction.

1.  In parallel, it initiates the open_channel on both B and C.
2.  B and C respond with accept_channel.  A can now create the funding transaction.
3.  In parallel, it sends the funding_created to both B and C.
4.  B responds with funding_signed.  However, C suddenly disconnects instead of responding with funding_signed.
5.  A cannot safely broadcast the funding transaction.  So it does funding_cancelled to B instead.

It is not safe for A to send the funding transaction to B, because B can turn around and broadcast the funding transaction itself (for example, B and C can be in cahoots with each other, and force A to push_msat more funds to C).  In the above case there is no replacement created - the intent is not to increase the fees to speed up opening the channel, the intent is to create a single funding transaction that can be used to anchor A<->B and A<->C channels.

Of course, A can simply double-spend the inputs it used for the multi-channel funding transaction to an address it controls solely, but that just adds an otherwise-unnecessary transaction with the cost paid by A.  A would prefer to simply silently forget the A<->B and A<->C channels and let B waste its resources hopelessly scanning each block for a transaction that A will never want to broadcast.

The important part to remember for this proposal is that the current 1.0 spec already allow both replace-by-fee and muilti-channel funding transactions, but at the cost of wasting resources on the fundee side, while only the funder side gets the benefit (either faster channel opens or cheaper channel opens).  Remember that the protocols for both replace-by-fee funding transactions and multi-channel funding transactions simply require implementation on the funder side, with the fundee side using the same protocol as the simple single-channel non-replaceable funding transaction case.  To prevent this, a fundee node might restrict the number of pending channel opening attempts that a peer can have with it; implementing `funding_cancelled` lets the funder free up this imposed resource limit on the fundee side.

(one could say that the c-lightning one-channel-one-peer is an example of this limiting of the resources an external node can consume, for example; of course, my understanding is that this limit will be lifted later on)

Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180109/64e7e93c/attachment-0001.html>