<oembed><type>rich</type><version>1.0</version><title>Rusty Russell [ARCHIVE] wrote</title><author_name>Rusty Russell [ARCHIVE] (npub1zw…hkhpx)</author_name><author_url>https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx</author_url><provider_name>njump</provider_name><provider_url>https://yabu.me</provider_url><html>📅 Original date posted:2021-06-29&#xA;📝 Original message:&#xA;Hi all!&#xA;&#xA;        John Carvalo recently pointed out that not every implementation&#xA;accepts zero-conf channels, but they are useful.  Roasbeef also recently&#xA;noted that they&#39;re not spec&#39;d.&#xA;&#xA;How do you all do it?  Here&#39;s a strawman proposal:&#xA;&#xA;1. Assign a new feature bit &#34;I accept zeroconf channels&#34;.&#xA;2. If both negotiate this, you can send update_add_htlc (etc) *before*&#xA;   funding_locked without the peer getting upset.&#xA;3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel&#xA;   unless they have explicit reason to trust that node (they can still&#xA;   send *out* that channel, because that&#39;s not their problem!).&#xA;&#xA;It&#39;s a pretty simple change, TBH (this zeroconf feature would also&#xA;create a new set of channel_types, altering that PR).&#xA;&#xA;I can draft something this week?&#xA;&#xA;Thanks!&#xA;Rusty.</html></oembed>