Sidechain Scaling“Bitcoin Fission”
Scaling via strategy, not physics
Paul Sztorc
paul.sztorc@bloq.com
Saturday Oct 8, 2016

Pizza• If we cut a pizza into more slices,does it weigh any less?

Agenda1. Overview & Problem
2. Basics & Definitions
3. Inter-Chain Harms (Are Negligible)
4. Chain II is More Secure Than It Appears
5. Benefits of Fission

The Concept: Teamwork, Not Copies
1.00(2.00)

Base(Segwit)
.25
(.50)

1. Create Sidechain
2. Shrink Mainchain

2.75(5.50)

Small BTC (Main)
Nodes: Many, Cheap, Private
Tx Fees: HigherLarge BTC (Side)
Few, Expensive, PublicLower

Mode:

VISA / Payment network

Money / settlement

Insecure…intentionally… (diff security).

Problem(s) This Talk Addresses
1. Declining Node Count– Complaints about disk space, time to sync, bandwidth
What motivates people
hogging, risk, reduced privacy.

2. Loss of Permissionless Innovation!

to run full nodes?

– Bitcoin is conservative by design, but this goesagainst ethos of open source / individual freedom.
– Misallocation of Dev Resources

3. Throughput (it increases)•Does Not Improve:– Physics of Info-XferFungibility
Lightning– “Miner Centralization” (abil. censoring, 51% attack)What are sidechains?
• An “” is a blockchain with “alt” rules and:)abilities. (Different cost/benefit tradeoff.)–“” = alt-chain +new monetary network.
–“” = alt-chain + inherits monetary network.
– (Note that mone. networks are inherently adversarial.):(• Open Questions– Is a sidechain“Bitcoin”? Essentialism– To what extent are“we” responsiblefor them?

What is Drivechain?
Merge-minedMAsymmetricSS

S

S

Contracts,
Payments,
Services7

04B4697D5319B8B0E461BE624EAD61331
What is Drivechain?
CA613216F061D2533490ABBB71616A0

M
SS

S

SContracts,
Payments,
Services8

04B4697D5319B8B0E461BE624EAD61331
What is Drivechain?
CA613216F061D2533490ABBB71616A0

M
Side-to-Main are Bundled, and “ACKed”
S

S

S

S

by miners.

Security
All attacks *must* take a very
inconvenient form:• Slow• DeliberateContracts,
Payments,• Un-ignorable
Services
9Great News: Costs are “Opt In”• Network: “Opt-In” Soft Fork
• Users: Option to use Sidechain– “checkbox”, if want cheaper txns
& higher node costs.

• Miners: *Must* upgrade (sf +mm.sc – if sidechain generates
tx fee revenues).
– Cost is tiny. Pays for itself.
– Other centralization pressures
way more relevant (spv, spy, smp).
– Talk on sidechain risks / miner interactivity.
Safe to ignore this.

Great News: Costs are “Opt In”• Network:“Opt-In”
Sidechainused as aSoft
large,Forklightning hub…
• Users: Option
to use Sidechain…that is itself a BTC blockchain.

– “checkbox”, if want cheaper txns
& highercosts. layer.
Slowlysyncsnodeto settlement• Miners: *Must* upgrade (sf +mm.sc – if sidechain generates
revenues).
– Cost is tiny. Pays for itself.
– Other centralization pressures
way more relevant (spv, spy, smp).
– Talk on sidechain risks / miner interactivity.
Safe to ignore this.

End of 1st HalfWhat about this?
If risks = 0, but what if benefits = 0?!
(Pointless if Large BTC dies, or breaks)!

Very Un-Bitcoin likeIs this “just” PayPal, Venmo, etc?

Q: What is the nature of ourweakness to having few nodes?

Sidechains + Lightning Network

Point 1: The BTC on “small” are instantaneouslyinterchangeable for the BTC on “large”.

Sidechains + Lightning Network“R”

Chain 1

Chain 2“N”

Why Do We Want
Many/Cheap Nodes?
What is the nature of our weakness
to having few/expensive nodes?

1. Redundancy – Avoid a central point of failure.
2. Security – Discourage / overwhelm attackers(“Where should I aim?”)
3. Sovereignty – “your” money, “your” contracts...“your” node.
How can {++} help with this?

Surviving a Fatal Attack• Say an attack disables all of the nodes.
– Typically: existential• OK, say an attack disables the large nodes only.
– Worst case: All “Large BTC” are paused.
– Best case: Full refund on “small BTC”
• Channels are off-chain.
• [1] miners buy BTC with btc.
• [2] miners pay themselves• Possible “emergencyblocks”– ultra-small– Within Mainchain coinbase

Surviving a Fatal Attack• Say an attack disables all of the nodes.
– Typically: existential• OK, say an attack disables the large nodes only.
– Worst case: All “Large BTC” are paused.
– Best case: Full refund on “small BTC”
Channels
are off-chain.
-- Realistic case: (Probably) 95% of•users
get a refund,at cost 1-2%.

• [1] miners sell BTC for btc.
• [2] miners pay themselves• Possible “emergencyblocks”– ultra-small
Result: Attack is pointless, largely no pointin bothering with attacking.
– Within Mainchain coinbase

(Potential) Synergy• “Weighing the pizza” -- staticand solitary, ignores strategicinteraction . Need Reactive /Organic metaphor.
• Better metaphor: weed thatwon’t die.

sunsafety• Small BTC + Large BTC (+ Lightning ) =• Regeneration = Attack’s Wont Succeed = Attacks costly, andembarrassing.
• Conclusion: can take “large” risks, but only pay “small costs”

Game Changer – Metaphors• US Legal– Global BitTorrent (VPN allows sophisticatedconsumers to breach copyright laws, therefore nonVPN unsophisticated breaches are often tolerated).
– Alcohol Prohibition (opposite – total ban wasattempted, but it backfired resulting in large black
market sales, rise of mafia, etc)

• Biology– Dominance Hierarchies– Costly Signaling (Handicap Principle)• Psychology– Learned Helplessness (saving effort, in situations
which are perceived as hopeless).

Conclusion: Benefits
1. Scale by factor of 3 (2  6).
2. Laboratory for “Scale Experiments”.
3. Only hope for decreasing size(recovering nodes).
4. Improvements in tech increase bothsecurity & scale simultaneously.
5. My Ulterior Motives
1. Sidechains (Anti-Scam)
2. HivemindThank You!!
Paul Sztorc

Appendix

Game Changer
Game 1bigattack

small

don’t

more BTC
some BTCBTC Dead :-(BTC Dead >-)BTC Alive :-(failed attack : /Game Changer
Game 1 (No Fission)

bigattackGame 2 (Fission)

small

big

attack

don’t
small

small

don’t

Game Changer
Game 1 (No Fission)

bigattackGame 2 (Fission)

small

don’t

bigattack

small

don’t

Node
Centralization(“CONOP”)

Tech Progress
Not happy with VISA / Bank of America/ etc  Option to Use Bitcoin

Not happy with Electrum / Coinbase /etc, (Payments are Large?)  Option to
Run a Full NodeJuly, 2010

Intolerable
Tolerable

Capacity of the P2P NetworkThroughput

Is min(y) optimal…or should we tradeoff…
Node Centralization(“CONOP”)
𝑡𝑒𝑐ℎ1

faster CPUs
libsecp256k1
mimblewimble

𝑡𝑒𝑐ℎ2July, 2010

All tech improvements
contribute directly to improved
decentralization.

Throughput

…or take min(Y) AND max(X).
• Keep “Small BTC” the same size.
• Keep “Large BTC” as large as possible.
Benefits

Costs

Small:

Small

Small

Large:

Large

Large

Both:

Large

Small