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
