@Val 1 June 2021 edited

Satoshi rejected second layer solutions, Soft Forks and was clear about scaling Bitcoin on-chain.

Bitcoin P2P e-cash paper. `Oct 31, 2008` Bitcoin Whitepaper release. https://www.metzdowd.com/pipermail/cryptography/2008-October/014810.htmlhttps://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html 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."` https://satoshi.nakamotoinstitute.org/emails/cryptography/threads/1/ https://www.metzdowd.com/pipermail/cryptography/2008-November/014814.html **Satoshi** in reply gave an explanation on how Bitcoin is designed to work. https://www.metzdowd.com/pipermail/cryptography/2008-November/014815.html 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.` https://www.metzdowd.com/pipermail/cryptography/2008-November/014834.html ***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. https://en.wikipedia.org/wiki/Talk%3ACypherpunk Bitcoin v0.1 released `Jan 8, 2009` https://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html The first release of Bitcoin client. https://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html 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. https://bitcointalk.org/index.php?action=profile;u=224 https://bitcointalk.org/index.php?topic=195 `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. https://bitcointalk.org/index.php?topic=532.msg6269#msg6269 `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* https://bitcointalk.org/index.php?topic=532.msg6269#msg6269 **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. https://bitcointalk.org/index.php?topic=1347.0 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. https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366 ' 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.` https://bitcointalk.org/index.php?action=profile;u=146383 http://diswww.mit.edu/bloom-picayune/crypto/137796 https://bitcointalk.org/index.php?topic=946236.msg10388435#msg10388435 ***Ray Dillinger*** (The origin of the 1MB block limit) https://www.reddit.com/r/btc/comments/5dtny2/the_origin_of_the_1mb_block_limit_cryddit_ray/ **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. https://plan99.net/~mike/satoshi-emails/thread1.html `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