rich1.0Bastien TEINTURIER [ARCHIVE] (npub17f…ntr0s)https://yabu.me/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0snjumphttps://yabu.me📅 Original date posted:2021-06-29 📝 Original message: 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 <rusty at 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 at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210629/a9f7eb76/attachment.html>