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

[Patrick Chkoreff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday, April 24, 2003, at 05:27 PM, Adam Back wrote:

> 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.)


Although I have read some material on blinding etc., I do not see a 
need for it in my system.

At Tim May's suggestion I shall avoid using the word "coin" and use the 
more accurate financial term "note" instead.

Although technically a note in my system is <32-bit file 
position><256-bit random gibberish><64-bit amount>, I'll use a simpler 
and abbreviated decimal notation with dashes in the quick example that 
follows.

Alice has a note "0247-223235898-00032" that entitles her to 32 grams 
of e-bullion.  She decides to take delivery.  She presents the coin to 
the server and the server computes the RIPEMD-160 hash.  It looks at 
record number 247 in the data file and sees if the hash stored there 
matches the computed hash.  If so, the server extinguishes the coin 
(randomizing the record and chaining it to the free list) and spends 32 
grams of e-bullion to the account that Alice designates, no questions 
asked.  (Obviously you have to handle any errors in the e-bullion spend 
- -- don't extinguish the coin if the spend fails.)

Now Alice tries to pull a fast one.  She presents that same note 
"0247-223235898-00032" to Bob.  Bob decides to swap the note for a new 
one.  He presents it to the server.  The server computes the RIPEMD-160 
hash.  It looks at record number 247 in the data file and sees that the 
record is on the free list.  It rejects Bob's request.  Double spend 
prevented.

Now perhaps in the meantime the server has decided to reuse record 247. 
  In that case there is a brand new note hash sitting there, and it is 
astronomically unlikely to match the hash of the "0247-223235898-00032" 
note.  (I have considered issuing serial numbers that are never reused 
but for some vague reason I don't quite like that.  It might not be a 
big deal.)  Again, double spend prevented.

Quite simply, the absence of a match indicates a spent coin, or one 
that was never issued in the first place.  It's very much like 
GoldMoney payment keys, which simply say YES or NO when you try to 
redeem them, with no information given about whether it was EVER a 
valid payment key.

If there is any problem of "linkability" in this scheme, please help me 
see it.  The server does not log any socket events or transaction 
records of any kind.  OK, if someone put a gun to my head and said "put 
in some code to log everything" then they might be able to discern some 
pattern like "this coin was issued to this IP address, and then three 
days later that coin was swapped from this other IP address."  OK, that 
sounds like a potential problem, but I don't see how you can hide this 
information from the server ITSELF.  When you present a coin to the 
server, it is going to know from which IP address it came, and I don't 
see a way around that.

There is no linkability of personal identity in the system because 
there is no personal identity in the system, period.  The server has no 
use for a public key from any user.

- -- Patrick
http://fexl.com

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPqhhW1A7g7bodUwLEQL63gCg91lfShbCyCGQ68Bn2LAeY3Cv6wkAnAtR
lEhm4j76EzsgzU/sdrm6TNbV
=4OMx
-----END PGP SIGNATURE-----