From bitcoinerrorlog at gmail.com  Tue Jun 29 07:53:23 2021
From: bitcoinerrorlog at gmail.com (Bitcoin Error Log)
Date: Tue, 29 Jun 2021 10:53:23 +0300
Subject: [Lightning-dev] Turbo channels spec?
In-Reply-To: <871r8lcjz9.fsf@rustcorp.com.au>
References: <871r8lcjz9.fsf@rustcorp.com.au>
Message-ID: <CAE2fw6u-5=HgYcHA0biWqDd9JjUsJYx7qA7PP-voRzSwnKLKgA@mail.gmail.com>

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 <rusty at rustcorp.com.au> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210629/9dd76388/attachment.html>