📅 Original date posted:2018-01-09
📝 Original message:
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-lists at mattcorallo.com
> To: ZmnSCPxj <ZmnSCPxj at protonmail.com>, lightning-dev\\@lists.linuxfoundation.org <lightning-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180109/993ca27d/attachment.html>;
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 12:48:26
in reply to nevent1q…rfdu
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:48:26Event JSON
{
"id": "87d0db7bfec46159777a49f3991fac7661a4ee80a3613e8df1005b65a193705d",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686314906,
"kind": 1,
"tags": [
[
"e",
"2a4926c7999f60c613526723369cef244df2cc105602a16cdb8a4a5833ba7a81",
"",
"root"
],
[
"e",
"9933d040e197d68dd9484a05361ee700e14ae2fef4271d5f15b7c7f8f6735537",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2018-01-09\n📝 Original message:\nGood morning Matt,\n\n\u003e -------- Original Message --------\n\u003e Subject: Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message\n\u003e Local Time: January 8, 2018 10:42 PM\n\u003e UTC Time: January 8, 2018 2:42 PM\n\u003e From: lf-lists at mattcorallo.com\n\u003e To: ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e, lightning-dev\\\\@lists.linuxfoundation.org \u003clightning-dev at lists.linuxfoundation.org\u003e\n\u003e\n\u003e 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.\n\nThere 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.\n\nTo my mind, a sketch of an implementation for `funding_cancelled` requires only to delete an entry in a database of transactions to be watched.\n\nImplementing 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.\n\nNote 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.\n\nIn any case, how would you implement replace-by-fee funding transactions?\n\nRegards,\nZmnSCPxj\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180109/993ca27d/attachment.html\u003e",
"sig": "0101dd6dfb3f5154128aa3f9adcbad72a843874b02cd9a83e23078bb425421a43e43c4871750cdbd52482d98b94294bfac657373e85459ba7eb0d4b5ae5a7ed5"
}