From: Adam Back <adam@cypherspace•org>
To: Bitcoin-Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability)
Date: Tue, 14 May 2013 16:09:02 +0200 [thread overview]
Message-ID: <20130514140902.GA22447@netbook.cypherspace.org> (raw)
In-Reply-To: <20130514115151.GA21600@netbook.cypherspace.org>
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
next prev parent reply other threads:[~2013-05-14 14:09 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 ` Adam Back [this message]
2013-05-14 14:27 ` [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability) Simon Barber
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=20130514140902.GA22447@netbook.cypherspace.org \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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