BitcoinScaling Tradeoffs

Adam Back

We all want Bitcoin to succeed● I am speaking as an individual who cares about the success of Bitcoin

○ I have been interested in and applied researcher in ecash since 1995○ Hashcash, brands/chaum ecash library, discussions about inflation control○ Cypherpunk list discussions about b-money/bitgold etc dating back to 1998○ Zero-Knowledge Systems (company)Tor precursor, Brands (privacy focussed) ecash○ Bitcoin finally figured out a deployable formula, very exciting.

● Not a bitcoin core spokesperson, developers speak for themselves○ Developers want Bitcoin to scale and worked harder than anyone to achieve that

● Not speaking as blockstream co-founder○ Blockstream as with any company reliant on Bitcoin wants Bitcoin to scale○ Blockstream founders & employees all own Bitcoin and are invested in its success

Scaling Requirements (what-if)● Scale Requirements

○ Scale onchain & layer2 independently in parallel○ Onchain: say 2x (or better) increase per year, for next 3 years?○ Layer2: hear numbers like 100x - 10,000x (depends on recirculation) great

● Bitcoin Properties (hard requirements)○ Permisionlessness○ Fungibility / Privacy

● Functional requirements (in priority order)○ Security○ Scalable (mass deploy so everyone can enjoy)○ Reliable / predictable (user experience)○ Cheap (more use cases)

What is Bitcoin? differentiators● Bearer ecash (irreversible, unseizable, no 3rd party trust/bank)● Permissionless, Borderless, network neutral● Fungible (unfreezable, all coins universally accepted at face value)● Privacy (or too transparent, deters use)● Virtual commodity (Gold-like virtual mining etc)● Non-political unlike fiat, Bitcoin is free market money

○ No QE, inflation, central interest rate setting authority

● Money-like○ Store of value ✓✓

○ Means of exchange ✓○ Unit of account ?

Upgrade methods - difficult trade-off choiceSoft-fork Firm-fork

(soft hard-fork)Simple hard-fork

Full hard-fork

Backwards compatible

✓ x x x

fast? ✓ ✓ x (fast/risky or slow/secure)

x (fast/risky or slow/secure)

Automatic vscoordinated

✓ ✓ x full-nodes x all clients

opt-in Indirect (via miners)

Indirect(via miners)

direct direct

No SPV walletUpgrade needed

x opt-in x mandatory ✓ x mandatory

Tech debt fixes segwit ✓ depends if quick then x Motivation ✓

When might we use a (near majority) “referendum”● Controversial examples (never!)

○ Reduce privacy○ Require permission to use Bitcoin

● Uncontroversial examples○ Faster transactions, More scale○ Cheaper transaction, Bug fixes / design defect fixes

● Grey area / discussion - tradeoffs exist but we want both!○ Scale vs security / permissionless tradeoff○ (At Extreme) Centralisation tends to put most differentiating properties at risk

● Hard-forks “referendum” soft-forks for “uncontroversial”○ Most things can technically be done by soft-fork, fairly elegantly too○ Question: does having referendum for uncontroversial improvement cost more than benefit?

Why do miners prefer smaller blocks?● Orphan rate - mining is a race to propagate block in last 3 seconds.● Limit is latency, burstiness not bandwidth● 1MB is not much, but it is hard to global broadcast in 3 seconds● Workarounds today

○ Use a pool! (eg slush!)○ Relay network (custom routes, network compression, much faster medium size miners)○ Peering (large miners use peering)○ Not so good: validationless mining reduces SPV security (eg BIP66 4th july side-effect)

● What happens if orphan rate goes up?○ Miners work around it: more validationless mining, more centralised huge pools… one pool?○ But centralisation presents risk to Bitcoin’s main properties.

Underlying problem is decentralisation● Lots of discussion but bottleneck is decentralisation● Decentralisation is at low point both economic nodes & miner/pool centralised● If both mining & economic nodes decentralised we could increase scale more● Even if one of mining or economic nodes were decentralised we could scale● Problem: this is an ecosystem problem, we can address this:

○ Users buy miners○ Ecosystem companies using Bitcoin buy miners, contribute to decentralisation.○ Mine on smaller pools first○ Manufacturers sell ASICs to power users (eg group buy) not farms only, not self-mine only○ Offer better discount to power users closer to farm bulk discount?○ Start more ASIC companies or not-for-profit / open spec ASIC

● Important for bitcoin success, scale & keeping differentiating properties.

How does scale via soft-fork work● Store witness (signature) separately (sig is 60% of transaction size)● 1MB limit applies to the block (excluding the witness data)● Hence up to 2.5x scale in principle, but for tech reasons more 1.8-2x● Soft-forks have been found to be more powerful than previous thought● Can soft-fork many types of things

Software engineering & technical debt● Technical debt rule of thumb should fix bugs & design incrementally● Letting problems persist over time creates complexity & software risk● What technical debt does segregated witness fix?

○ Malleability (design defect, needs to be fixed for Lightning and other uses)○ Signature on value (more efficient for hardware wallets like trezor)○ O(n^2) hashing problem (scaling problem)○ Change build-up (scaling problem)○ Makes fraud proof possible (in whitepaper, but were limits; good for scale/security tradeoff)○ More security assurable convenient script extension mechanism (for schnorr & other)

Future Scale sketch (my opinion)● Scaling story for bitcoin is best in some years: lots of new tech and progress● Soft-fork segwit ~2MB as wallets & companies opt-in (late testing now)● 1.5-2x scale from schnorr aggregate signature (new soft-fork, this year)

○ Same physical 2MB effective block, but throughput equivalent of 3-4MB with old sig type

● IBLT/weak-blocks - Address orphan problem. Changes bottleneck from latency to bandwidth

● 2x or more HF or flexcap or equivalent to push network harder with IBLT○ Next year. There is spare bandwidth it is just bursty and latency limits

● Relies on segwit malleability fixes.○ Rough estimates of 100 - 10,000x transaction scale (compared to onchain)○ Similar security as on-chain, suitable for retail, micropayments, maybe other○ Are real bitcoin transactions, just in a coalescing write cache layer○ Instant secure/final confirmation (great for retail)