Re: [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability)

[Simon Barber <simon@superduper.net>]

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
>