public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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
>



  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.net \
    --cc=adam@cypherspace.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=xb@cs.stanford.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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