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
--
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
