[Lightning-dev] Including a Protocol for splicing to BOLT

[Olaoluwa Osuntokun]

What's the nasty compromise?

Let's also not underestimate how big of an update switching to dlog based
HTLCs will be.

On Wed, Jul 4, 2018, 4:21 PM Rusty Russell <rusty at rustcorp.com.au> wrote:

> Christian Decker <decker.christian at gmail.com> writes:
>
> > ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
> writes:
> >> For myself, I think splice is less priority than AMP. But I prefer an
> >> AMP which retains proper ZKCP (i.e. receipt of preimage at payer
> >> implies receipt of payment at payee, to facilitate trustless
> >> on-to-offchain and off-to-onchain bridges).
> >
> > Agreed, multipath routing is a priority, but I think splicing is just as
> > much a key piece to a better UX, since it allows to ignore differences
> > between on-chain and off-chain funds, showing just a single balance for
> > all use-cases.
>
> Agreed, we need both.  Multi-channel was a hack because splicing doesn't
> exist, and I'd rather not ever have to implement multi-channel :)
>
> AMP is important, but it's a nasty compromise with the current
> limitations.  I want to have my cake and eat it too, and I'm pretty sure
> it's possible once the Scnorr-Eltoonicorn arrives.
>
> Cheers,
> 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/20180704/f422b9e3/attachment.html>