Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-04 📝 Original message: Matt Corallo <lf-lists at ...
📅 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.
📝 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.