Ray Dillinger wrote: > One way to do this would be > to have the person recieving the coin generate an asymmetric > key pair, and then have half of it published with the > transaction. In order to spend the coin later, s/he must > demonstrate posession of the other half of the asymmetric > key pair, probably by using it to sign the key provided by > the new seller.
Right, it's ECC digital signatures. A new key pair is used for every transaction. It's not pseudonymous in the sense of nyms identifying people, but it is at least a little pseudonymous in that the next action on a coin can be identified as being from the owner of that coin. > Mmmm. I don't know if I'm comfortable with that. You're saying > there's no effort to identify and exclude nodes that don't > cooperate? I suspect this will lead to trouble and possible DOS > attacks. There is no reliance on identifying anyone. As you've said, it's futile and can be trivially defeated with sock puppets. The credential that establishes someone as real is the ability to supply CPU power. > Until.... until what? How does anybody know when a transaction > has become irrevocable? Is "a few" blocks three? Thirty? A > hundred? Does it depend on the number of nodes? Is it logarithmic > or linear in number of nodes? Section 11 calculates the worst case under attack. Typically, 5 or 10 blocks is enough for that. If you're selling something that doesn't merit a network-scale attack to steal it, in practice you could cut it closer. > But in the absence of identity, there's no downside to them > if spends become invalid, if they've already received the > goods they double-spent for (access to website, download, > whatever). The merchants are left holding the bag with > "invalid" coins, unless they wait that magical "few blocks" > (and how can they know how many?) before treating the spender > as having paid. > > The consumers won't do this if they spend their coin and it takes > an hour to clear before they can do what they spent their coin on. > The merchants won't do it if there's no way to charge back a > customer when they find the that their coin is invalid because > the customer has doublespent. This is a version 2 problem that I believe can be solved fairly satisfactorily for most applications. The race is to spread your transaction on the network first. Think 6 degrees of freedom -- it spreads exponentially. It would only take something like 2 minutes for a transaction to spread widely enough that a competitor starting late would have little chance of grabbing very many nodes before the first one is overtaking the whole network. During those 2 minutes, the merchant's nodes can be watching for a double-spent transaction. The double-spender would not be able to blast his alternate transaction out to the world without the merchant getting it, so he has to wait before starting. If the real transaction reaches 90% and the double-spent tx reaches 10%, the double-spender only gets a 10% chance of not paying, and 90% chance his money gets spent. For almost any type of goods, that's not going to be worth it for the scammer. Information based goods like access to website or downloads are non-fencible. Nobody is going to be able to make a living off stealing access to websites or downloads. They can go to the file sharing networks to steal that. Most instant-access products aren't going to have a huge incentive to steal. If a merchant actually has a problem with theft, they can make the customer wait 2 minutes, or wait for something in e-mail, which many already do. If they really want to optimize, and it's a large download, they could cancel the download in the middle if the transaction comes back double-spent. If it's website access, typically it wouldn't be a big deal to let the customer have access for 5 minutes and then cut off access if it's rejected. Many such sites have a free trial anyway. Satoshi Nakamoto --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]