From rusty at rustcorp.com.au Thu Jul 5 00:07:44 2018 From: rusty at rustcorp.com.au (Rusty Russell) Date: Thu, 05 Jul 2018 09:37:44 +0930 Subject: [Lightning-dev] Including a Protocol for splicing to BOLT In-Reply-To: References: <87efgmh5ob.fsf@rustcorp.com.au> <87y3esigat.fsf@gmail.com> <878t6r3638.fsf@rustcorp.com.au> Message-ID: <87po021r5b.fsf@rustcorp.com.au> 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 >>