Bitcoin P2P e-cash paper. Oct 31, 2008
Bitcoin Whitepaper release.
When Satoshi published the Bitcoin whitepaper in 2008, he got the first reply by James A. Donald saying "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."
Satoshi in reply gave an explanation on how Bitcoin is designed to work.
with'
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
First proposal to scale with side chains (Bink).
James A. Donald then proposed a second layer solution to scale Bitcoin.
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.
James A. Donald
Later on James A. Donald's historical first commentaries with Satoshi Nakamoto were considered to argumentatively presage and posit the BTC lightning network, as well as suggest data compression.
Bitcoin v0.1 released Jan 8, 2009
The first release of Bitcoin client.
Announcing the first release of Bitcoin, a new electronic cash
system that uses a peer-to-peer network to prevent double-spending.
It's completely decentralized with no server or central authority.
Total circulation will be 21,000,000 coins. It'll be distributed
to network nodes when they make blocks, with the amount cut in half
every 4 years.
first 4 years: 10,500,000 coins
next 4 years: 5,250,000 coins
next 4 years: 2,625,000 coins
next 4 years: 1,312,500 coins
etc...
When that runs out, the system can support transaction fees if
needed. It's based on open market competition, and there will
probably always be nodes willing to process transactions for free.
Satoshi Nakamoto
Second compatible implementation. SoftFork. June 17, 2010
Gavin Andresen makes a question about a second, compatible implementation.
I see that the outputs of transactions have a value (number of bitcoins) and a bunch of bytes that are run through the little Forth-like scripting language built in to bitcoin. E.g.: ['TxOut: value: 100.00 Script: DUP HASH160 6fad...ab90 EQUALVERIFY CHECKSIG']
First: it make me a little nervous that bitcoin has a scripting language in it, even though it is a really simple scripting language (no loops, no pointers, nothing but math and crypto). It makes me nervous because it is more complicated, and complication is the enemy of security. It also makes it harder to create a second, compatible implementation. But I think I can get over that.
Gavin Anersen
Satoshi responds with':
The nature of Bitcoin is such that once version 0.1 was released, the core
design was set in stone for the rest of its lifetime. Because of that, I wanted
to design it to support every possible transaction type I could think of.Â
The problem was, each thing required special support code and data fields
whether it was used or not, and only covered one special case at a time.Â
It would have been an explosion of special cases. The solution was script,
which generalizes the problem so transacting parties can describe their
transaction as a predicate that the node network evaluates.Â
The nodes only need to understand the transaction to the extent
of evaluating whether the sender's conditions are met.
The script is actually a predicate. It's just an equation that evaluates
to true or false. Predicate is a long and unfamiliar word so I called it script.
The receiver of a payment does a template match on the script. Currently,
receivers only accept two templates: direct payment and bitcoin address.Â
Future versions can add templates for more transaction types and nodes running
that version or higher will be able to receive them. All versions of nodes
in the network can verify and process any new transactions into blocks, even
though they may not know how to read them.The design supports a tremendous
variety of possible transaction types that I designed years ago. Escrow
transactions, bonded contracts, third party arbitration, multi-party signature,
etc. If Bitcoin catches on in a big way, these are things we will want to explore
in the future, but they all had to be designed at the beginning to make sure
they would be possible later.
I do not believe a second, compatible implementation of Bitcoin will ever
be a good idea. So much of the design depends on all nodes getting exactly
identical results in lockstep that a second implementation would be a menace
to the network. The MIT license is compatible with all other licenses and
commercial uses, so there is no need to rewrite it from a licensing standpoint.
Satoshi Nakamoto
Second proposal to scale with side chains (Bit-Banks). July 28, 2010
James A. Donald was not the only one that proposed a second layer scaling solution for Bitcoin. Later in 2010 a user "Bytemaster" on BitcoinTalk forum suggested a side chain model as a solution to scale Bitcoin.
I am convinced that bandwidth, disk space, and computation time necessary to distribute and "finalize" a transaction will be prohibitively expensive for micro-payments. Consider for a second that the current banking industry is unable to provide a reasonable micropayment solution that does not involve depositing a reasonable sum and only allowing a withdraw after a reasonable sum has been accumulated.Â
Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.
Thus we need bit-banks that allow instant transfers among members and peer banks.  Anyone can open a bit-bank but the system would, by necessity operate on some level of trust. Transfers in and out of the banks and peer-to-peer would still be possible but will be more costly.  Thus, a bit bank could make money by enabling transfers cheaper and faster than the swarm with the added risk of trusting the bank. A bank has to maintain trust to make money.
Dan Larimer
Satoshi however was very clear on how Bitcoin is designed to scale.
'
The current system where every user is a network node is not the intended
configuration for large scale. That would be like every Usenet user runs
their own NNTP server. The design supports letting users just be users.Â
The more burden it is to run a node, the fewer nodes there will be.Â
Those few nodes will be big server farms. The rest will be client nodes
that only do transactions and don't generate.
Quote from: bytemaster on July 28, 2010, 08:59:42 PM
Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.
'
See the snack machine thread, I outline how a payment processor could verify
payments well enough, actually really well (much lower fraud rate than credit
cards), in something like 10 seconds or less. If you don't believe me or don't
get it, I don't have time to try to convince you, sorry.
Satoshi Nakamoto
http://bitcointalk.org/index.php?topic=423.msg3819#msg3819
The first attempt to increase the Block Size October 03, 2010
Jeff Garzik suggested to at least match Paypal's average transaction rate and proposed a patch for the Bitcoin code.
Satoshi warned that it's not yet necessary, and the code upgrade would make it incompatible with other versions.
'
Don't use this patch, it'll make you incompatible with the network, to your own
detriment. We can phase in a change later if we get closer to needing it.
Satoshi Nakamoto
However Satoshi explained how the upgrade could be done in future.
'
It can be phased in, like:
if (blocknumber > 115000)
   maxblocksize = largerlimit
