[Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability)
simon at superduper.net
Tue May 14 14:27:58 UTC 2013
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.
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
> So I still think that is an important point. "Ecash should not be
> revocable". I think bitcoin currently has a partial problem because of
> Now blinding based unlinkability, in a distributed cryptographic payer/payee
> anonymous system like Sander & Ta Shma  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
> 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.
>  Sander & Ta Shma "Auditable, Anonymous Electronic Cash"
> 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.
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
More information about the bitcoin-dev