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.
📝 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.