📅 Original date posted:2018-01-14
📝 Original message:
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 <ZmnSCPxj at 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-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/20180115/18f95f71/attachment.html>;
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-09 12:48:26
in reply to nevent1q…gc6g
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-09 12:48:26Event JSON
{
"id": "3a3a107636b94f01122f0382e70b7aaafdccdf72970eac9636667bee4546d127",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686314906,
"kind": 1,
"tags": [
[
"e",
"2a4926c7999f60c613526723369cef244df2cc105602a16cdb8a4a5833ba7a81",
"",
"root"
],
[
"e",
"87d0db7bfec46159777a49f3991fac7661a4ee80a3613e8df1005b65a193705d",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-01-14\n📝 Original message:\nSounds 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.\"\n\nNote 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.\n\nGiven the relative simplicity on the receiving end, this could even be slipped in to the spec today prior to v1.1.\n\nCue bikeshedding.\n\nOn January 9, 2018 5:25:29 AM UTC, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003eGood morning Matt,\n\u003e\n\u003e\u003e -------- Original Message --------\n\u003e\u003e Subject: Re: [Lightning-dev] [1.1] Proposed `funding_cancelled`\n\u003emessage\n\u003e\u003e Local Time: January 8, 2018 10:42 PM\n\u003e\u003e UTC Time: January 8, 2018 2:42 PM\n\u003e\u003e From: lf-lists at mattcorallo.com\n\u003e\u003e To: ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e,\n\u003elightning-dev\\\\@lists.linuxfoundation.org\n\u003e\u003clightning-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e\n\u003e\u003e I have to say I'm rather not a fan of this idea. Adding messages\n\u003ewhich do not result in different node behavior other then waiting for\n\u003ethe timeout with little overhead on the node to simply keep watching\n\u003efor the funding transaction is a recipe for ending up with a needlessly\n\u003ecomplex protocol and misimplementation.\n\u003e\n\u003eThere is no specified timeout for funding transactions, and thus a\n\u003efundee node may keep track of funding transactions until end-of-life. \n\u003eThis is a concern since replaceable funding transactions require that\n\u003eall versions be monitored on the blockchain - there is always the\n\u003epossibility that the winning miner got older versions of the funding\n\u003etransaction.\n\u003e\n\u003eTo my mind, a sketch of an implementation for `funding_cancelled`\n\u003erequires only to delete an entry in a database of transactions to be\n\u003ewatched.\n\u003e\n\u003eImplementing replacable funding transactions require an implementation\n\u003eto keep track of all versions of the funding transaction, as well as\n\u003ethe state (\"waiting for accept_channel\", \"waiting for funding_signed\",\n\u003e\"waiting for confirmation\") of each funding transaction version. You\n\u003ewould also link all those versions together - for example you might\n\u003ehave a separate table containing an ID column that you allocate for\n\u003eeach channel open attempt, and separate this from the funding\n\u003etransaction table (which would have a foreign key to the openings\n\u003etable). If one funding transaction confirms \"deeply enough\", then you\n\u003esend `funding_cancelled` for each other funding transaction.\n\u003e\n\u003eNote that the complexity here for replace-by-fee funding transactions\n\u003eis due solely to the fact that miners have the choice of mining any\n\u003eversion of the transaction. It is possible that a miner deliberately\n\u003echooses an older version, or (more realistically) that a race condition\n\u003eoccurs where you broadcast the replacement but the miner has already\n\u003ewon a block before the replacement propagated to it. Thus the funder\n\u003e(who initially owns all coins in the channel) needs to keep track of\n\u003eall versions of the funding transaction it broadcast, regardless. But\n\u003eof course it will want to not consume its own resources watching for\n\u003etransactions that can never confirm if another transaction has deeply\n\u003econfirmed, and it will delete such entries from its database; sending\n\u003e`funding_cancelled` in this case is simply \"being nice\", and the fundee\n\u003eignores this at its own detriment, wasting resources each block to\n\u003echeck for a transaction that logically can never confirm.\n\u003e\n\u003eIn any case, how would you implement replace-by-fee funding\n\u003etransactions?\n\u003e\n\u003eRegards,\n\u003eZmnSCPxj\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180115/18f95f71/attachment.html\u003e",
"sig": "9561d362dee5e24b41e02fc79d9cc4b45d5a8e78b42606f681ed9dd460c544434d0b63742ec9c87c3569e415196fe00204ca436d31d8b29782548f3b95b9a59c"
}