double-spending prevention w. spent coins (Re: [Lucrative-L] lucrative accounts revisited)

[Adam Back]

If the coins offer privacy, then unspent coins are unlinkable when the
same coin is deposited, so keeping just unspent coins doesn't work.

Spent coins on the other hand have their blinding removed, so you
notice double spending by looking at spent coins.

(There are zero-knowledge proofs of non-set membership as proposed for
use in ecash by Sander and Ta-Shma [1], but I think these are quite
computationally expensive.)

Adam

[1] "Auditable, Anonymous Electronic Cash", Tomas Sander, Amnon
Ta-Shma, Crypto 99

http://citeseer.nj.nec.com/sander98auditable.html

On Thu, Apr 24, 2003 at 03:52:28PM -0400, Patrick Chkoreff wrote:
> On Thursday, April 24, 2003, at 01:57 PM, R. A. Hettinga wrote:
> 
> > Again, the *only* thing you need to prevent double-spending is a copy 
> > of the spent coins. Period.
> 
> Alternatively, I think a copy of the non-spent coins will do the trick 
> also.
> 
> So in your scenario, the predicate valuable(x) = valid_crypto_stamp(x) 
> & not element(x, spent_coins).
> 
> In my scenario, valuable(x) = element(x, unspent_coins).
> 
> Why store the large set of spent coins when you can store the much 
> smaller set of unspent coins?
> 
> There's no security issue I don't think.  In my scheme the bad guys can 
> torture you and get access to the hash file, yes, but what's the point? 
>   They still have to mount a multi-million dollar collision attack.  
> It's much easier just to seize the gold in the vaults than fiddle 
> around with some pathetic bits on a server.  Or if the digital coins 
> are backed by something like e-bullion they can just torture you for 
> the e-bullion password.
> 
> 
> > Anything else costs money.
> >
> > Transaction cost is everything.
> 
> I don't understand your point here.  Why are my transaction costs 
> greater than yours?  They might even be less.  The disk usage might be 
> less, too.
> 
> -- Patrick
> http://fexl.com