Upgrading the Bitcoin protocol - Simone Bronzini - Codemotion Rome 2018

Simone Bronzini
CTO @ Chainside
simone.bronzini@chainside.net
Upgrading a permissionless,
consensus-based distributed system

Chainside
● Making simple for eCommerce
systems to accept bitcoins
● WIP: Merchant mobile app to
receive bitcoins face-to-face
● Open source:
○ btcpy:
https://github.com/chainside/btcpy
○ btcnodejs:
https://github.com/chainside/btcnodejs

BEN Italia
● 800+ students, researchers and
professors as members
● 50+ universities involved
● 17 events organised in 2017
● 9 startups funded among by
members
● a law draft proposed

Consensus: agreeing on a global state
PERMISSIONED
● Writing permission is
granted by a central
authority
● Read permission can either
be granted to single subjects
or allowed to everyone
● Use traditional, majority
based, consensus protocols:
Paxos, PBFT, RAFT, etc.
PERMISSIONLESS
● Writing permission is paid in
scarce resources:
nodes propose values
(i.e. transactions), miners
receive proposed values, and
do proof-of-work on them
● Read permission is granted to
everyone
● Use proof-of-work.
Ongoing research on
Stake and Capacity.

Consensus: agreeing on a global state
CONs of Paxos & co:
● To have a concept of
majority, the number of
nodes must be predefined
● Who is a reader and who
is a writer must be
predefined
● Imagine it permissionless: I
can deploy thousands of
writers and subvert the
network
PROs of Bitcoin:
● Nodes and miners can come
and go, computational power
counts
● I can deploy as many nodes as
I want but I need to waste
actual computational power
to control the network
● Miners are encouraged to not
subvert the system by the
incentive of mining new
blocks

Upgrading a consensus-based system
Upgrading Paxos & co:
● shut down all nodes
(it’s permissioned, you
can do that!)
● upgrade the software
● restart the network
Upgrading Bitcoin:
● shut down all
nodes...
(uhm, how?)

Backward compatibility - 2
Transactions
produced by
old nodes
Transactions
produced by
new nodes

Backward compatibility – HOW?
In any consensus-based system,
nodes follow the same set of rules
What happens in case of an upgrade?

Backward compatibility – SCENARIO #1
Whatever happens
the network will
split!

As soon as a blue or
yellow block appears,
there is no way to
recover the split!

If the green chain is longer,
the network will not split:
SOFT FORK

As soon as a blue block
appears, there is no way to
recover the split: HARD FORK

Example of a HARD FORK
Increasing the block size:
Currently capped at 1MB
Years-long debate among bitcoiners
● Problems:
○ increases the propagation delay,
makes the network less stable
○ does not scale (imagine 1GB blocks)
○ the blockchain becomes HUGE
○ it’s a hard fork!

Upgrading the Bitcoin protocol - Simone Bronzini - Codemotion Rome 2018

Example of a SOFT FORK - 1
Restricting the way transactions are signed:
● For cryptography, Bitcoin uses ECDSA secp256k1curve
● Bitcoin transactions are identified by their hash:
1. Take the whole tx
2. Serialise it
3. Compute the hash
4. That’s the transaction identifier
● Problems:
○ Signatures are included
○ But secp256k1 signatures can be malleated!

● secp256k1 is an elliptic curve
● a signature is represented as
a point on the curve
● let’s see what can go wrong..
A representation of the SECP256k1
curve, projected over real numbers.
It is actually in the Zp
field.

Transaction A has the
following signature:
Someone can change the
signature to look like this:

New rule: from now on, we only accept
signatures on the lower end of the
curve
Notice: still
requires miners
coordination!

Miners Coordination
● Miners signal readiness to an upgrade by activating the
appropriate bits in the block header
● Example: “for this upgrade set the first 3 bits to 010”
● As soon as a strong majority of blocks have those bits
set in the header, the rest of the network knows that
the upgrade can be activated
(actually slightly more complex than this)

Possible attack: TRANSACTION MALLEABILITY
There are many more malleability vectors than the
secp256k1signature:
It is still possible to sign the same transaction twice
with different nonces
This results in two semantically equal transactions,
with different ids

Transaction Malleability: Why is it a problem?
● User withdraws from wallet
● Wallet sends transaction A with id X (i.e. hash(A) = X)
● User produces transaction A’ so that its id is Y (hash(A’) = Y)
● Y enters a block
● User goes to wallet “Hey, transaction X was never approved,
please send me another transaction”
● Wallet: “Oh, sorry, here’s a new transaction for you”

Transaction Malleability: LAYER 2
● Blocks can’t accommodate all the
transactions in the long term
● We have seen why we can’t just increase the
block size willy-nilly

SOLUTION: Off-chain transactions
block n
Tx 1
From: Alice
To: Bob

block n
Tx 1
From: Alice
To: Bob
Tx 2
From: Bob
To: Chuck
OFF-CHAIN

block n block n+1
Tx 1
From: Alice
To: Bob
Tx 2
From: Bob
To: Chuck
Tx 3
From: Chuck
To: Dave
OFF-CHAIN

block n block n+1 block n+2
Tx 1
From: Alice
To: Bob
Tx 2
From: Bob
To: Chuck
Tx 3
From: Chuck
To: Dave
Tx 20
From: Ken
To: Eve
Tx (…)
From: (…)
To: (…)
OFF-CHAIN

