Good morning Rusty et al, > Matt Corallo [email protected] 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).
Mostly nitpick on terminology below, but I think text substantially like the above should exist in some kind of "rationale" section in the BOLT, so --- In light of dual-funding we should avoid "funder" and "fundee" in favor of "initiator" and "acceptor". However, we should also note that the substantial feature of turbo channels is ***not*** in channel opening per se, it is the *confirmation* of the channel. Once the opening ritual has completed and the funding tx broadcast, that is when turbo channels come in, so it actually does not matter which peer is "initiator" and which is "acceptor" at that point, the opening ritual has completed. Both peers, at the end of the opening ritual, have a valid commitment tx and both can double-spend the funds they put in to back out of the channel. So what matters for the above rationale is the "sender" of an HTLC and the "receiver" of an HTLC, not really who is acceptor or initiator. * Risks for HTLC sender is that the 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 HTLC receiver is that the channel never confirms, so HTLC must not be routed out to others or resolved locally if the receiver already knows the preimage, UNLESS the HTLC receiver has some *other* reason to trust the peer. Basically: * "funder" and "fundee" are legacy terms that predate dual-funding and are depreciated. In modern terms, the "funder" is the "initiator" and the "fundee" is the "acceptor", and in a legacy pre-dua-funding channel, only the initiator can start putting funds into the channel. * "initiator" is the peer that starts the opening process, and pays for the opening fees. * "acceptor" is the peer that is contacted by the initiator and decides whether to allow the creation of a channel with the initiator, and pays no opening fees. * "HTLC sender" is any peer that, *after* the channel opening completes (but possibly before it is locked in), offers an HTLC to the peer. * "HTLC receiver" is any peer that, *after* the channel opening completes (but possibly before it is locked in), is the one who accepts the HTLC from the HTLC sender. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
