Alan Reiner [ARCHIVE] on Nostr: 📅 Original date posted:2014-01-18 📝 Original message:*Avoiding ECDH calcs on ...
📅 Original date posted:2014-01-18
📝 Original message:*Avoiding ECDH calcs on every blockchain transaction (and avoiding the
prefix thing):*
Can we skip the whole ECDSA/ECDH thing, and use the second key pair for
encryption instead? Then we don't need any ephemeral keys. We use the
much simpler scheme like I mentioned before (just root keys and
multpliers), but instead of requesting a multiplier from the person
receiving the money, the payer can create their own multiplier and
encrypt it into an OP_RETURN msg (using the secondary public key of the
receiver). When they do this, they append a deterministic identifier to
it, so that the receiver can immediately identify it upon decryption.
Basically, the receiver simply attempts decryption of every OP_RETURN
message, and if the identifier is there, they immediately know that the
tx is theirs, and that the other bytes of the decrypted message is the
multiplier used.
Of course, using something like ECIES and forcing the receiver to
attempt decryption of every OP_RETURN tx may not be any faster than the
ECDH we've already talked about here. But with this, we are not tied to
any particular crypto. Isn't there a much faster asymmetric scheme that
we can use? I've heard people talk about ed25519, though I'm not sure
it can be used for encryption. I'd bet money there is an asymmetric
_/encryption/_//algorithm that would be fast enough to not burden the
receiver.
Here's how I envision it:
--Alice gives out her business card that has public key X (BIP32 root),
and public key Y (fastCrypto)
--Bob generates a random 32-byte nonce, and EC-multiplies Alice's public
key by it. He prepares a transaction sending coins to that address (Z)
--Bob also computes a deterministic identifier, perhaps hash(pubKeyX ||
addrZ)[8:]. Bob appends the those 8 bytes to the multiplier, and
encrypts all of it with Alice's fastCrypto key, Y. He puts that
message in the OP_RETURN output.
--Alice's wallet will attempt decryption of every OP_RETURN message.
First she computes hash(pubKeyX, addrZ)[8:], and then decrypts the
message with the fastCrypto private key. If the tx is actually hers,
the last 8 bytes will match the identifier, and she knows to use the
other 32 bytes as a multiplier. If it doesn't, it's irrelevant to her
and she moves on.
[**Should probably use 24-byte values for the multipliers (or hashes of
24-byte values), so that adding 8 bytes makes the whole message an even
32 bytes which is better for encryption]
Doesn't this have the exact same properties as the original proposal
(including compatibility with CoinJoin)? But it all depends on having
fast asymmetric encryption.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140117/ef9e2937/attachment.html>;
📝 Original message:*Avoiding ECDH calcs on every blockchain transaction (and avoiding the
prefix thing):*
Can we skip the whole ECDSA/ECDH thing, and use the second key pair for
encryption instead? Then we don't need any ephemeral keys. We use the
much simpler scheme like I mentioned before (just root keys and
multpliers), but instead of requesting a multiplier from the person
receiving the money, the payer can create their own multiplier and
encrypt it into an OP_RETURN msg (using the secondary public key of the
receiver). When they do this, they append a deterministic identifier to
it, so that the receiver can immediately identify it upon decryption.
Basically, the receiver simply attempts decryption of every OP_RETURN
message, and if the identifier is there, they immediately know that the
tx is theirs, and that the other bytes of the decrypted message is the
multiplier used.
Of course, using something like ECIES and forcing the receiver to
attempt decryption of every OP_RETURN tx may not be any faster than the
ECDH we've already talked about here. But with this, we are not tied to
any particular crypto. Isn't there a much faster asymmetric scheme that
we can use? I've heard people talk about ed25519, though I'm not sure
it can be used for encryption. I'd bet money there is an asymmetric
_/encryption/_//algorithm that would be fast enough to not burden the
receiver.
Here's how I envision it:
--Alice gives out her business card that has public key X (BIP32 root),
and public key Y (fastCrypto)
--Bob generates a random 32-byte nonce, and EC-multiplies Alice's public
key by it. He prepares a transaction sending coins to that address (Z)
--Bob also computes a deterministic identifier, perhaps hash(pubKeyX ||
addrZ)[8:]. Bob appends the those 8 bytes to the multiplier, and
encrypts all of it with Alice's fastCrypto key, Y. He puts that
message in the OP_RETURN output.
--Alice's wallet will attempt decryption of every OP_RETURN message.
First she computes hash(pubKeyX, addrZ)[8:], and then decrypts the
message with the fastCrypto private key. If the tx is actually hers,
the last 8 bytes will match the identifier, and she knows to use the
other 32 bytes as a multiplier. If it doesn't, it's irrelevant to her
and she moves on.
[**Should probably use 24-byte values for the multipliers (or hashes of
24-byte values), so that adding 8 bytes makes the whole message an even
32 bytes which is better for encryption]
Doesn't this have the exact same properties as the original proposal
(including compatibility with CoinJoin)? But it all depends on having
fast asymmetric encryption.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140117/ef9e2937/attachment.html>;