📅 Original date posted:2021-07-04
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> Thanks!
>
> On 6/29/21 01:34, Rusty Russell wrote:
>> Hi all!
>>
>> John Carvalo recently pointed out that not every implementation
>> accepts zero-conf channels, but they are useful. Roasbeef also recently
>> noted that they're not spec'd.
>>
>> How do you all do it? Here's a strawman proposal:
>>
>> 1. Assign a new feature bit "I accept zeroconf channels".
>> 2. If both negotiate this, you can send update_add_htlc (etc) *before*
>> funding_locked without the peer getting upset.
>
> Does it make sense to negotiate this per-direction in the channel init message(s)? There's a pretty different threat
> model between someone spending a dual-funded or push_msat balance vs someone spending a classic channel-funding balance.
channel_types fixes this :)
Until then, I'd say keep it simple. I would think that c-lightning will
implement the "don't route from non-locked-in channels" and always
advertize this option. That means we're always offering zero-conf
channels, but that seems harmless:
- Risks for funder is that channel never confirms, but it probably ignores
the risk because it can close onchain (annoying, and fee-heavy, but not
loss of funds caused by peer).
- Risks for fundee (or DF channels where peer contributes any funds) is
that funder doublespends, so HTLCs must not be routed out to others
(unless you have other reason to trust peer).
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 13:03:00
in reply to nevent1q…ysgt
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 13:03:00Event JSON
{
"id": "687b4ae413dcfe0aafab79903b20f51ad2869db0eb2bfbdd4e2120b4b7d0f715",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315780,
"kind": 1,
"tags": [
[
"e",
"5b939faaa8b1530f86472b2f9c4dc55b9f8dea6f71ca80ce3563af20d2a12ae1",
"",
"root"
],
[
"e",
"9ddadc9dfc0a085fafba10da880e1b7b830d6eff8f554986153a1ad334b1f998",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2021-07-04\n📝 Original message:\nMatt Corallo \u003clf-lists at mattcorallo.com\u003e writes:\n\u003e Thanks!\n\u003e\n\u003e On 6/29/21 01:34, Rusty Russell wrote:\n\u003e\u003e Hi all!\n\u003e\u003e \n\u003e\u003e John Carvalo recently pointed out that not every implementation\n\u003e\u003e accepts zero-conf channels, but they are useful. Roasbeef also recently\n\u003e\u003e noted that they're not spec'd.\n\u003e\u003e \n\u003e\u003e How do you all do it? Here's a strawman proposal:\n\u003e\u003e \n\u003e\u003e 1. Assign a new feature bit \"I accept zeroconf channels\".\n\u003e\u003e 2. If both negotiate this, you can send update_add_htlc (etc) *before*\n\u003e\u003e funding_locked without the peer getting upset.\n\u003e\n\u003e Does it make sense to negotiate this per-direction in the channel init message(s)? There's a pretty different threat \n\u003e model between someone spending a dual-funded or push_msat balance vs someone spending a classic channel-funding balance.\n\nchannel_types fixes this :)\n\nUntil then, I'd say keep it simple. I would think that c-lightning will\nimplement the \"don't route from non-locked-in channels\" and always\nadvertize this option. That means we're always offering zero-conf\nchannels, but that seems harmless:\n\n- Risks for funder is that channel never confirms, but it probably ignores\n the risk because it can close onchain (annoying, and fee-heavy, but not\n loss of funds caused by peer).\n\n- Risks for fundee (or DF channels where peer contributes any funds) is\n that funder doublespends, so HTLCs must not be routed out to others\n (unless you have other reason to trust peer).\n\nCheers,\nRusty.",
"sig": "49be9c5a0a6d9a9720d7e7b92d84ac36eaf7fa085877dea95cf75da4e2d2898765a3c13893278e0122e0c7fcd9ffd3abc22b28c8b89832085e073c3192079ed9"
}