{"type":"rich","version":"1.0","title":"Matt Corallo [ARCHIVE] wrote","author_name":"Matt Corallo [ARCHIVE] (npub1e4…jxmcu)","author_url":"https://yabu.me/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-07-01\n📝 Original message:\nThanks!\n\nOn 6/29/21 01:34, Rusty Russell wrote:\n\u003e Hi all!\n\u003e \n\u003e          John Carvalo recently pointed out that not every implementation\n\u003e accepts zero-conf channels, but they are useful.  Roasbeef also recently\n\u003e noted that they're not spec'd.\n\u003e \n\u003e How do you all do it?  Here's a strawman proposal:\n\u003e \n\u003e 1. Assign a new feature bit \"I accept zeroconf channels\".\n\u003e 2. If both negotiate this, you can send update_add_htlc (etc) *before*\n\u003e     funding_locked without the peer getting upset.\n\nDoes it make sense to negotiate this per-direction in the channel init message(s)? There's a pretty different threat \nmodel between someone spending a dual-funded or push_msat balance vs someone spending a classic channel-funding balance.\n\n\u003e 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel\n\u003e     unless they have explicit reason to trust that node (they can still\n\u003e     send *out* that channel, because that's not their problem!).\n\u003e \n\u003e It's a pretty simple change, TBH (this zeroconf feature would also\n\u003e create a new set of channel_types, altering that PR).\n\u003e \n\u003e I can draft something this week?\n\u003e \n\u003e Thanks!\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e"}