{"type":"rich","version":"1.0","author_name":"npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7h","author_url":"https://nostr.ae/npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-01-18\n📝 Original message:*Avoiding ECDH calcs on every blockchain transaction (and avoiding the\nprefix thing):*\n\nCan we skip the whole ECDSA/ECDH thing, and use the second key pair for\nencryption instead?  Then we don't need any ephemeral keys.  We use the\nmuch simpler scheme like I mentioned before (just root keys and\nmultpliers), but instead of requesting a multiplier from the person\nreceiving the money, the payer can create their own multiplier and\nencrypt it into an OP_RETURN msg (using the secondary public key of the\nreceiver).  When they do this, they append a deterministic identifier to\nit, so that the receiver can immediately identify it upon decryption.\n\nBasically, the receiver simply attempts decryption of every OP_RETURN\nmessage, and if the identifier is there, they immediately know that the\ntx is theirs, and that the other bytes of the decrypted message is the\nmultiplier used.\n\nOf course, using something like ECIES and forcing the receiver to\nattempt decryption of every OP_RETURN tx may not be any faster than the\nECDH we've already talked about here.  But with this, we are not tied to\nany particular crypto.  Isn't there a much faster asymmetric scheme that\nwe can use?  I've heard people talk about ed25519, though I'm not sure\nit can be used for encryption.  I'd bet money there is an asymmetric\n_/encryption/_//algorithm that would be fast enough to not burden the\nreceiver.\n\nHere's how I envision it:\n\n--Alice gives out her business card that has public key X (BIP32 root),\nand public key Y (fastCrypto)\n--Bob generates a random 32-byte nonce, and EC-multiplies Alice's public\nkey by it.   He prepares a transaction sending coins to that address (Z)\n--Bob also computes a deterministic identifier, perhaps hash(pubKeyX ||\naddrZ)[8:].  Bob appends the those 8 bytes to the multiplier, and\nencrypts all of it with Alice's fastCrypto key, Y.   He puts that\nmessage in the OP_RETURN output.\n--Alice's wallet will attempt decryption of every OP_RETURN message. \nFirst she computes hash(pubKeyX, addrZ)[8:], and then decrypts the\nmessage with the fastCrypto private key.  If the tx is actually hers,\nthe last 8 bytes will match the identifier, and she knows to use the\nother 32 bytes as a multiplier.  If it doesn't, it's irrelevant to her\nand she moves on.\n\n[**Should probably use 24-byte values for the multipliers (or hashes of\n24-byte values), so that adding 8 bytes makes the whole message an even\n32 bytes which is better for encryption]\n\nDoesn't this have the exact same properties as the original proposal\n(including compatibility with CoinJoin)?  But it all depends on having\nfast asymmetric encryption.\n\n-Alan\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140117/ef9e2937/attachment.html\u003e"}