{
"subject": "Bitcoin P2P e-cash paper",
"content": {
"format": "email",
"body": "Ray Dillinger wrote:\n> One way to do this would be\n> to have the person recieving the coin generate an asymmetric\n> key pair, and then have half of it published with the\n> transaction. In order to spend the coin later, s/he must\n> demonstrate posession of the other half of the asymmetric\n> key pair, probably by using it to sign the key provided by\n> the new seller.\n\nRight, it's ECC digital signatures. A new key pair is used for every\ntransaction.\n\nIt's not pseudonymous in the sense of nyms identifying people, but it\nis at least a little pseudonymous in that the next action on a coin\ncan be identified as being from the owner of that coin.\n\n\n> Mmmm. I don't know if I'm comfortable with that. You're saying\n> there's no effort to identify and exclude nodes that don't\n> cooperate? I suspect this will lead to trouble and possible DOS\n> attacks.\n\nThere is no reliance on identifying anyone. As you've said, it's\nfutile and can be trivially defeated with sock puppets.\n\nThe credential that establishes someone as real is the ability to\nsupply CPU power. \n\n\n> Until.... until what? How does anybody know when a transaction\n> has become irrevocable? Is \"a few\" blocks three? Thirty? A\n> hundred? Does it depend on the number of nodes? Is it logarithmic\n> or linear in number of nodes?\n\nSection 11 calculates the worst case under attack. Typically, 5 or\n10 blocks is enough for that. If you're selling something that\ndoesn't merit a network-scale attack to steal it, in practice you\ncould cut it closer.\n\n\n> But in the absence of identity, there's no downside to them\n> if spends become invalid, if they've already received the\n> goods they double-spent for (access to website, download,\n> whatever). The merchants are left holding the bag with\n> \"invalid\" coins, unless they wait that magical \"few blocks\"\n> (and how can they know how many?) before treating the spender\n> as having paid.\n>\n> The consumers won't do this if they spend their coin and it takes\n> an hour to clear before they can do what they spent their coin on.\n> The merchants won't do it if there's no way to charge back a\n> customer when they find the that their coin is invalid because\n> the customer has doublespent.\n\nThis is a version 2 problem that I believe can be solved fairly\nsatisfactorily for most applications.\n\nThe race is to spread your transaction on the network first. Think 6\ndegrees of freedom -- it spreads exponentially. It would only take\nsomething like 2 minutes for a transaction to spread widely enough\nthat a competitor starting late would have little chance of grabbing\nvery many nodes before the first one is overtaking the whole network.\n During those 2 minutes, the merchant's nodes can be watching for a\ndouble-spent transaction. The double-spender would not be able to\nblast his alternate transaction out to the world without the merchant\ngetting it, so he has to wait before starting.\n\nIf the real transaction reaches 90% and the double-spent tx reaches\n10%, the double-spender only gets a 10% chance of not paying, and 90%\nchance his money gets spent. For almost any type of goods, that's\nnot going to be worth it for the scammer.\n\nInformation based goods like access to website or downloads are\nnon-fencible. Nobody is going to be able to make a living off\nstealing access to websites or downloads. They can go to the file\nsharing networks to steal that. Most instant-access products aren't\ngoing to have a huge incentive to steal. \n\nIf a merchant actually has a problem with theft, they can make the\ncustomer wait 2 minutes, or wait for something in e-mail, which many\nalready do. If they really want to optimize, and it's a large\ndownload, they could cancel the download in the middle if the\ntransaction comes back double-spent. If it's website access,\ntypically it wouldn't be a big deal to let the customer have access\nfor 5 minutes and then cut off access if it's rejected. Many such\nsites have a free trial anyway.\n\nSatoshi Nakamoto\n\n\n---------------------------------------------------------------------\nThe Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com\n\n"
},
"source": {
"name": "cryptography",
"url": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014860.html"
},
"date": "2008-11-15T18:02:00Z"
}