rich1.0npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hhttps://nostr.ae/npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hnjumphttps://nostr.ae📅 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>