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