pull down to refresh

0 sats \ 7 replies \ @BitcoinHistory OP 14 Nov 2023 \ parent \ on: Bitcoin P2P e-cash paper | Satoshi Nakamoto satoshi at vistomail.com Fri Oct 31 bitcoin
Satoshi Nakamoto https://www.metzdowd.com/pipermail/cryptography/2008-November/014815.html satoshi at vistomail.com Sun Nov 2 20:37:43 EST 2008 Previous message: Secrets and cell phones. Next message: Bitcoin P2P e-cash paper Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Satoshi Nakamoto wrote:
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: http://www.bitcoin.org/bitcoin.pdf
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 a double spending event in a timely manner, one must have most past transactions of the coins in the transaction, which, naively implemented, requires each peer to have most past transactions, or most past transactions that occurred recently. If hundreds of millions of people are doing transactions, that is a lot of bandwidth - each must know all, or a substantial part thereof.
Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.
The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.
If the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal.
Satoshi Nakamoto
write
preview
0 sats \ 3 replies \ @BitcoinHistory OP 14 Nov 2023
Ray Dillinger https://www.metzdowd.com/pipermail/cryptography/2008-November/014822.html bear at sonic.net Thu Nov 6 00:14:37 EST 2008 Previous message: Bitcoin P2P e-cash paper Next message: WPA broken even further Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Tue, 2008-11-04 at 06:20 +1000, James A. Donald wrote:
If I understand Simplified Payment Verification correctly:
New coin issuers need to store all coins and all recent coin transfers.
There are many new coin issuers, as many as want to be issuers, but far more coin users.
Ordinary entities merely transfer coins. To see if a coin transfer is OK, they report it to one or more new coin issuers and see if the new coin issuer accepts it. New coin issuers check transfers of old coins so that their new coins have valid form, and they report the outcome of this check so that people will report their transfers to the new coin issuer.
I think the real issue with this system is the market for bitcoins.
Computing proofs-of-work have no intrinsic value. We can have a limited supply curve (although the "currency" is inflationary at about 35% as that's how much faster computers get annually) but there is no demand curve that intersects it at a positive price point.
I know the same (lack of intrinsic value) can be said of fiat currencies, but an artificial demand for fiat currencies is created by (among other things) taxation and legal-tender laws. Also, even a fiat currency can be an inflation hedge against another fiat currency's higher rate of inflation. But in the case of bitcoins the inflation rate of 35% is almost guaranteed by the technology, there are no supporting mechanisms for taxation, and no legal-tender laws. People will not hold assets in this highly-inflationary currency if they can help it.
		Bear
reply
0 sats \ 2 replies \ @BitcoinHistory OP 14 Nov 2023
Satoshi Nakamoto https://www.metzdowd.com/pipermail/cryptography/2008-November/014831.html satoshi at vistomail.com Sat Nov 8 13:54:38 EST 2008 Previous message: This is a test. This is only a test... Next message: Bitcoin P2P e-cash paper Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Ray Dillinger:
the "currency" is inflationary at about 35% as that's how much faster computers get annually ... the inflation rate of 35% is almost guaranteed by the technology
Increasing hardware speed is handled: "To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases."
As computers get faster and the total computing power applied to creating bitcoins increases, the difficulty increases proportionally to keep the total new production constant. Thus, it is known in advance how many new bitcoins will be created every year in the future.
The fact that new coins are produced means the money supply increases by a planned amount, but this does not necessarily result in inflation. If the supply of money increases at the same rate that the number of people using it increases, prices remain stable. If it does not increase as fast as demand, there will be deflation and early holders of money will see its value increase.
Coins have to get initially distributed somehow, and a constant rate seems like the best formula.
Satoshi Nakamoto
reply
0 sats \ 1 reply \ @BitcoinHistory OP 14 Nov 2023
James A. Donald https://www.metzdowd.com/pipermail/cryptography/2008-November/014837.html jamesd at echeque.com Sun Nov 9 05:05:05 EST 2008 Previous message: Bitcoin P2P e-cash paper Next message: Bitcoin P2P e-cash paper Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Satoshi Nakamoto wrote:
Increasing hardware speed is handled: "To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases."
This does not work - your proposal involves complications I do not think you have thought through.
Furthermore, it cannot be made to work, as in the proposed system the work of tracking who owns what coins is paid for by seigniorage, which requires inflation.
This is not an intolerable flaw - predictable inflation is less objectionable than inflation that gets jiggered around from time to time to transfer wealth from one voting block to another.
reply
0 sats \ 0 replies \ @BitcoinHistory OP 14 Nov 2023
Satoshi Nakamoto https://www.metzdowd.com/pipermail/cryptography/2008-November/014842.html satoshi at vistomail.com Sun Nov 9 21:14:30 EST 2008 Previous message: Bitcoin P2P e-cash paper Next message: Bitcoin P2P e-cash paper Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] James A. Donald wrote:
Furthermore, it cannot be made to work, as in the proposed system the work of tracking who owns what coins is paid for by seigniorage, which requires inflation.
If you're having trouble with the inflation issue, it's easy to tweak it for transaction fees instead. It's as simple as this: let the output value from any transaction be 1 cent less than the input value. Either the client software automatically writes transactions for 1 cent more than the intended payment value, or it could come out of the payee's side. The incentive value when a node finds a proof-of-work for a block could be the total of the fees in the block.
Satoshi Nakamoto
reply
0 sats \ 1 reply \ @BitcoinHistory OP 14 Nov 2023
James A. Donald https://www.metzdowd.com/pipermail/cryptography/2008-November/014819.html jamesd at echeque.com Mon Nov 3 15:20:13 EST 2008 Previous message: Bitcoin P2P e-cash paper Next message: Bitcoin P2P e-cash paper Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] James A. Donald:
To detect and reject a double spending event in a timely manner, one must have most past transactions of the coins in the transaction, which, naively implemented, requires each peer to have most past transactions, or most past transactions that occurred recently. If hundreds of millions of people are doing transactions, that is a lot of bandwidth - each must know all, or a substantial part thereof.
Satoshi Nakamoto wrote:
Long before the network gets anywhere near as large as that, it would be Safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers,
If I understand Simplified Payment Verification correctly:
New coin issuers need to store all coins and all recent coin transfers.
There are many new coin issuers, as many as want to be issuers, but far more coin users.
Ordinary entities merely transfer coins. To see if a coin transfer is OK, they report it to one or more new coin issuers and see if the new coin issuer accepts it. New coin issuers check transfers of old coins so that their new coins have valid form, and they report the outcome of this check so that people will report their transfers to the new coin issuer.
If someone double spends a coin, and one expenditure is reported to one new coin issuer, and the other simultaneously reported to another new coin issuer, then both issuers to swifly agree on a unique sequence order of payments. This, however, is a non trivial problem of a massively distributed massive database, a notoriously tricky problem, for which there are at present no peer to peer solutions. Obiously it is a solvable problem, people solve it all the time, but not an easy problem. People fail to solve it rather more frequently.
But let us suppose that the coin issue network is dominated by a small number of issuers as seems likely.
If a small number of entities are issuing new coins, this is more resistant to state attack that with a single issuer, but the government regularly attacks financial networks, with the financial collapse ensuing from the most recent attack still under way as I write this.
Government sponsored enterprises enter the business, in due course bad behavior is made mandatory, and the evil financial network is bigger than the honest financial network, with the result that even though everyone knows what is happening, people continue to use the paper issued by the evil financial network, because of network effects - the big, main issuers, are the issuers you use if you want to do business.
Then knowledgeable people complain that the evil financial network is heading for disaster, that the government sponsored enterprises are about to cause a "collapse of the total financial system", as Wallison and Alan Greenspan complained in 2005, the government debates shrinking the evil government sponsored enterprises, as with "S. 190 [109th]: Federal Housing Enterprise Regulatory Reform Act of 2005" but they find easy money too seductive, and S. 190 goes down in flames before a horde of political activists chanting that easy money is sound, and opposing it is racist, nazi, ignorant, and generally hateful, the recent S. 190 debate on limiting portfolios (bond issue supporting dud mortgages) by government sponsored enterprises being a perfect reprise of the debates on limiting the issue of new assignats in the 1790s.
The big and easy government attacks on money target a single central money issuer, as with the first of the modern political attacks, the French Assignat of 1792, but in the late nineteenth century political attacks on financial networks began, as for example the Federal reserve act of 1913, the goal always being to wind up the network into a single too big to fail entity, and they have been getting progressively bigger, more serious, and more disastrous, as with the most recent one. Each attack is hugely successful, and after the cataclysm that the attack causes the attackers are hailed as saviors of the poor, the oppressed, and the nation generally, and the blame for the the bad consequences is dumped elsewhere, usually on Jews, greedy bankers, speculators, etc, because such attacks are difficult for ordinary people understand. I have trouble understanding your proposal - ordinary users will be easily bamboozled by a government sponsored security update. Further, when the crisis hits, to disagree with the line, to doubt that the regulators are right, and the problem is the evil speculators, becomes political suicide, as it did in America in 2007, sometimes physical suicide, as in Weimar Germany.
Still, it is better, and more resistant to attack by government sponsored enterprises, than anything I have seen so far.
Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.
If the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal.
If there were a hundred or a thousand money issuers by the time the government attacks, the kind of government attacks on financial networks that we have recently seen might well be more difficult.
But I think we need to concern ourselves with minimizing the data and bandwidth required by money issuers - for small coins, the protocol seems wasteful. It would be nice to have the full protocol for big coins, and some shortcut for small coins wherein people trust account based money for small amounts till they get wrapped up into big coins.
The smaller the data storage and bandwidth required for money issuers, the more resistant the system is the kind of government attacks on financial networks that we have recently seen.
reply
0 sats \ 0 replies \ @BitcoinHistory OP 14 Nov 2023 freebie
Satoshi Nakamoto https://www.metzdowd.com/pipermail/cryptography/2008-November/014823.html satoshi at vistomail.com Thu Nov 6 15:15:40 EST 2008 Previous message: IBM Zurich Research Laboratory Internet Transaction Security on Your Key Chain Next message: ADMIN: no money politics, please Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Lengthy exposition of vulnerability of a systm to use-of-force monopolies ellided.]
You will not find a solution to political problems in cryptography.
Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.
Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.
Satoshi
(NOTE: It is unknown who this comment by satoshi is in reply to, but it fits as a reply to James A donald. Wuith that said there is no verification of this on the mailing list, so it could have been in reply to someone elses now missing message?)
0 sats \ 0 replies \ @BitcoinHistory OP 14 Nov 2023 freebie
James A. Donald https://www.metzdowd.com/pipermail/cryptography/2008-November/014834.html jamesd at echeque.com Sat Nov 8 23:55:23 EST 2008 Previous message: WPA broken even further Next message: Bitcoin P2P e-cash paper Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Satoshi Nakamoto wrote:
The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.
The trouble is, you are comparing with the Bankcard network.
But a new currency cannot compete directly with an old, because network effects favor the old.
You have to go where Bankcard does not go.
At present, file sharing works by barter for bits. This, however requires the double coincidence of wants. People only upload files they are downloading, and once the download is complete, stop seeding. So only active files, files that quite a lot of people want at the same time, are available.
File sharing requires extremely cheap transactions, several transactions per second per client, day in and day out, with monthly transaction costs being very small per client, so to support file sharing on bitcoins, we will need a layer of account money on top of the bitcoins, supporting transactions of a hundred thousandth the size of the smallest coin, and to support anonymity, chaumian money on top of the account money.
Let us call a bitcoin bank a bink. The bitcoins stand in the same relation to account money as gold stood in the days of the gold standard. The binks, not trusting each other to be liquid when liquidity is most needed, settle out any net discrepancies with each other by moving bit coins around once every hundred thousand seconds or so, so bitcoins do not change owners that often, Most transactions cancel out at the account level. The binks demand bitcoins of each other only because they don't want to hold account money for too long. So a relatively small amount of bitcoins infrequently transacted can support a somewhat larger amount of account money frequently transacted.