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 <ru...@rustcorp.com.au> 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
