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

1 357
Avatar for Val
Written by
3 years ago

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

10
$ 24.34
$ 5.82 from @TheRandomRewarder
$ 5.00 from @majamalu
$ 5.00 from @fadcapital
+ 5
Avatar for Val
Written by
3 years ago

Comments

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.

$ 0.00
3 years ago