Mats Jerratsch [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-19 📝 Original message: Interesting, thanks for ...
📅 Original date posted:2015-11-19
📝 Original message:
Interesting, thanks for the write-up Anthony!
Indeed, if we can somehow prove that R1 = R2 XOR X without revealing
R1 or R2, we can switch R in between the routing an arbitrary amount
of time. This would solve the last obvious privacy attack vector that
we have currently.
I feel like the way ZKPs are constructed, one has to be absolutely
certain everything is perfectly implemented to actually work out the
way we want it.
> A drawback is that you'd either (a) have to do all this on the merchant's
> side (not just sending SHA(R) to whoever wants to pay you, but sending
> SHA(R1), SHA(R2), SHA(R3), SHA(R4), X12, X23, X34, and three proofs,
> which would be pretty painful; or (b) you'd have to generate all the
> R secrets as a consumer, and you wouldn't get to use the fact that you
> know R as evidence that you paid the merchant.
I don't think (a) would be too much of a problem. I am playing around
with the idea of having a messaging system over the same route as the
actual payment. The data that needs to be communicated over regular
channels (QR, ...) would be limited to a rendezvous node and the
encrypted route from that node to the receiver. The sender can contact
the receiver over that route and include the encrypted route back for
further communications.
I also think that - given how young SNARKs still are - efficiency will
further be improved. Especially generation and verification of the
proof, such that it is no longer a major cost factor.
---------------
After a night of sleep and some reassurance with sipa, I thought about
something similar but with EC keys, that will allow us to do the same,
but without SNARKS.
If we would switch from preimage-hash verification to
privatekey-publickey, we can use the arithmetic operations inherited
from the elliptic curve field.
Assume two keypairs, K1(Q, q) and K2(R, r). Further we have a scalar
p, such that
r = p * q
and
R = r * G = ( p * q ) * G = p * ( q * G ) = p * Q.
You can therefore give someone Q, R and p and he is able to verify
that above conditions indeed holds true. For a sufficiently large p it
is not possible to derive that relationship within reasonable time
without p. If he ever gets to know q, he is able to directly compute r
as well.
So instead of making a payment towards a hash, we make a payment
towards a public key. If we ever get to know the private key, the
payment is deemed settled.
This will allow for following construction:
(1) Bob calculates a key pair he wants to receive a payment on
(2) Bob will give the public key Q to Alice
(3) Alice calculates a route, consisting of 10 hops
(4) Alice chooses x random large numbers N_x and calculates x public
keys, such that
Q_y = Q * N_x * N_x-1 * ... * N_y.
(5) Alice constructs an onion object and includes Q_y together with N_y
Each hop is able to translate the public key towards the corresponding
key for the next relay node, only Alice, with the knowledge of the set
N is able to relate the payment though.
There is one caveat. We are currently unable to enforce a payment with
a priv/pub key pair. We would need a new operator
OP_CHECKPRIVPUBKEYPAIR or similar that pops two items from the stack
<Private Key> <Public Key>
and replaces them with true/false. It could also be constructed in a
softfork-manner, where the stack is not touched and it only fails in
case the key pair is not correct.
Revealing the private key has the same effect as revealing a preimage.
Cheers
Mats
Published at
2023-06-09 12:45:02Event JSON
{
"id": "60e0c4b70d81b01dd83c609e4064e9bc3ebf9f97ed31ababde7e8e4107aac829",
"pubkey": "b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528",
"created_at": 1686314702,
"kind": 1,
"tags": [
[
"e",
"ebf410166f334c23aa8c4463788497d09c02fc7a472b5ea556de811c6970ae8b",
"",
"root"
],
[
"e",
"7ec5ac527de989b2fdd8978d7d72473439189ad717f77e00451ac75e33ce5b38",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2015-11-19\n📝 Original message:\nInteresting, thanks for the write-up Anthony!\n\nIndeed, if we can somehow prove that R1 = R2 XOR X without revealing\nR1 or R2, we can switch R in between the routing an arbitrary amount\nof time. This would solve the last obvious privacy attack vector that\nwe have currently.\n\nI feel like the way ZKPs are constructed, one has to be absolutely\ncertain everything is perfectly implemented to actually work out the\nway we want it.\n\n\u003e A drawback is that you'd either (a) have to do all this on the merchant's\n\u003e side (not just sending SHA(R) to whoever wants to pay you, but sending\n\u003e SHA(R1), SHA(R2), SHA(R3), SHA(R4), X12, X23, X34, and three proofs,\n\u003e which would be pretty painful; or (b) you'd have to generate all the\n\u003e R secrets as a consumer, and you wouldn't get to use the fact that you\n\u003e know R as evidence that you paid the merchant.\n\nI don't think (a) would be too much of a problem. I am playing around\nwith the idea of having a messaging system over the same route as the\nactual payment. The data that needs to be communicated over regular\nchannels (QR, ...) would be limited to a rendezvous node and the\nencrypted route from that node to the receiver. The sender can contact\nthe receiver over that route and include the encrypted route back for\nfurther communications.\n\nI also think that - given how young SNARKs still are - efficiency will\nfurther be improved. Especially generation and verification of the\nproof, such that it is no longer a major cost factor.\n\n---------------\n\nAfter a night of sleep and some reassurance with sipa, I thought about\nsomething similar but with EC keys, that will allow us to do the same,\nbut without SNARKS.\n\nIf we would switch from preimage-hash verification to\nprivatekey-publickey, we can use the arithmetic operations inherited\nfrom the elliptic curve field.\n\nAssume two keypairs, K1(Q, q) and K2(R, r). Further we have a scalar\np, such that\n\nr = p * q\n\nand\n\nR = r * G = ( p * q ) * G = p * ( q * G ) = p * Q.\n\nYou can therefore give someone Q, R and p and he is able to verify\nthat above conditions indeed holds true. For a sufficiently large p it\nis not possible to derive that relationship within reasonable time\nwithout p. If he ever gets to know q, he is able to directly compute r\nas well.\n\nSo instead of making a payment towards a hash, we make a payment\ntowards a public key. If we ever get to know the private key, the\npayment is deemed settled.\n\nThis will allow for following construction:\n\n(1) Bob calculates a key pair he wants to receive a payment on\n(2) Bob will give the public key Q to Alice\n(3) Alice calculates a route, consisting of 10 hops\n(4) Alice chooses x random large numbers N_x and calculates x public\nkeys, such that\n\nQ_y = Q * N_x * N_x-1 * ... * N_y.\n\n(5) Alice constructs an onion object and includes Q_y together with N_y\n\nEach hop is able to translate the public key towards the corresponding\nkey for the next relay node, only Alice, with the knowledge of the set\nN is able to relate the payment though.\n\nThere is one caveat. We are currently unable to enforce a payment with\na priv/pub key pair. We would need a new operator\nOP_CHECKPRIVPUBKEYPAIR or similar that pops two items from the stack\n\n\u003cPrivate Key\u003e \u003cPublic Key\u003e\n\nand replaces them with true/false. It could also be constructed in a\nsoftfork-manner, where the stack is not touched and it only fails in\ncase the key pair is not correct.\n\nRevealing the private key has the same effect as revealing a preimage.\n\nCheers\nMats",
"sig": "f2a17a897f699ef5e76a38317fc0c3b35f27ec63af0b8925a5a7362a278ca9ec8d17fc3b01356997a4420f055437908a164f945873866b0d2ef112276187891f"
}