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

Olaoluwa Osuntokun laolu32 at gmail.com
Thu Jul 5 04:30:22 UTC 2018


> Was referring to losing proof-of-payment; that's vital in a system without
> intermediaries.  We have to decide what the lesser evil is.

As is now, we don't have a proper proof of payment. We have a "proof that
someone paid". A proper proof of payment would be: "proof that bob paid
carol".
Aside from that, spontaneous payments is amongst the most request feature
request I get from users and developers.

There're a few ways to achieve this with dlog based AMPs.

As far hash based AMPs, with a bit more interaction, and something like
zkboo,
one can achieve stronger binding. However, we'd lose the nice "one shot"
property that dlog based AMPs allow.

> And yeah, I called it Schnorr-Eltoonicorn not only because it's sooooo
> pretty, but because actually capturing it will be a saga.

eltoo won't be the end-all-be-all as it comes along with several tradeoffs,
like everything else does.

Also, everything we can do with Schnorr, we can also do with ECDSA, but
today.

-- Laolu


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

> Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> > What's the nasty compromise?
> >
> > Let's also not underestimate how big of an update switching to dlog based
> > HTLCs will be.
>
> Was referring to losing proof-of-payment; that's vital in a system
> without intermediaries.  We have to decide what the lesser evil is.
>
> And yeah, I called it Schnorr-Eltoonicorn not only because it's sooooo
> pretty, but because actually capturing it will be a saga.
>
> Cheers,
> Rusty.
>
> > 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/27c23619/attachment-0001.html>


More information about the Lightning-dev mailing list