Tx 1
From: Alice
To: Bob
Tx 2
From: Bob
To: Chuck
Tx 3
From: Chuck
To: Dave
Tx 20
From: Ken
To: Eve
Tx 21
From: Eve
To: Bob
Tx (…)
From: (…)
To: (…)
OFF-CHAIN

block n block n+1 block n+2 block n+3
Tx 1
From: Alice
To: Bob
Tx 2
From: Bob
To: Chuck
Tx 3
From: Chuck
To: Dave
Tx 20
From: Ken
To: Eve
Tx 21
From: Eve
To: Bob
Tx 22
From: Bob
To: Ted
Tx (…)
From: (…)
To: (…)
OFF-CHAIN
OPENING CHANNEL CLOSING CHANNEL

TRANSACTION MALLEABILITY
TX: B
OUT: 0
sig
TX D
OUT: 3
sig
1 BTC
1 BTC
3 BTC
hash(TX) = K
TX: K
OUT: 0
sig
TX K
OUT: 2
sig
hash(TX) = J
TX: J
OUT: 0
sig
TX J
OUT: 1
sig
1 BTC
1 BTC
1 BTC
hash(TX) = M
2 BTC
1 BTC
TX: B
OUT: 0
sig
TX D
OUT: 3
sig
1 BTC
1 BTC
3 BTC
hash(TX) = K
TX: K
OUT: 0
SIG
TX K
OUT: 2
sig
hash(TX) = J
hash(TX) = H
TX: J
OUT: 0
sig
TX J
OUT: 1
sig
1 BTC
1 BTC
1 BTC
hash(TX) = M
2 BTC
1 BTC

From: Ted
To: Chuck
Tx B
ScriptSig B
BREAKING LAYER 2
block n block n+1
witness A
OFF-CHAIN
From: Bob
To: Ted
Tx A
ScriptSig A

From: Chuck
To: Alice
Tx C
ScriptSig C
From: Ted
To: Chuck
Tx B
ScriptSig B
BREAKING LAYER 2
witness A
OFF-CHAIN
From: Bob
To: Ted
Tx A
ScriptSig A

From: Chuck
To: Alice
Tx C
ScriptSig C
From: Ted
To: Chuck
Tx B
ScriptSig B
BREAKING LAYER 2
witness A
OFF-CHAIN
From: Bob
To: Ted
Tx A
ScriptSig A
From: Ted
To: Chuck
Tx B’
ScriptSig B’

SOLUTION: Segregated Witness
Moving signatures out of hash computation

SAVING LAYER 2
block n block n+1
witness A
From: Bob
To: Ted
Tx A
From: Ted
To: Chuck
Tx B
Witness A
Witness B
OFF-CHAIN

SAVING LAYER 2
From: Bob
To: Ted
Tx A
From: Ted
To: Chuck
Tx B
From: Chuck
To: Alice
Tx C
Witness B Witness C
OFF-CHAIN
Witness A

SAVING LAYER 2
witness A
From: Bob
To: Ted
Tx A
From: Ted
To: Chuck
Tx B
From: Chuck
To: Alice
Tx C
From: Ted
To: Chuck
Tx B
Witness A
Witness B Witness C
Witness B’
OFF-CHAIN

How to deploy SegWit?
Changing the transaction structure might
easily lead to a network split...
...unless we find a way to make the new
transactions valid also for the old nodes!

Transactions before SegWit
Tx: 2
From: Bob
To: Chuck
Tx: 1
ScriptSig
From: Alice
To: Bob
ScriptSig
Tx: 3
From: Chuck
To: Ted
ScriptSig

SegWit transactions
Tx: 3
Witness
From: Chuck
To: Ted
Tx: 1
Witness
From: Alice
To: Bob
Tx: 2
Witness
From: Bob
To: Chuck
As seen by upgraded nodes:
Tx: 3
From: Chuck
To: Ted
Tx: 1
From: Alice
To: Bob
Tx: 2
From: Bob
To: Chuck
As seen by old nodes:

Additional advantage: soft fork block size increase
Tx: 1
ScriptSig
Tx: 1
1MB Block
ScriptSig
Tx: 2
ScriptSig

Additional advantage: soft fork block size increase
Tx: 1
Witness
Tx: 1
Tx: 2
Tx: 3
Tx: 4
Witness
Witness
Witness
Witness
1MB Block

Summary
● Upgrading a consensus-based, permissionless,
system is a nightmare
● Very easy solutions to very easy problems must be
deployed in a very complex way
● Extra care needs to be taken when changing
consensus rules (they can only be restricted!)

For those who are interested -1
We propose the following thesis topics in collaboration with
Sapienza and UZH universities:
● Percolation on graphs and information diffusion in network of
blockchain users
● The essential features of a monetary system: a comparison
between traditional and blockchain-based systems
● Energy consumption in the Bitcoin system
● Monopolies formation in the Bitcoin system
● Optimal levels of decentralization in blockchain-based systems
● Scalability of on-chain and off-chain solutions
● Consensus protocols: a comparison of classical and
blockchain-based approaches

For those who are interested -2
If you like blockchain-related topics, consider joining
Blockchain Education Network
http://blockchainedu.net/

QUESTIONS?
Simone Bronzini
CTO @ Chainside
simone.bronzini@chainside.net

Upgrading the Bitcoin protocol - Simone Bronzini - Codemotion Rome 2018

More Related Content

Similar to Upgrading the Bitcoin protocol - Simone Bronzini - Codemotion Rome 2018 (20)

More from Codemotion (20)

Recently uploaded (20)

Upgrading the Bitcoin protocol - Simone Bronzini - Codemotion Rome 2018