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

[Ben Laurie]

Patrick Chkoreff wrote:
> On Thursday, April 24, 2003, at 05:27 PM, Adam Back wrote:
> 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.

Blinded coins prevent the server from knowing which IP address they are
issued to (that is, it knows it issued _a_ coin to the address, but it
doesn't know which one). When it sees an unblinded coin, yes, it knows
which IP address that is presented by, but since it doesn't know who had
it in the first place, that doesn't help. Of course, the unblinded coin
is immediately replaced by a blinded one, thus restarting the cycle.

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

Errr - so how do you get money into the system in the first place? Note
that blinded coins solve this issue, too - the server can have a list of
where all the money came from in the first place, but after that it
knows nothing.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff