What is Nostr?
Rusty Russell [ARCHIVE] /
npub1zw7…khpx
2023-06-09 12:45:03
in reply to nevent1q…5k8j

Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-19 📝 Original message: Mats Jerratsch <matsjj at ...

📅 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.
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx