From: Simon Barber <simon@superduper•net>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin-Dev <bitcoin-development@lists•sourceforge.net>,
Xavier Boyen <xb@cs•stanford.edu>
Subject: Re: [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability)
Date: Tue, 14 May 2013 07:27:58 -0700 [thread overview]
Message-ID: <519249EE.5050001@superduper.net> (raw)
In-Reply-To: <20130514140902.GA22447@netbook.cypherspace.org>
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
>
next prev parent reply other threads:[~2013-05-14 14:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-14 11:51 [Bitcoin-development] ecash and revocability Adam Back
2013-05-14 14:09 ` [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability) Adam Back
2013-05-14 14:27 ` Simon Barber [this message]
2013-05-14 17:30 ` grarpamp
2013-05-15 10:25 ` [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability) Adam Back
2013-05-15 11:19 ` Peter Todd
2013-05-15 11:49 ` Adam Back
2013-05-15 12:40 ` Caleb James DeLisle
2013-05-15 16:21 ` Adam Back
2013-05-15 18:01 ` Caleb James DeLisle
2013-05-15 23:40 ` Adam Back
2013-05-16 1:24 ` Gavin
2013-05-16 1:39 ` Gregory Maxwell
2013-05-16 2:22 ` Mike Hearn
2013-05-16 2:45 ` Gregory Maxwell
2013-05-16 5:52 ` Caleb James DeLisle
2013-05-16 11:32 ` Adam Back
2013-05-16 14:51 ` Adam Back
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=519249EE.5050001@superduper.net \
--to=simon@superduper$(echo .)net \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=xb@cs$(echo .)stanford.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox