Lecture 3: Scaling Bitcoin Andrew Miller SJTU 2017 Winter School on - - PowerPoint PPT Presentation

Lecture 3: Scaling Bitcoin

Andrew Miller SJTU 2017 Winter School on Cryptocurrency and Blockchain Technologies - Jan 14, 2017

3.2 transactions per second

VISA: 2000 transactions/sec on average, (2015) peak rate of 56,000 transactions/sec

Can decentralized blockchains be scaled up to match the performance of a mainstream payment processor?

Bitcoin: 3.2 transactions/sec on average (as of Jan. 2017) 3.3-7 transactions/sec max

Bitcoin faces an imminent scaling hurdle

Jan ‘16 Jan ‘17 1.0MB (HARD LIMIT)

Last updated: April 2016! (as of Jan 17)

Last updated: April 2016! (as of Jan 17)

Last updated: April 2016! (as of Jan 17)

Last updated: April 2016!

Goal of this lecture: understand the technical topics underlying the Bitcoin scaling controversy

• 1. Bitcoin’s underlying P2P communication network
• 2. Upgrade mechanisms “hard-fork” and “soft-fork”
• 3. “Off-chain” payment channels, e.g. “Lightning”

3.1: Bitcoin’s P2P Network

P2P Network consists of ~5500 nodes

P2P Network consists of ~5500 nodes

Network nodes (aka reachable/full nodes):

• bootstrap new nodes into the network
• provide service to mobile clients
• relay blocks and transactions
• sound alarms if they see invalid blocks

Nodes communicate by sending messages

PING PONG

Ping/Pong Respond within 60 seconds, or disconnected!

Nodes communicate by sending messages

(connect) VERSION VERACK VERACK VERSION

Initial Handshake / S a t

• s

h i : . 1 3 . 1 / , 4 4 7 9 2 4 b l

• c

k s

Forming connections:

• 1. Learn about new nodes by connecting to hardcoded “Seeder” nodes

$ dig seed.btc.petertodd.org

• 2. Form 8 outgoing connections
• 3. Accept up to 125 total connections (incoming and outgoing)
• 4. Propagate information about nodes to each other

Nodes communicate by sending messages

ADDR GETADDR

Propagate information about other peers ADDR messages sent in response to GETADDR, also spontaneously

ADDR

Sampled from local “addrMan” database

Nodes communicate by sending messages

GETHEADERS GETBLOCKS BLOCK HEADERS

Blockchain Download

BLOCK BLOCK BLOCK

Nodes communicate by sending messages

INV BLOCK GETDATA

Learn about new transactions

TX

Only sends GETDATA if it doesn’t have it and hasn’t already asked

I found a block!

INV(h) I N V ( h )

I found a block!

I N V ( h ) INV(h) GETDATA(h) G E T D A T A ( h )

I found a block!

I N V ( h ) INV(h) GETDATA(h) B L O C K ( b ) G E T D A T A ( h ) B L O C K ( b )

I found a block!

I N V ( h ) INV(h) GETDATA(h) B L O C K ( b ) G E T D A T A ( h ) B L O C K ( b ) INV(h) INV(h) INV(h)

I found a block!

I N V ( h ) INV(h) GETDATA(h) B L O C K ( b ) G E T D A T A ( h ) B L O C K ( b ) INV(h) GETDATA(h) INV(h) INV(h) GETDATA(h)

I found a block!

I N V ( h ) INV(h) GETDATA(h) B L O C K ( b ) G E T D A T A ( h ) B L O C K ( b ) INV(h) GETDATA(h) B L O C K ( b ) INV(h) INV(h) GETDATA(h) BLOCK(b)

I found a block!

I N V ( h ) INV(h) GETDATA(h) B L O C K ( b ) G E T D A T A ( h ) B L O C K ( b ) INV(h) GETDATA(h) B L O C K ( b ) INV(h) INV(h) GETDATA(h) BLOCK(b) I N V ( h )

Demonstration: Tiny Bitcoin Peer

• Fun for a demo - connects immediately to a random Testnet node

https://github.com/amiller/tinybitcoinpeer

• Good starting point for exploring/experimenting with the network
• For more info: https://en.bitcoin.it/wiki/Protocol_documentation

https://bitcoin.org/en/developer-reference#p2p-network

Bitcoin faces an imminent scaling hurdle

Jan ‘16 Jan ‘17 1.0MB (HARD LIMIT)

Why not just increase the limit?

Concern #1: Orphaned blocks → Decrease in power (caused by delay in propagation)

Counter argument: Many Bitcoin miners use alternative networks

Examples:

• Bitcoin Fibre http://bitcoinfibre.org/public-network.html
• Falcon http://www.falcon-net.org/

Features: Optimized topology (not random) Compression / prediction Transmits and validates in a “pipelined” fashion

Let’s do science! Idea: use empirical measurements about the P2P network to determine an appropriate block size scaling limit Miners are not the only nodes in the network. We also care about the full nodes.

I found a block!

Measuring the Bitcoin Peer-to-Peer Network

I N V ( h ) Measurement node: connects to all nodes, records messages & timestamps

Measurement Study #1

I found a block!

Measuring the Bitcoin Peer-to-Peer Network

I N V ( h ) INV(h) INV(h) INV(h) Measurement node: connects to all nodes, records messages & timestamps

Measurement Study #1

I found a block!

Measuring the Bitcoin Peer-to-Peer Network

I N V ( h ) INV(h) INV(h) INV(h) I N V ( h ) Measurement node: connects to all nodes, records messages & timestamps

Measurement Study #1

Measurement results (Propagation rate vs block size)

4.1MB in 10 minutes, reaches 90% of the nodes

Def’n: X% effective throughput (block size)/(X% block propagation delay)

Physical Limits indicate 10-100x greater capacity

Measurement Study #2

Caveats and limitations

• Measurements pertain to the network as it exists today
• Affected by protocol changes
• Affected by participation and provisioning
• Our measurements efforts could be easily attacked
• Should we even care about the P2P network?
• We’ve used # nodes as a proxy for decentralization. (Not an axiom!)
• Why 90%? Do the most poorly provisioned nodes provide relevant service?
• Miners already route around the P2P network (e.g., Bitcoin Relay Network)

A contentious scaling debate rages on

Appropriate size: 1MB, 2MB, 4MB, 8MB? Change over time? No limit at all? Measuring consensus: what’s the threshold? Who is represented? Upgrade mechanism: Hard-fork or soft-fork? Failure modes: will the p2p network grow to match policy? Underlying values: decentralization? adoption? risk vs. urgency ………….

3.1: How to Upgrade Bitcoin with “Hard Forks” and “Soft Forks”

What ways would we want to change Bitcoin?

• Increase the block size limit
• Add support for a new signature type

(Post-Quantum signatures?)

• Reverse a transaction that was made by mistake
• Add “encryption” to the P2P protocol

Let’s focus on this for now

Hard forks - the obvious way

OldTx OldTx OldTx OldTx OldTx OldTx

Time Activation day! (block number) New code deployed, with time for everyone to switch

Hard forks - the obvious way

OldTx OldTx OldTx OldTx OldTx OldTx NewTx NewTx NewTx NewTx NewTx NewTx NewTx NewTx NewTx

Activation day! (block number) New code deployed, with time for everyone to switch Time

<oldsig> | <pubkey> OP_CHECKSIGVERIFY <newsignature> | <pubkey> OP_CHECKSIGVERIFY

What happens to nodes that fail to upgrade in time?

Two conflicting blocks! Un-upgraded nodes will view a weaker and smaller chain with old-style transactions

/Satoshi:0.11.2/ - Nov 12, 2015

https://bitnodes.21.co/nodes

Let’s accept (for now) the following premises:

• Full nodes are important for maintaining the health and robustness of the Bitcoin

network

• Full nodes do not all “upgrade” quickly
• Full nodes have limited bandwidth, CPU power, etc.
• Non-upgraded full nodes must not be allowed to “fall off the main chain.”

Otherwise, they will a) be vulnerable to attacks b) form a “split currency” which threatens the economic stability

How can we “Soft Fork” to add a new signature type?

<oldsig> | <pubkey> OP_CHECKSIGVERIFY OP_UNUSED1 <newsig> | <pubkey> OP_CHECKSIGVERIFY Occasional old-style blocks, get discarded

This OpCode exists, but has no effect. In the old rules, anyone can spend this!

To recap: Hard forks are a “loosening” of the rules

• Un-upgraded full nodes view new blocks as “invalid”,

find themselves on weaker/smaller divergent chain Soft forks are a “narrowing” of the rules, but a “loosening” of conventions

• Un-upgraded nodes will still view the new chain as valid
• Un-upgraded miners waste hashpower on invalid blocks
• What happens if someone already uses “unused” opcode?

Measuring consensus with a “flag day”

• Miners signal their “support” for an upgrade. Once this support

reaches a threshold percentage, the upgrade is “committed”. If the threshold is not reached by a deadline, the upgrade is “canceled”

• After the threshold is established, there is a delay (weeks?

months?) to leave time for full nodes to upgrade as well.

SegWit (Segregated Witness): A soft-fork Bitcoin upgrade that introduces a new signature type

• Improves transaction verification performance
• Fixes “transaction malleability”, needed for future upgrades (Lightning Network)
• Modest increase in transaction capacity (up to 1.7x, depending on wallet support)
• Currently pending activation

How would we “blacklist” a particular address A?

(assume that everyone agrees to do so)

With a hard fork? After activation time, create a new transaction that transfers balance of A to some alternative recovery address With a soft fork? After activation time, any transactions that spend from A are considered invalid

How would we add “encrypted” P2P channels?

• Right now, the communication between P2P nodes is

unencrypted, unauthenticated. We may want to change this

• Is a fork required at all?

No, it does not affect the validity rules for blocks

Soft-fork to undo a failed database upgrade

• On March 11, 2013, an accidental fork occurred

A block B (height 225430) was created by version 0.8 nodes … but considered invalid by version 0.7 nodes Caused by an edge case in the database library The fork lasted 24 blocks (6 hours) Deployed an immediate “soft fork” where miners rejected the

What about decreasing the block time (2min blocks)?

• 10 minute block time is enforced by looking at timestamps of the

previous 2016 blocks, and updating the mining difficulty target

• We could hard fork to change the difficulty rule!
• Clever alternative without forks:

Every node could change its system clock to run at 5x speed!

What about printing 1M additional coins?

Seems to require a hard fork! Open question - is there a way to approximate this with soft fork?

Soft fork upgrades in Bitcoin

• Pay-to-script-hash opcode soft fork

(More efficient transactions, multisig) September, 2011

• Check-Locktime-Verify opcode

(Time lock smart contracts) June, 2015

• Check-Sequence-Verify opcode

(Relative time lock smart contracts) July 4, 2016

• SegWit → pending, has not been activated yet!

Hard Fork upgrades in other cryptocurrencies

• Ethereum has had several hard forks
• July 20th, 2016 (to cancel “The DAO” attack)
• October 18, 2016
• November 22, 2016

Mitigate DoS attacks Ethereum’s July 20 fork led to a split: ETH and ETC (Ethereum Classic) ETC is traded on exchanges, currently 1/100 size of ETH (market cap) No evidence of “un-upgraded nodes” ETC has also hard forked, Oct 25, 2016

• Monero
• Hard Fork to add new transaction type (RingCT) Jan 10, 2016

What have we learned from hard forks in practice?

• Bitcoin soft forks have been repeated several times successfully

SegWit is the first not to be adopted immediately

• Not all hard forks result in harm

This is not necessarily strong evidence that they are “safe”

• Even the “Split currency” scenario (Eth / Eth Classic) is not immediately

catastrophic

3.3: Off-Chain Payment Channels

Scalability - the traditional distributed systems view

A desirable property of a distributed system design Means: You can increase capacity by adding more hardware (more nodes) to the system. The Bitcoin protocol does not exhibit this property! All nodes verify all of the transactions. To build a scalable cryptocurrency we need a redesign

“Off-chain” protocols - the Very High Level Avoid blockchain transactions except in rare cases

Blockchain

“Off-chain” protocols - the Very High Level Avoid blockchain transactions except in rare cases

Blockchain

Parties deposit money into a special transaction called a “smart contract”

“Off-chain” protocols - the Very High Level Avoid blockchain transactions except in rare cases

Blockchain Out-of-band communication

“Off-chain” protocols - the Very High Level Avoid blockchain transactions except in rare cases

Blockchain Out-of-band communication

Dispute raised Blockchain determines outcome Blockchain executes the remedy

Unidirectional Payment Channels

Blockchain

Alice deposits $100

signature(Alice, “$1”)

Alice pays Bob by sending signatures on incrementally larger payments signature

Unidirectional Payment Channels

Blockchain

Alice deposits $100

signature(Alice, “$1”) signature(Alice, “$2”) ….

Alice pays Bob by sending signatures on incrementally larger payments signature

Unidirectional Payment Channels

Blockchain

Alice deposits $100

Alice pays Bob by sending signatures on incrementally larger payments signature

signature(Alice, “$1”) signature(Alice, “$2”) ….

At any point, Bob closes the channel by posting the largest signed message on the blockchain. If Bob aborts, Alice can claim a refund (after a time limit)

$2 $8

def refund(): assert(msg.sender == alice) assert(block.number > deadline) // only after deadline send(alice, self.balance) def finalize(signature, amount): assert(msg.sender == bob) assert(verify_signature(alice, amount, sig))) send(bob, amount) send(alice, self.balance)

Unidirectional Payment Channels (Implemented in Ethereum)

Blockchain

Lightning Network

• Implemented in Bitcoin (“Raiden”: Lightning Network in Ethereum)
• Channels support payments in two directions (Bob can pay Alice too)
• Channels can be linked to each other, forming a payment chain

Similar to credit networks

• Relies on the SegWit upgrade
• Alpha software implementation in testing
• Open questions: What will be the resulting topology? What impact on privacy?

The details get more complicated….

The future vision of off-chain scalability with Lightning:

• Most users will store significant amount of Bitcoins in payment channels,
• channels to peers that they trust
• channels to “hubs” with high connectivity
• Most transactions will occur along paths of established channels

Last updated: April 2016! (as of Jan 17)

Roughly, there are two factions*

*my perception

Bitcoin XT / Unlimited / Classic

• “big blockers”
• Volunteer nodes don’t matter, miners

have incentive to operate the system

• Bitcoin is an experiment, market

growth is most important now

• Hard forks have worked out for others
• Road map: immediate relief

Blockstream, Bitcoin Core

• “small blockers”
• Concerned about full nodes
• Risk averse, slow growth is fine
• Prefer soft forks
• Core road map: SegWit soft fork

→ Lightning Network

Conclusion

• The Bitcoin scaling controversy is only partially about “scalability”
• The debate is about short term needs, and upgrade methods
• Root disagreement about underlying priorities & assumptions
• Empirical/scientific measurements don’t clearly favor either faction
• Off-chain applications are promising approach for future

scalability