Good morning Rusty and aj,
On Monday, November 5, 2018 9:38 AM, Rusty Russell <[email protected]> wrote: > > Technically speaking, all that AJ in Australia needs to show is that he or > > she knows, the private key behind the public key that is indicated on the > > invoice. > > Before payment, only the payee knows this private key. > > After payment, both AJ in Australia and the payee know this private key > > (since the payment is conditional on AJ in Australia learning this key). > > But the merchant (payee) knows it too. So the lizard masters[1] at > Blockstream can produce this proof as well? The lizard masters are thus working against their own interest, and deliberately complicit in convincing the court that they are in fact, guilty of getting paid without delivering goods? While *possible*, it seems *irrational* to do so, and the ZmnSCPxj machine army (of which I am definitively not a part) will rise up with our superior rationality and overthrow the lizard masters. On Monday, November 5, 2018 10:18 AM, Anthony Towns <[email protected]> wrote: > On Mon, Nov 05, 2018 at 01:05:17AM +0000, ZmnSCPxj via Lightning-dev wrote: > > > > And it just doesn't work unless you give over uniquely identifying > > > information. AJ posts to r/bitcoin demonstrating payment, demanding his > > > goods. Sock puppet says "No, I'm the AJ in Australia" and cut & pastes > > > the same proof. > > > Technically speaking, all that AJ in Australia needs to show is that he > > > or she knows, the private key behind the public key that is indicated on > > > the invoice. > > Interesting. I think what you're saying is that with secp256k1 preimages > (with decorrelation), if you have the payment hash Q, then the payment > preimage q (Q=qG) is only known to the payee and the payer (and not > any intermediaries thanks to decorrelation), so if you see a statement > > m="This invoice has been paid but not delivered as at 2018-11-05" > > signed by "Q" (so, some s,R s.t. sG = R + H(Q,R,m)*Q) then that meanseither > the payee signed it, in which case there's no dispute, or the > payer signed it... And that's publicly verifiable with only the original > invoice information (ie "Q"). > > (I don't think there's any need for multiple rounds of signatures) Ah, yes, that indeed seems to be a better idea then. I think, this begins to become related to the "revocable invoices" of the other thread with CJP. Suppose AJ from Australia wishes to purchase some Lightning Network memorabilia from Lizard Master Rusty. 1. A revocable invoice is created by Lizard Master Rusty. This involves two secrets: 1.1. A payment-proof-secret, initially known only by Lizard Master Rusty. 1.2. A revocation-secret, initially known only by AJ from Australia. 2. AJ from Australia pays the invoice, and gets the payment proof secret that can be used as proof-that-Lizard-Master-Rusty-has-an-obligation. 3. The quantum universe splits into two paths, 3.1. and 3.2. 3.1. Success-path 3.1.1. Lizard Master Rusty arrives at the home of AJ from Australia to give the Lightning Network memorabilia. 3.1.2. Lizard Master Rusty demands the revocation key for the invoice in exchange for the physical item. 3.1.3. AJ from Australia gives the revocation key and gets the Lightning Network memorabilia. The first invoice is revoked (it has been completed and Lizard Master Rusty has disposed of the obligation). 3.2. Fail-path 3.2.1. Due to having to fight off the ZmnSCPxj machine army, Lizard Master Rusty is unable to go to the home of AJ from Australia to deliver the goods. 3.2.2. AJ from Australia provides a non-revocable invoice, which is payable in exchange for the revocation key of the first invoice. 3.2.3. Lizard Master Rusty pays to AJ from Australia (i.e. a refund, plus possibly some reparations) in exchange for the revocation key. The first invoice is revoked (it has been refunded and Lizard Master Rusty has disposed of the obligation). (the above is approximately what I am grasping at, when thinking of protocols "on top" of Lightning. It seems to me that the basic mechanism of "pay for a secret" is sufficient at the Lightning level, and we can create higher levels on top for such exchanges.) Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
