diff options
| author | Simon Barber <simon@superduper.net> | 2013-05-14 07:27:58 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-05-14 14:28:13 +0000 |
| commit | 8d5a45b7ec5b5458ca6188713e73f382c1747055 (patch) | |
| tree | 6509d0ee84dc9d85e7cb0f6bce54ad254a66289a | |
| parent | ee9478996482fd2d3d9eacb855a10a4e311139ee (diff) | |
| download | pi-bitcoindev-8d5a45b7ec5b5458ca6188713e73f382c1747055.tar.gz pi-bitcoindev-8d5a45b7ec5b5458ca6188713e73f382c1747055.zip | |
Re: [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability)
| -rw-r--r-- | b8/23a4a6bdf6370103b4db562dcca870b943f6b3 | 140 |
1 files changed, 140 insertions, 0 deletions
diff --git a/b8/23a4a6bdf6370103b4db562dcca870b943f6b3 b/b8/23a4a6bdf6370103b4db562dcca870b943f6b3 new file mode 100644 index 000000000..bb899cc5c --- /dev/null +++ b/b8/23a4a6bdf6370103b4db562dcca870b943f6b3 @@ -0,0 +1,140 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <simon@superduper.net>) id 1UcGD7-0005xs-CY + for bitcoin-development@lists.sourceforge.net; + Tue, 14 May 2013 14:28:13 +0000 +X-ACL-Warn: +Received: from masada.superduper.net ([85.119.82.91]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) + (Exim 4.76) id 1UcGD2-0004AF-Ba + for bitcoin-development@lists.sourceforge.net; + Tue, 14 May 2013 14:28:13 +0000 +Received: from 199-83-222-6.public.monkeybrains.net ([199.83.222.6] + helo=[192.168.0.13]) by masada.superduper.net with esmtpsa + (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) + (envelope-from <simon@superduper.net>) + id 1UcGCu-00075K-AP; Tue, 14 May 2013 15:28:01 +0100 +Message-ID: <519249EE.5050001@superduper.net> +Date: Tue, 14 May 2013 07:27:58 -0700 +From: Simon Barber <simon@superduper.net> +User-Agent: Mozilla/5.0 (X11; Linux i686; + rv:17.0) Gecko/20130329 Thunderbird/17.0.5 +MIME-Version: 1.0 +To: Adam Back <adam@cypherspace.org> +References: <20130514115151.GA21600@netbook.cypherspace.org> + <20130514140902.GA22447@netbook.cypherspace.org> +In-Reply-To: <20130514140902.GA22447@netbook.cypherspace.org> +Content-Type: text/plain; charset=ISO-8859-1; format=flowed +Content-Transfer-Encoding: 7bit +X-Spam-Score: -2.9 (--) +X-Spam-Score: -0.6 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay + domain +X-Headers-End: 1UcGD2-0004AF-Ba +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) +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Tue, 14 May 2013 14:28:13 -0000 + +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 +> + + |