You've already forked nakamoto-archive
wakgill
112 lines
4.3 KiB
Markdown
112 lines
4.3 KiB
Markdown
---
|
|
layout: default
|
|
title: Bitcoin P2P e-cash paper
|
|
grand_parent: Emails
|
|
parent: Cryptography Mailing List
|
|
nav_order: 14
|
|
date: 2008-11-15 18:02:00 UTC
|
|
---
|
|
|
|
# Bitcoin P2P e-cash paper
|
|
|
|
Satoshi discusses double-spending and merchant payment processing.
|
|
{: .fs-6 .fw-300 }
|
|
|
|
---
|
|
|
|
```
|
|
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 majordomo at metzdowd.com
|
|
```
|