📅 Original date posted:2015-11-19
📝 Original message:
Mats Jerratsch <matsjj at gmail.com> writes:
> 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.
Nice job! I've been saying there might be a way using keypairs, but I'm
just not this clever :)
Even then, it took me several reads to make sure I understood your post
:)
> 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
Yes, the two private keys are related by p...
> and
>
> R = r * G = ( p * q ) * G = p * ( q * G ) = p * Q.
...And if the two public keys are related by p, we know it's true. Thus
we know revealing their privkey will give us our privkey.
> 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
Or we could do an OP_FFMUL to do multiply over a finite field and check
the result, too:
<G> OP_FFMUL <PUBKEY> OP_EQUAL
With the segregated witness proposal, introducing new opcodes is easy,
so maybe someone would find a reason to prefer open-coding it like this?
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:45:03
in reply to nevent1q…5k8j
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:45:03Event JSON
{
"id": "1c781d249fd4bc45a5b6243b7dba8b64428987b90507804544a52c16256ae2b8",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314703,
"kind": 1,
"tags": [
[
"e",
"ebf410166f334c23aa8c4463788497d09c02fc7a472b5ea556de811c6970ae8b",
"",
"root"
],
[
"e",
"60e0c4b70d81b01dd83c609e4064e9bc3ebf9f97ed31ababde7e8e4107aac829",
"",
"reply"
],
[
"p",
"b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528"
]
],
"content": "📅 Original date posted:2015-11-19\n📝 Original message:\nMats Jerratsch \u003cmatsjj at gmail.com\u003e writes:\n\u003e After a night of sleep and some reassurance with sipa, I thought about\n\u003e something similar but with EC keys, that will allow us to do the same,\n\u003e but without SNARKS.\n\nNice job! I've been saying there might be a way using keypairs, but I'm\njust not this clever :)\n\nEven then, it took me several reads to make sure I understood your post\n:)\n\n\u003e If we would switch from preimage-hash verification to\n\u003e privatekey-publickey, we can use the arithmetic operations inherited\n\u003e from the elliptic curve field.\n\u003e\n\u003e Assume two keypairs, K1(Q, q) and K2(R, r). Further we have a scalar\n\u003e p, such that\n\u003e\n\u003e r = p * q\n\nYes, the two private keys are related by p...\n\n\u003e and\n\u003e\n\u003e R = r * G = ( p * q ) * G = p * ( q * G ) = p * Q.\n\n...And if the two public keys are related by p, we know it's true. Thus\nwe know revealing their privkey will give us our privkey.\n\n\u003e There is one caveat. We are currently unable to enforce a payment with\n\u003e a priv/pub key pair. We would need a new operator\n\u003e OP_CHECKPRIVPUBKEYPAIR or similar that pops two items from the stack\n\nOr we could do an OP_FFMUL to do multiply over a finite field and check\nthe result, too:\n\n \u003cG\u003e OP_FFMUL \u003cPUBKEY\u003e OP_EQUAL\n\nWith the segregated witness proposal, introducing new opcodes is easy,\nso maybe someone would find a reason to prefer open-coding it like this?\n\nCheers,\nRusty.",
"sig": "8ddae8547fbca41a68c443fd16152b1c5b9dae84f812938994deec993520abe84e36bb60233734f5cb585ed760de0dad8ceb6fc6c9cd2e22028ab7e49db1f2f0"
}