It can start being in versions way ahead, so by the time it reaches that
block number and goes into effect, the older versions that don't have it
are already obsolete.
When we're near the cutoff block number, I can put an alert to old
versions to make sure they know they have to upgrade.
Satoshi Nakamoto
The origin of the 1MB block limit February 07, 2015
Ray Dillinger (Cryddit), who reviewed Satoshi Nakamoto's Bitcoin code with Hal Finney before it was released, posted on BitcoinTalk forum.
I'm the guy who went over the blockchain stuff in Satoshi's first cut of the bitcoin code. Satoshi didn't have a 1MB limit in it. The limit was originally Hal Finney's idea. Both Satoshi and I objected that it wouldn't scale at 1MB. Hal was concerned about a potential DoS attack though, and after discussion, Satoshi agreed. The 1MB limit was there by the time Bitcoin launched. But all 3 of us agreed that 1MB had to be temporary because it would never scale.
Ray Dillinger (The origin of the 1MB block limit)
Mike Hearn: Questions about BitCoin
There is another evidence where Satoshi explains how Bitcoin would scale on-chain in e-mail replying to Mike Hearn.
If there is only one chain recording "the story of the economy" so to speak, how does this scale? In an imaginary planet-wide deployment there would be millions of even billions of transactions per hour being hashed into the chain. I realize that each PoW can wrap many transactions in one block, nonetheless, that's a large amount of data to hash.
Mike Hearn
Satoshi responds and clarifies how Bitcoin scales.
Hi Mike,
I'm glad to answer any questions you have.
There is only one global chain.
With'The existing Visa credit card network processes about 15 million Internet
purchases per day worldwide. Bitcoin can already scale much larger than that with
existing hardware for a fraction of the cost. It never really hits a scale ceiling.Â
If you're interested, I can go over the ways it would cope with extreme size.
By Moore's Law, we can expect hardware speed to be 10 times faster in 5 years
and 100 times faster in 10. Even if Bitcoin grows at crazy adoption rates,
I think computer speeds will stay ahead of the number of transactions.
Satoshi Nakamoto
The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users.
The more burden it is to run a node, the fewer nodes there will be.
Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate.
I'm the guy who went over the blockchain stuff in Satoshi's first cut of the bitcoin code. Satoshi didn't have a 1MB limit in it. The limit was originally Hal Finney's idea. Both Satoshi and I objected that it wouldn't scale at 1MB. Hal was concerned about a potential DoS attack though, and after discussion, Satoshi agreed. The 1MB limit was there by the time Bitcoin launched. But all 3 of us agreed that 1MB had to be temporary because it would never scale.
Pretty much this is saying that the network was supposed to have more capacity in the future and that the Lightning Network solution is just something the bankers sympathizers came out to sell LN to the masses who know nothing.
Too bad because smartBCH will bring the usage that will make everyone realize that Bitcoin Cash is the real Bitcoin because it is currency and money you can actually program, not to mention that apps like noise cash and read cash are already helping. The new addition is flexUSD which lets you receive interest in USD pegged coins which creates transactions in the BCH blockchain.