Re: [Lightning-dev] Turbo channels spec?
Good morning Rusty, > ZmnSCPxj zmnsc...@protonmail.com writes: > > > 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". > > Yes, Lisa has a patch for this in her spec PR :) > > > 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. > > This misses an important case: even with the dual-funding prototol, > single-sided funding is more common. > > So: > > - if your peer hasn't contributed funds: > - You are in control, channel is safe (modulo your own conf issues) Hmm. In single-funding, if you sent out an HTLC, got the preimage, then now your peer has funds in the channel. If you do this before the channel confirms, then the peer can send to you, and you can accept it safely without concern since your peer cannot block the channel confirmation. So yes, it seems correct. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Turbo channels spec?
Sorry this took so long. https://github.com/lightningnetwork/lightning-rfc/pull/895 This changed quite a bit, based on discussion here and more coherent thinking. 1. You can simply send funding_locked early, no feature needed. 2. It's a bit useless unless you are the (sole) funder or you trust the other side. Without that, you can neither accept payments nor route them; in theory if they used push_msat you could send payments out, but that seems a niche case. 3. We do want to know the short_channel_id they're going to use for the channel, so we can add it to routehints for incoming payments. Adding the scid is nice anyway, for chainsplit scenarios. Here is the new text, a little formatted: 1. `tlv_stream`: `funding_locked_tlvs` 2. types: 1. type: 1 (`short_channel_id`) 2. data: * [`short_channel_id`:`short_channel_id`] Requirements The sender: ... - SHOULD set `short_channel_id` - if it is the sole contributor to the funding transaction, or has reason to trust the peer: - MAY send `funding_locked` before the funding transaction has reached `minimum_depth` - MAY set `short_channel_id` to a fake value, if it will route payments to that `short_channel_id`. - otherwise: - MUST wait until the funding transaction has reached `minimum_depth` before sending this message. - SHOULD re-transmit `funding_locked` if the `short_channel_id` for this chanel has changed. ... The receiver: - SHOULD ignore the `funding_locked` if it knows the `short_channel_id` of the channel and it differs from the value in `funding_locked`. ... Nodes which have funded the channel or trust their peers to have done, can simply start using the channel instantly by sending `funding_locked`. This raises the problem of how to use this new channel in route hints, since it does not yet have a block number. For this reason, a convincing fake number can be use; when the real funding transaction is finally mined, it can re-send `funding_locked` with the real value. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Turbo channels spec?
Hi guys, happy to see this being discussed again! When I came up with the idea, it was originally intended for cases when there's an inherently trusted exchange, such as trading fiat for sats using an ATM. In this scenario only the push amount was spendable. Receiving more on top of that was disabled. Since then some implementations have made zero-conf channels fully operational. While strictly worse security, I'm not against it. I'd just really, really like to have these cases distinguished. So I think we need one more bit to signal whether it's only push being zeroconf or the channel is fully zeroconf. Cheers, Martin ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Turbo channels spec?
ZmnSCPxj writes: > 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". Yes, Lisa has a patch for this in her spec PR :) > 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. This misses an important case: even with the dual-funding prototol, single-sided funding is more common. So: - if your peer hasn't contributed funds: - You are in control, channel is safe (modulo your own conf issues) - if the peer has contributed funds: - You can send, since cancellation just gives you a free refund (if you contributed anything at all). - You should not route an incoming HTLCs (unless you trust peer) Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Turbo channels spec?
Good morning Rusty et al, > Matt Corallo lf-li...@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). 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 Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Turbo channels spec?
Matt Corallo 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. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Turbo channels spec?
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. 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel unless they have explicit reason to trust that node (they can still send *out* that channel, because that's not their problem!). It's a pretty simple change, TBH (this zeroconf feature would also create a new set of channel_types, altering that PR). I can draft something this week? Thanks! Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Turbo channels spec?
> > - MUST NOT send `announcement_signatures` messages until `funding_locked` > has been sent and received AND the funding transaction has at least > six confirmations. > > So still compliant there? > Great, I hadn't spotted that one, so we're good on the `announcement_signatures` side. I'm wondering if `option_zeroconf` implies that we should set `min_depth = 0` in `accept_channel`, since that's the number of confirmations before we can send `funding_locked`. We need a signal that this channel uses zero-conf, and the two obvious choices are: - set `min_depth = 0` - use a `channel_type` that sets `option_zeroconf` I think the second option is better, this way we can keep a "normal" `min_depth` set and when we send `funding_locked`, we know that the channel is now perfectly safe to use (out of the zero-conf zone). Cheers, Bastien Le mer. 30 juin 2021 à 02:09, Rusty Russell a écrit : > Bastien TEINTURIER writes: > > Hi Rusty, > > > > On the eclair side, we instead send `funding_locked` as soon as we > > see the funding tx in the mempool. > > > > But I think your proposal would work as well. > > This would be backward compatible, I think. Eclair would send > `funding_locked`, which is perfectly legal, but a normal peer would > still wait for confirms before also sending `funding_locked`; it's > just that option_zeroconf_channels would mean it doesn't have to > wait for that before sending HTLCs? > > > We may want to defer sending `announcement_signatures` until > > after the funding tx has been confirmed? What `min_depth` should > > we use here? Should we keep a non-zero value in `accept_channel` > > or should it be zero? > > You can't send it before you know the channel_id, so it has to be at > least 1. Spec says: > > - MUST NOT send `announcement_signatures` messages until > `funding_locked` > has been sent and received AND the funding transaction has at least > six confirmations. > > So still compliant there? > > Cheers, > Rusty. > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Turbo channels spec?
Bastien TEINTURIER writes: > Hi Rusty, > > On the eclair side, we instead send `funding_locked` as soon as we > see the funding tx in the mempool. > > But I think your proposal would work as well. This would be backward compatible, I think. Eclair would send `funding_locked`, which is perfectly legal, but a normal peer would still wait for confirms before also sending `funding_locked`; it's just that option_zeroconf_channels would mean it doesn't have to wait for that before sending HTLCs? > We may want to defer sending `announcement_signatures` until > after the funding tx has been confirmed? What `min_depth` should > we use here? Should we keep a non-zero value in `accept_channel` > or should it be zero? You can't send it before you know the channel_id, so it has to be at least 1. Spec says: - MUST NOT send `announcement_signatures` messages until `funding_locked` has been sent and received AND the funding transaction has at least six confirmations. So still compliant there? Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Turbo channels spec?
Thanks for instigating this, Rusty! 0conf/turbo channels have been hackable for a long time, and we would love to unlock new user experiences for our platforms with it, formally if possible. 0conf is desired by every wallet, every LN exchange, and truly shows off something only LN can uniquely offer as a UX. We are happy to support how we can, and answer any questions from the trenches. On Tue, Jun 29, 2021 at 8:34 AM 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. > 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel >unless they have explicit reason to trust that node (they can still >send *out* that channel, because that's not their problem!). > > It's a pretty simple change, TBH (this zeroconf feature would also > create a new set of channel_types, altering that PR). > > I can draft something this week? > > Thanks! > Rusty. > -- ~ John Carvalho Schedule: https://calendly.com/bitcoinerrorlog Chat: https://t.me/bitcoinerrorlog Social: https://twitter.com/bitcoinerrorlog ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Turbo channels spec?
Hi Rusty, On the eclair side, we instead send `funding_locked` as soon as we see the funding tx in the mempool. But I think your proposal would work as well. We may want to defer sending `announcement_signatures` until after the funding tx has been confirmed? What `min_depth` should we use here? Should we keep a non-zero value in `accept_channel` or should it be zero? Cheers, Bastien Le mar. 29 juin 2021 à 07:34, Rusty Russell a écrit : > 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. > 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel >unless they have explicit reason to trust that node (they can still >send *out* that channel, because that's not their problem!). > > It's a pretty simple change, TBH (this zeroconf feature would also > create a new set of channel_types, altering that PR). > > I can draft something this week? > > Thanks! > Rusty. > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Turbo channels spec?
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. 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel unless they have explicit reason to trust that node (they can still send *out* that channel, because that's not their problem!). It's a pretty simple change, TBH (this zeroconf feature would also create a new set of channel_types, altering that PR). I can draft something this week? Thanks! Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
