Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.83.50 as permitted sender)
	client-ip=74.125.83.50; envelope-from=adam.back@gmail.com;
	helo=mail-ee0-f50.google.com; 
Date: Tue, 14 May 2013 16:09:02 +0200
From: Adam Back <adam@cypherspace.org>
To: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20130514140902.GA22447@netbook.cypherspace.org>
References: <20130514115151.GA21600@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20130514115151.GA21600@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Bitcoin-development] bitcoin taint & unilateral revocability (Re:
	ecash and revocability)
Precedence: list

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