From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W4NwT-0001Zq-4L for bitcoin-development@lists.sourceforge.net; Sat, 18 Jan 2014 04:55:33 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.173 as permitted sender) client-ip=209.85.216.173; envelope-from=etotheipi@gmail.com; helo=mail-qc0-f173.google.com; Received: from mail-qc0-f173.google.com ([209.85.216.173]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W4NwS-0000oj-6S for bitcoin-development@lists.sourceforge.net; Sat, 18 Jan 2014 04:55:33 +0000 Received: by mail-qc0-f173.google.com with SMTP id i8so4308661qcq.4 for ; Fri, 17 Jan 2014 20:55:26 -0800 (PST) X-Received: by 10.224.60.69 with SMTP id o5mr9374406qah.92.1390020926727; Fri, 17 Jan 2014 20:55:26 -0800 (PST) Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net. [76.111.96.126]) by mx.google.com with ESMTPSA id w8sm16908591qag.15.2014.01.17.20.55.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jan 2014 20:55:26 -0800 (PST) Message-ID: <52DA093D.4070505@gmail.com> Date: Fri, 17 Jan 2014 23:55:25 -0500 From: Alan Reiner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <20140114225321.GT38964@giles.gnomon.org.uk> <20140116212805.GA4421@petertodd.org> <20140117144601.GA8614@petertodd.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------000009010600060708060400" X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (etotheipi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1W4NwS-0000oj-6S Subject: Re: [Bitcoin-development] Stealth Addresses X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 04:55:33 -0000 This is a multi-part message in MIME format. --------------000009010600060708060400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit *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 --------------000009010600060708060400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit *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



--------------000009010600060708060400--