> 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 <ru...@rustcorp.com.au> wrote: > Olaoluwa Osuntokun <laol...@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 <ru...@rustcorp.com.au> > wrote: > > > >> Christian Decker <decker.christ...@gmail.com> writes: > >> > >> > ZmnSCPxj via Lightning-dev <lightning-dev@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@lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > >> >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev