From aj at erisian.com.au Wed Feb 21 09:19:47 2018 From: aj at erisian.com.au (Anthony Towns) Date: Wed, 21 Feb 2018 19:19:47 +1000 Subject: [Lightning-dev] Proof of payment (Re: AMP: Atomic Multi-Path Payments over Lightning) In-Reply-To: References: <1518171320.5145.0.camel@ultimatestunts.nl> <87h8qmwohh.fsf@gmail.com> <87eflqw0aj.fsf@gmail.com> <9b84f100-172d-11ba-8440-12c2c9956698@bitonic.nl> Message-ID: <20180221091947.GA4644@erisian.com.au> On Tue, Feb 13, 2018 at 09:23:37AM -0500, ZmnSCPxj via Lightning-dev wrote: > Good morning Corne and Conner, > Ignoring the practical matters that Corne rightly brings up, I think, > it is possible to use ZKCP to provide a "stronger" proof-of-payment in > the sense that Conner is asking for. I think Schnorr scriptless scripts work for this (assuming HTLC payment hashes are ECC points rather than SHA256 hashes). In particular: - Alice agrees to pay Bob $5 for a coffee. - Bob calculates a lightning payment hash preimage r, and payment hash R=r*G. Bob also prepares a receipt message, saying "I've been paid $5 to give Alice a coffee", and calculates a partial Schnorr signature of this receipt (n a signature nonce, N=n*G, s=n+H(R+N,B,receipt)*b), and sends Alice (R, N, s) - Alice verfies the partial signature: s*G = N + H(R+N,B,receipt)*B - Alice pays over lightning conditional on receiving the preimage r of R. - Alice then has a valid signature of the receipt, signed by Bob: (R+N, r+s) The benefit over just getting a hash preimage, is that you can use this to prove that you paid Bob, rather than Carol or Dave, at some later date, including to a third party (a small-claims court, tax authorities, a KYC/AML audit?). The nice part is you get that just by doing some negotiation at the start, it's not something the lightning protocol needs to handle at all (beyond switching to ECC points for payment hashes). > -------- Original Message -------- > On February 13, 2018 10:33 AM, Corn? Plooy via Lightning-dev wrote: > >Hi Conner, > > I do believe proof of payment is an important feature to have, > > especially for the use case of a payer/payee pair that doesn't > > completely trust each other, but does have the possibility to go to court. Cheers, aj