Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UcGD7-0005xs-CY for bitcoin-development@lists.sourceforge.net; Tue, 14 May 2013 14:28:13 +0000 X-ACL-Warn: Received: from masada.superduper.net ([85.119.82.91]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1UcGD2-0004AF-Ba for bitcoin-development@lists.sourceforge.net; Tue, 14 May 2013 14:28:13 +0000 Received: from 199-83-222-6.public.monkeybrains.net ([199.83.222.6] helo=[192.168.0.13]) by masada.superduper.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UcGCu-00075K-AP; Tue, 14 May 2013 15:28:01 +0100 Message-ID: <519249EE.5050001@superduper.net> Date: Tue, 14 May 2013 07:27:58 -0700 From: Simon Barber User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adam Back References: <20130514115151.GA21600@netbook.cypherspace.org> <20130514140902.GA22447@netbook.cypherspace.org> In-Reply-To: <20130514140902.GA22447@netbook.cypherspace.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1UcGD2-0004AF-Ba Cc: Bitcoin-Dev , Xavier Boyen Subject: Re: [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability) 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: Tue, 14 May 2013 14:28:13 -0000 Adam, Take a look at this privacy enhancing solution based on fair exchange implemented by bitcoin contracts and cut-and-choose. It would require a public pool of users willing to exchange in common denominations at moments in time together to ensure unlinkability. It also leave a trace of exchange activity in the chain. This could all be added to wallet software to become automatic. http://robotics.stanford.edu/~xb/fc12/index.html Simon On 05/14/2013 07:09 AM, Adam Back wrote: > On Tue, May 14, 2013 at 01:51:51PM +0200, Adam Back wrote: >> Adam Back in Sep 1999, cypherpunks list: >>> I wouldn't say ecash has to use blinding, but I would argue it would be a >>> misuse of the word "ecash", if something which was revocable were dubbed >>> ecash. > > So I still think that is an important point. "Ecash should not be > revocable". I think bitcoin currently has a partial problem because of > taint. > > Now blinding based unlinkability, in a distributed cryptographic payer/payee > anonymous system like Sander & Ta Shma [1] and zerocoin has so far been > based on ZKP of set membership. Of course that is somewhat expensive, > though zerocoin improved the ZKP with an relatively efficient (but still > cut-and-choose) proof. > > Bitcoins relative lack of privacy creates a problem with tainted coins > risking becoming unspendable, or spendable only with some users, or at a > discount. So while the policy coded says all coins are equally acceptable, > the information exists so people can unilaterally reject them, depending on > what the taint is. So far revocability hasnt reared it's head that I heard, > nor taint inspection too much? However people have the choice and technical > means to check the taint and send the bitcoins back. > > > Another aspect is that bitcoin, like systemics sox/digigold, makes a > different privacy tradeoff. Somewhat private, but not very much. > > But it creates the question: could the taint issue be fixed efficiently (eg > even without blinding or ZKP of set membership?) > > > One related concept is commitments. I think its relatively easy to commit > to a payment and lock a coin without identifying yourself, until the > commitment is released. You might do the commitment, wait 6-blocks for > confirmation, then reveal the commitment. Then that is like a self-issued > green coin with no need for trust, that can be immediately cleared. The > recipient has to be committed to at the same time to prevent double > spending. > > So just commit = H( input-pub ) H( transaction ) and put it in the block > chain. Where transaction the is usual ( input signature, output-pub, > script). (Fee for the commit would have to come from an unlinked coin or > the input-pub reveals the coin). Wait 6 blocks, send/reveal the transaction > (free because fee was already paid). Validators check input-pub hash > against committed coins by hash, check the transaction hash, and the usual > ransaction validations = sum inputs, otherwise reject. The user better pay > change if any to a different public key, as the inputs public keys are one > use - are after the reveal they are DoS lockable by other people reposting > H( input-pub ). > > The input-pub coin is locked as normal transactions have their public key hash > validate as not being locked. > > Adam > > [1] Sander & Ta Shma "Auditable, Anonymous Electronic Cash" > http://www.cs.tau.ac.il/~amnon/Papers/ST.crypto99.pdf > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >