From rusty at rustcorp.com.au Sun Jul 8 06:38:38 2018 From: rusty at rustcorp.com.au (Rusty Russell) Date: Sun, 08 Jul 2018 16:08:38 +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> <87po021r5b.fsf@rustcorp.com.au> Message-ID: <87muv2z0y9.fsf@rustcorp.com.au> Olaoluwa Osuntokun writes: >> 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". Hi Laolu! I consider that proof-of-payer, which would be great. proof-of-payment (though ours is trivially forgable by the payee) is useful for the common case of "I paid, and you never shipped me my widget!" arguments (assuming description is invoice is useful, such as containing shipping address). Our network of early adopters with no significant malicious players will not last, regrettably. > Aside from that, spontaneous payments is amongst the most request feature > request I get from users and developers. But they're terrible for anything but donations. Businesses do *not* want people to get into the habit of resuing old invoices (even if we used dlog methods so it wasn't massively broken). push-payments was one of the first support headaches we had at the Blockstream Store, and I'm not eager to repeat it. At least in that case we knew where to return the funds! To be clear: (opt-in) reusable invoices are vital. But it's still part of an 'invoice -> pay' flow (though with the pay step repeated). >> 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. I somewhat agree that it has caveats, but it'll improve things significantly against what we have today. > Also, everything we can do with Schnorr, we can also do with ECDSA, but > today. True. But it should be much easier... Cheers, Rusty.