Sounds to me like the lack of a protocol-required minimum timeout is the issue.
Because the cost of tracking an unopened channel is relatively trivial, I see
limited reason to bother notifying the peer that a channel has timed out.
However, due to potentially radically different concepts for what is and isn't
an acceptable wait time, it's likely useful to have something like "a receiving
node MUST keep a channel ready to be used for at least a week prior to funding
transaction confirmation. Thus, a node creating a funding transaction SHOULD
double-spend and make unconfirmable a funding transaction which has not
confirmed prior to a week."
Note that obviously a node can keep the initial commitment transaction around
and just wait forever and if the funding transaction ever confirms it can go
broadcast the initial commitment transaction then, but it's much nicer to be
able to simply double spend via RBF.
Given the relative simplicity on the receiving end, this could even be slipped
in to the spec today prior to v1.1.
Cue bikeshedding.
On January 9, 2018 5:25:29 AM UTC, ZmnSCPxj <zmnsc...@protonmail.com> wrote:
>Good morning Matt,
>
>> -------- Original Message --------
>> Subject: Re: [Lightning-dev] [1.1] Proposed `funding_cancelled`
>message
>> Local Time: January 8, 2018 10:42 PM
>> UTC Time: January 8, 2018 2:42 PM
>> From: lf-li...@mattcorallo.com
>> To: ZmnSCPxj <zmnsc...@protonmail.com>,
>lightning-dev\\@lists.linuxfoundation.org
><lightning-dev@lists.linuxfoundation.org>
>>
>> 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.
>
>There is no specified timeout for funding transactions, and thus a
>fundee node may keep track of funding transactions until end-of-life.
>This is a concern since replaceable funding transactions require that
>all versions be monitored on the blockchain - there is always the
>possibility that the winning miner got older versions of the funding
>transaction.
>
>To my mind, a sketch of an implementation for `funding_cancelled`
>requires only to delete an entry in a database of transactions to be
>watched.
>
>Implementing replacable funding transactions require an implementation
>to keep track of all versions of the funding transaction, as well as
>the state ("waiting for accept_channel", "waiting for funding_signed",
>"waiting for confirmation") of each funding transaction version. You
>would also link all those versions together - for example you might
>have a separate table containing an ID column that you allocate for
>each channel open attempt, and separate this from the funding
>transaction table (which would have a foreign key to the openings
>table). If one funding transaction confirms "deeply enough", then you
>send `funding_cancelled` for each other funding transaction.
>
>Note that the complexity here for replace-by-fee funding transactions
>is due solely to the fact that miners have the choice of mining any
>version of the transaction. It is possible that a miner deliberately
>chooses an older version, or (more realistically) that a race condition
>occurs where you broadcast the replacement but the miner has already
>won a block before the replacement propagated to it. Thus the funder
>(who initially owns all coins in the channel) needs to keep track of
>all versions of the funding transaction it broadcast, regardless. But
>of course it will want to not consume its own resources watching for
>transactions that can never confirm if another transaction has deeply
>confirmed, and it will delete such entries from its database; sending
>`funding_cancelled` in this case is simply "being nice", and the fundee
>ignores this at its own detriment, wasting resources each block to
>check for a transaction that logically can never confirm.
>
>In any case, how would you implement replace-by-fee funding
>transactions?
>
>Regards,
>ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
