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: [email protected]
> To: ZmnSCPxj <[email protected]>
> lightning-dev\\@lists.linuxfoundation.org
> <[email protected]>
>
> 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
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
