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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
