From ZmnSCPxj at protonmail.com Tue Sep 21 11:40:37 2021 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Tue, 21 Sep 2021 11:40:37 +0000 Subject: [Lightning-dev] Stateless invoices with proof-of-payment In-Reply-To: References: Message-ID: Good morning again Joost, > However, we can do "pay for signature" protocols using PTLCs, and rather than requesting for a scalar behind a point as the proof-of-payment, we can instead ask for a signature of a message that attests "this recipient got paid `payment_amount` with `encoded_order_details`" and have a recipient pubkey (not necessarily the node key, it might be best to reduce signing for node keys) as the signing key. > > So it seems to me that this cannot work with hashes, but can work with PTLCs if we use pay-for-signature and the proof-of-payment is a signature rather than a scalar. No, it does not work either. The reason is that for signing, we need an `R` as well. Typically, this is a transient keypair generated by the signer as `r = rand(); R = r * G`. In order to set up a pay-for-signature, the sender needs to know an `R` from the recipient, and the recipient, being the signer, has to generate that `R` for itself. And if you are just going to do something like sender->request->receiver, receiver->R->sender, and *then* do the sender->PTLC->receiver, then you might as well just do sender->request->receiver, receiver->invoice->sender, sender->PTLC->receiver. I think your goal, as I understand it, is to reduce it to one round, i.e. sender->PTLC+some_data->receiver, then receiver responds to the PTLC that somehow generates the proof-of-payment. Is my understanding correct? We cannot have the sender generate the `r` and `R = r * G` as knowledge of `r`, `s` and the signed message `m` results in learning the privkey `a`: s = r - a * h(R | m) a = (r - s) / h(R | m) Even with MuSig2 we need a separate round for `R` establishment before the round where everyone gives shares of `s`, and one can argue that a proof-of-payment, being an agreement of the sender and a receiver, is semantically equivalent to a 2-of-2 signature of both sender and the receiver signing off on the fact that the payment happened. Thus, it seems to me that we can adapt any *secure* single-round multisignature Schnorr scheme to this problem of needing a single-round pay-for-signature. Perhaps another mechanism? WARNING: THIS IS NOVEL CRYPTOGRAPHY I THOUGHT UP IN FIVE MINUTES AND I AM NOT A CRYPTOGRAPHER, DO NOT ROLL YOUR OWN CRYPTO. Instead of having a single receiver-scalar, the receiver knows two scalars. A = a * G B = b * G The sender knows both `A` and `B`. Now, suppose sender wants to make a payment to the receiver. At its simplest, the sender can simply add `A + B` and lock an outgoing PTLC to that point. The proof-of-payment is the sum `a + b`, but knowledge of this sum does not imply knowledge of either `a` or `b` (I THINK --- I AM NOT A CRYPTOGRAPHER). Now, suppose we want a proof-of-payment to be keyed to some data. We can translate that data to a scalar (e.g. just hash it) and call it `d`. Then the sender makes a payment to the receiver using this point: d * A + B The sender then receives the scalar behind the above point: d * a + b Even with knowledge of `d`, the sender cannot learn either `a` or `b` and thus cannot synthesize any other proof-of-payment with a different `d`, thus "locking" the proof-of-payment to a specific `d`. The above proof-of-payment is sufficient by showing the point `d * A + B`, the committed data `d`, and the receiver public keys `A` and `B`. AGAIN THIS IS NOVEL CRYPTOGRAPHY I THOUGHT UP IN FIVE MINUTES AND I AM NOT A CRYPTOGRAPHER, THIS NEEDS ACTUAL MATHEMATICAL REVIEW FROM AN ACTUAL CRYPTOGRAPHER. Regards, ZmnSCPxj