From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WLXLG-00026n-44 for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 12:24:02 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; envelope-from=gcbd-bitcoin-development@m.gmane.org; helo=plane.gmane.org; Received: from plane.gmane.org ([80.91.229.3]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WLXLE-0000ir-Ir for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 12:24:02 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WLXL6-0007DK-Jk for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 13:23:52 +0100 Received: from 69-172-146-209.cable.teksavvy.com ([69.172.146.209]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Mar 2014 13:23:52 +0100 Received: from carterd by 69-172-146-209.cable.teksavvy.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Mar 2014 13:23:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-development@lists.sourceforge.net From: Dan Carter Date: Thu, 06 Mar 2014 04:23:40 -0800 Message-ID: <531868CC.807@gmail.com> References: <20140106120338.GA14918@savin> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 69-172-146-209.cable.teksavvy.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:29.0) Gecko/20100101 Thunderbird/29.0a1 In-Reply-To: <20140106120338.GA14918@savin> X-Spam-Score: -0.3 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.91.229.3 listed in list.dnswl.org] -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 (carterd[at]gmail.com) -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1WLXLE-0000ir-Ir 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: Thu, 06 Mar 2014 12:24:02 -0000 I think stealth addresses combined with zk-snarks would obviate the need for CoinJoin. zk-snarks could be used to hide the coin's value and stealth addresses could be used to hide the recipient for payments and even mined coins. More info on zero-knowledge snarks: http://cs.tau.ac.il/~tromer/papers/vnsnark-20131230.pdf http://cs.tau.ac.il/~tromer/papers/csnark-20131007.pdf Start with a mined coin: generate a coin secret, create a coinbase transaction with an output to your stealth address and send hash(coin-secret + reward-value) + encrypt(coin-secret + reward-value) where only the recipient (you) can decrypt. (The reward value is known publicly but just assume it isn't here for generality). You also embed the 0.2KB zk-snark proof + 3KB verifying key that the hash result is in fact SHA256(coin-secret + reward-value), where your private witnesses are (coin-secret, reward-value). Now you could split a coin into as many pieces as you want in a single transaction and send to multiple recipients, some pieces go to yourself (change) and others to the payee, every piece would have a different recipient address thanks to stealth addresses, and all values hidden thanks to zk-snarks. So lets say you want to split the mined coin into two new ones. You create a transaction where the input redeems the mined coin using mined tx out + your stealth address, and there are two new coins as outputs to your own stealth address each having: hash(new-coin-secret + new-hidden-value) + encrypt(new-coin-secret + new-hidden-value). You also embed the zk-snark proof that the two new hidden values add up to the original hidden value, and that the two new hash results are in fact SHA256(new-coin-secret + new-hidden-value), where your private witnesses are (original-coin-secret, original-hidden-value, new-coin-secrets, new-hidden-values). If you want to merge two coins into one it's just a split backwards, two inputs one output, zk-snark proof that two original hidden values add up to the new hidden value and that the new hash result is SHA256(new-coin-secret + new-hidden-value). If you want to transfer ownership of a coin then just redeem at input, and output same as mined coin except using recipient stealth address (which is a public key) to encrypt(coin-secret + hidden-value). - Dan On 2014-01-06 4:03 AM, Peter Todd wrote: > * Abstract > > A Stealth Address is a new type of Bitcoin address and related > scriptPubKey/transaction generation scheme that allowers payees to > publish a single, fixed, address that payors can send funds efficiently, > privately, reliably and non-interactively. Payors do not learn what > other payments have been made to the stealth address, and third-parties > learn nothing at all. (both subject to an adjustable anonymity set)