From laolu32 at gmail.com Thu Jul 5 04:30:22 2018 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Wed, 4 Jul 2018 23:30:22 -0500 Subject: [Lightning-dev] Including a Protocol for splicing to BOLT In-Reply-To: <87po021r5b.fsf@rustcorp.com.au> References: <87efgmh5ob.fsf@rustcorp.com.au> <87y3esigat.fsf@gmail.com> <878t6r3638.fsf@rustcorp.com.au> <87po021r5b.fsf@rustcorp.com.au> Message-ID: > 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 wrote: > Olaoluwa Osuntokun 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 > wrote: > > > >> Christian Decker writes: > >> > >> > ZmnSCPxj via Lightning-dev > >> 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: