Tweet
Un certain 31 Octobre 2008, un inconnu avec un nom japonais (Satoshi Nakamoto) écrit dans un forum américain '' Cryptography mailing List'' qu'il a la solution pour créer un système de paiement type ''client à client'' sans le besoin de passer par les banques ou toute autre institution financière.
Satoshi Nakamoto:
Subject: Bitcoin P2P e-cash paper
Subject: Bitcoin P2P e-cash paper
I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party.
The paper is available at:
The main properties:
Bitcoin: A Peer-to-Peer Electronic Cash System
Satoshi Nakamoto
http://www.bitcoin.org/bitcoin.pdf
The paper is available at:
The main properties:
- Double-spending is prevented with a peer-to-peer network.
- No mint or other trusted parties.
- Participants can be anonymous.
- New coins are made from Hashcash-style proof-of-work.
- The proof-of-work for new coin generation also powers the network to prevent double-spending.
Bitcoin: A Peer-to-Peer Electronic Cash System
Satoshi Nakamoto
http://www.bitcoin.org/bitcoin.pdf
. James A. Donald — October 31 2008 (First Reply)
We very, very much need such a system, but the way I understand your proposal, it does not seem to scale to the required size.
For transferable proof of work tokens to have value, they must have monetary value. To have monetary value, they must be transferred within a very large network — for example, a file trading network akin to bittorrent.
To detect and reject double spending in a distributed database without a central authority, each participant must know about all transactions. If every user is broadcasting every transaction to every user, that’s O(n²) messages for every transaction.
Worse, as the size of the network grows, that quickly becomes unmanageable. How does your system handle that?
For transferable proof of work tokens to have value, they must have monetary value. To have monetary value, they must be transferred within a very large network — for example, a file trading network akin to bittorrent.
To detect and reject double spending in a distributed database without a central authority, each participant must know about all transactions. If every user is broadcasting every transaction to every user, that’s O(n²) messages for every transaction.
Worse, as the size of the network grows, that quickly becomes unmanageable. How does your system handle that?
Satoshi Nakamoto — November 2 2008 (Reply to James A. Donald)
Long before the network gets anywhere near that size, it would be safe for users to use Simplified Payment Verification (SPV), to verify payments without running a full network node. They only need to keep a copy of the block headers of the longest proof-of-work chain, which they can get by querying network nodes until they’re convinced they have the longest chain, and obtain the Merkle branch linking the transaction to the block it’s timestamped in.
They can’t check the transaction for themselves, but by linking it to a place in the chain, they can see that a network node has accepted it, and blocks added after it further confirm that the network has accepted it.
The only way to confirm the absence of a transaction would be to be aware of all transactions. For that reason, full network nodes are still needed for merchants and banks, but lightweight clients could exist for most users.
They can’t check the transaction for themselves, but by linking it to a place in the chain, they can see that a network node has accepted it, and blocks added after it further confirm that the network has accepted it.
The only way to confirm the absence of a transaction would be to be aware of all transactions. For that reason, full network nodes are still needed for merchants and banks, but lightweight clients could exist for most users.
James A. Donald — November 3 2008 (Second Reply)
OK, suppose every user is broadcasting every transaction. Each is sent once, on average, to every user. That’s still O(n²) bandwidth. Even if each node only keeps track of the latest few thousand transactions, it’s still enormous bandwidth. How do you avoid that?
Satoshi Nakamoto — November 3 2008 (Second Reply)
The bandwidth might not be as prohibitive as you think. Each transaction is only about 100 bytes. Each block is about 10 minutes worth of transactions. At 7 transactions per second worldwide, that’s ~10 MB per hour, or ~4.2 GB per year.
Every user doesn’t need to broadcast to every other user. Broadcasts can reach most nodes with fan-out flooding. If one node has an average of 8 connections, that’s enough to reach most of the network within a few hops.
The network does not have to be perfect; it just needs to outpace any attacker who tries to generate an alternate chain faster than the honest network.
Every user doesn’t need to broadcast to every other user. Broadcasts can reach most nodes with fan-out flooding. If one node has an average of 8 connections, that’s enough to reach most of the network within a few hops.
The network does not have to be perfect; it just needs to outpace any attacker who tries to generate an alternate chain faster than the honest network.
Commentaire