Bitcoin Error Log [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-29 📝 Original message: Thanks for instigating ...
📅 Original date posted:2021-06-29
📝 Original message:
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>
📝 Original message:
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>