Introduction
Block Commitments
BIP Commitments
Conclusion

Changes without unanimous consent
Anthony Towns

Scaling Bitcoin, 2017

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Outline1

Introduction
Approaches to change
Model
Costs

2

Block Commitments

3

BIP Commitments

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Chain splits

What's this talk really about?

Consensus changes without unanimous consent

Consensus changes without consensus?
Really about: chain split

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Chain splits

What's this talk really about?

Consensus changes without unanimous consent

Consensus changes without consensus?
Really about: chain split

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Chain splits

What's this talk really about?

Consensus changes without unanimous consent

Consensus changes without consensus?
Really about: chain split

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Chain splits

What's this talk really about?

Consensus changes without unanimous consent

Consensus changes without consensus?
Really about: chain split

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Unanimous consent

If you do have unanimous consent, everything works great!

Developers are happy to update their software
Changes are clearly specied, and make sense
People running nodes are happy to deploy it
No security holes, upgrade challenges, extra costs
Miners are happy to deploy and signal
No hits to prot, no PoW on old chain, no split!
Economy is happy to maintain and increase value
Step 4: ... PROFIT

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Unanimous consent

If you do have unanimous consent, everything works great!

Developers are happy to update their software
Changes are clearly specied, and make sense
People running nodes are happy to deploy it
No security holes, upgrade challenges, extra costs
Miners are happy to deploy and signal
No hits to prot, no PoW on old chain, no split!
Economy is happy to maintain and increase value
Step 4: ... PROFIT

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Unanimous consent

If you do have unanimous consent, everything works great!

Developers are happy to update their software
Changes are clearly specied, and make sense
People running nodes are happy to deploy it
No security holes, upgrade challenges, extra costs
Miners are happy to deploy and signal
No hits to prot, no PoW on old chain, no split!
Economy is happy to maintain and increase value
Step 4: ... PROFIT

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Unanimous consent

If you do have unanimous consent, everything works great!

Developers are happy to update their software
Changes are clearly specied, and make sense
People running nodes are happy to deploy it
No security holes, upgrade challenges, extra costs
Miners are happy to deploy and signal
No hits to prot, no PoW on old chain, no split!
Economy is happy to maintain and increase value
Step 4: ... PROFIT

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Unanimous consent

If you do have unanimous consent, everything works great!

Developers are happy to update their software
Changes are clearly specied, and make sense
People running nodes are happy to deploy it
No security holes, upgrade challenges, extra costs
Miners are happy to deploy and signal
No hits to prot, no PoW on old chain, no split!
Economy is happy to maintain and increase value
Step 4: ... PROFIT

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Scaling and disagreements
But that only works if everyone agrees, and growth makes
agreement less likely

Disagreements over goals

eg, government buys into Bitcoin, then wants to make it hardfor criminals to use by reducing anonymitiy

Unclear what the impact of a change will be

Perfect knowledge might imply consent, but what if somepeople just don't see it?

Non-Pareto improvements

What if someone is actually made worse o? Perhaps an
upgrade makes some mining hardware less ecient...

Implementation bugs

More developers = more bugs? More developers = more bugs
found ?

Stategic disagreements

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Scaling and disagreements
But that only works if everyone agrees, and growth makes
agreement less likely

Disagreements over goals

eg, government buys into Bitcoin, then wants to make it hardfor criminals to use by reducing anonymitiy

Unclear what the impact of a change will be

Perfect knowledge might imply consent, but what if somepeople just don't see it?

Non-Pareto improvements

What if someone is actually made worse o? Perhaps an
upgrade makes some mining hardware less ecient...

Implementation bugs

More developers = more bugs? More developers = more bugs
found ?

Stategic disagreements

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Scaling and disagreements
But that only works if everyone agrees, and growth makes
agreement less likely

Disagreements over goals

eg, government buys into Bitcoin, then wants to make it hardfor criminals to use by reducing anonymitiy

Unclear what the impact of a change will be

Perfect knowledge might imply consent, but what if somepeople just don't see it?

Non-Pareto improvements

What if someone is actually made worse o? Perhaps an
upgrade makes some mining hardware less ecient...

Implementation bugs

More developers = more bugs? More developers = more bugs
found ?

Stategic disagreements

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Scaling and disagreements
But that only works if everyone agrees, and growth makes
agreement less likely

Disagreements over goals

eg, government buys into Bitcoin, then wants to make it hardfor criminals to use by reducing anonymitiy

Unclear what the impact of a change will be

Perfect knowledge might imply consent, but what if somepeople just don't see it?

Non-Pareto improvements

What if someone is actually made worse o? Perhaps an
upgrade makes some mining hardware less ecient...

Implementation bugs

More developers = more bugs? More developers = more bugs
found ?

Stategic disagreements

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Scaling and disagreements
But that only works if everyone agrees, and growth makes
agreement less likely

Disagreements over goals

eg, government buys into Bitcoin, then wants to make it hardfor criminals to use by reducing anonymitiy

Unclear what the impact of a change will be

Perfect knowledge might imply consent, but what if somepeople just don't see it?

Non-Pareto improvements

What if someone is actually made worse o? Perhaps an
upgrade makes some mining hardware less ecient...

Implementation bugs

More developers = more bugs? More developers = more bugs
found ?

Stategic disagreements

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Scaling and disagreements
But that only works if everyone agrees, and growth makes
agreement less likely

Disagreements over goals

eg, government buys into Bitcoin, then wants to make it hardfor criminals to use by reducing anonymitiy

Unclear what the impact of a change will be

Perfect knowledge might imply consent, but what if somepeople just don't see it?

Non-Pareto improvements

What if someone is actually made worse o? Perhaps an
upgrade makes some mining hardware less ecient...

Implementation bugs

More developers = more bugs? More developers = more bugs
found ?

Stategic disagreements

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Splits are cheap

Splitting is cheapchange a few lines of codechange the proof of work rules

No matter how undesirable it is, you can't stop it.
So saying Bitcoin is great as is  let's not change anything
isn't a solution either.

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Splits are cheap

Splitting is cheapchange a few lines of codechange the proof of work rules

No matter how undesirable it is, you can't stop it.
So saying Bitcoin is great as is  let's not change anything
isn't a solution either.

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Outline1

Introduction
Approaches to change
Model
Costs

2

Block Commitments

3

BIP Commitments

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Easy changes

Uncontroversial soft-forks
Simple, uncontroversial, emergency hard-fork
Long-buried, uncontroversial, hard fork
All of these work great!

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Everything else
Contentious hard-forks

People want to maintain unupgraded chain
 SPLIT
People don't have time to upgrade
Un-upgraded nodes run un-upgraded chain
 SPLIT
Un-upgraded chain remains viable
People still want it SPLIT

Quick hard-forks

Contentious User-activated Soft-forks

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Everything else
Contentious hard-forks

People want to maintain unupgraded chain
 SPLIT
People don't have time to upgrade
Un-upgraded nodes run un-upgraded chain
 SPLIT
Un-upgraded chain remains viable
People still want it SPLIT

Quick hard-forks

Contentious User-activated Soft-forks

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Everything else
Contentious hard-forks

People want to maintain unupgraded chain
 SPLIT
People don't have time to upgrade
Un-upgraded nodes run un-upgraded chain
 SPLIT
Un-upgraded chain remains viable
People still want it SPLIT

Quick hard-forks

Contentious User-activated Soft-forks

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Who decides what we getCore developers?

If it's controversial, devs will disagree too
And they don't want to decide anyway
If everyone decides to defer to them, sure! (BIP9, etc)
If not, probably not

Miners?

We'll get more data in a couple of weeks!

Nodes?

Nope, way too easy to replace them
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Who decides what we getCore developers?

If it's controversial, devs will disagree too
And they don't want to decide anyway
If everyone decides to defer to them, sure! (BIP9, etc)
If not, probably not

Miners?

We'll get more data in a couple of weeks!

Nodes?

Nope, way too easy to replace them
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Who decides what we getCore developers?

If it's controversial, devs will disagree too
And they don't want to decide anyway
If everyone decides to defer to them, sure! (BIP9, etc)
If not, probably not

Miners?

We'll get more data in a couple of weeks!

Nodes?

Nope, way too easy to replace them
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Who decides what we getCore developers?

If it's controversial, devs will disagree too
And they don't want to decide anyway
If everyone decides to defer to them, sure! (BIP9, etc)
If not, probably not

Miners?

We'll get more data in a couple of weeks!

Nodes?

Nope, way too easy to replace them
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Who decides what we get

The Economy

Provides the reason devs work
Either philosophically, or the paycheque
Pays miners

Block rewards only let you pay for electricity if Bitcoin has
value

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

How does the economy decide

The economy gives a value for Bitcoin
That is, will trade Bitcoin for goods and services

Buy Bitcoin  give goods/services, get Bitcoin
Sell Bitcoin  give Bitcoin, get goods/services

One way or another, the economy wants some sort of market
in order to exercise its power

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Outline1

Introduction
Approaches to change
Model
Costs

2

Block Commitments

3

BIP Commitments

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Change, or don't

What are we talking about?
Someone proposes a change...to consensus rules
Specic and explicit about what changes
Release new versions of software
Update nodes
Care about who owns how much according to the new rules

Everyone adopts the change

Or nobody adopts the change, and stick with the current rules
Or some people do and some don't

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Price formula

Someone proposes a change, what's the expected value of thecoin now?

c = pN · a + pE · b + pS (α + β )Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Trading coins

Can gain pricing information by trading coins (atomic swaps,
BitFinex markets, etc)
Three types of markets:

Unconditional: someone gets coins on old chain, other person
gets coins on changed chain
Split or refund: trade only takes place if a split occurs (refund
if there's only one chain, whichever that is)
Activation or refund: trade only takes place if the changed
rules activate (refund if only the old chain works)
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Trading coins

Can gain pricing information by trading coins (atomic swaps,
BitFinex markets, etc)
Three types of markets:

Unconditional: someone gets coins on old chain, other person
gets coins on changed chain
Split or refund: trade only takes place if a split occurs (refund
if there's only one chain, whichever that is)
Activation or refund: trade only takes place if the changed
rules activate (refund if only the old chain works)
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Trading coins

Can gain pricing information by trading coins (atomic swaps,
BitFinex markets, etc)
Three types of markets:

Unconditional: someone gets coins on old chain, other person
gets coins on changed chain
Split or refund: trade only takes place if a split occurs (refund
if there's only one chain, whichever that is)
Activation or refund: trade only takes place if the changed
rules activate (refund if only the old chain works)
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Trading coins

Can gain pricing information by trading coins (atomic swaps,
BitFinex markets, etc)
Three types of markets:

Unconditional: someone gets coins on old chain, other person
gets coins on changed chain
Split or refund: trade only takes place if a split occurs (refund
if there's only one chain, whichever that is)
Activation or refund: trade only takes place if the changed
rules activate (refund if only the old chain works)
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Trading coins

Can gain pricing information by trading coins (atomic swaps,
BitFinex markets, etc)
Three types of markets:

Unconditional: someone gets coins on old chain, other person
gets coins on changed chain
Split or refund: trade only takes place if a split occurs (refund
if there's only one chain, whichever that is)
Activation or refund: trade only takes place if the changed
rules activate (refund if only the old chain works)
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

But!

1 gives us

But three markets and our expected value equation
ve equations...
...in seven unknowns
So this is only enough to give us values for,,and (p · β )that chain would not be very valuable?
or just because it's not likely to exist?
(pN · a) (pE · b ) (pS · α)S

But is one of those gures low because:

1 and p

N + pE + pS = 1

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

But!

1 gives us

But three markets and our expected value equation
ve equations...
...in seven unknowns
So this is only enough to give us values for,,and (p · β )that chain would not be very valuable?
or just because it's not likely to exist?
(pN · a) (pE · b ) (pS · α)S

But is one of those gures low because:

1 and p

N + pE + pS = 1

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

But!

1 gives us

But three markets and our expected value equation
ve equations...
...in seven unknowns
So this is only enough to give us values for,,and (p · β )that chain would not be very valuable?
or just because it's not likely to exist?
(pN · a) (pE · b ) (pS · α)S

But is one of those gures low because:

1 and p

N + pE + pS = 1

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Prediction market

A prediction market can solve this and give values for the
probabilities
But not if it's denominated in Bitcoin...and probably not if it's in any other cryptocurrency(unless it's one that's not correlated with Bitcoin's value)

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Lack of price discovery
What happens if you don't have these sorts of markets?
Suppose everyone knows that a split is coming:c = α +βpS = 1 and

But there isn't a good market price for α and β (orpS β )

pS α and

Then dierent people can have dierent values for α and β 

c = α1 + β1 = α2 + β2 with α1 > α2 and β2 > β1

And after the split, people with higher values for α will buy
the old chain and vice-versa

Leading to a price rise  c = α + β > c... like we got when Bitcoin Cash forked
0Anthony Towns

1

2

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Lack of price discovery
What happens if you don't have these sorts of markets?
Suppose everyone knows that a split is coming:c = α +βpS = 1 and

But there isn't a good market price for α and β (orpS β )

pS α and

Then dierent people can have dierent values for α and β 

c = α1 + β1 = α2 + β2 with α1 > α2 and β2 > β1

And after the split, people with higher values for α will buy
the old chain and vice-versa

Leading to a price rise  c = α + β > c... like we got when Bitcoin Cash forked
0Anthony Towns

1

2

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Lack of price discovery
What happens if you don't have these sorts of markets?
Suppose everyone knows that a split is coming:c = α +βpS = 1 and

But there isn't a good market price for α and β (orpS β )

pS α and

Then dierent people can have dierent values for α and β 

c = α1 + β1 = α2 + β2 with α1 > α2 and β2 > β1

And after the split, people with higher values for α will buy
the old chain and vice-versa

Leading to a price rise  c = α + β > c... like we got when Bitcoin Cash forked
0Anthony Towns

1

2

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Lack of price discovery
What happens if you don't have these sorts of markets?
Suppose everyone knows that a split is coming:c = α +βpS = 1 and

But there isn't a good market price for α and β (orpS β )

pS α and

Then dierent people can have dierent values for α and β 

c = α1 + β1 = α2 + β2 with α1 > α2 and β2 > β1

And after the split, people with higher values for α will buy
the old chain and vice-versa

Leading to a price rise  c = α + β > c... like we got when Bitcoin Cash forked
0Anthony Towns

1

2

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Outline1

Introduction
Approaches to change
Model
Costs

2

Block Commitments

3

BIP Commitments

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Splitting is expensive

Splitting the chain has lots of negative externalities

Updating wallets, miners, node software
P2P confusion
Miners need to choose which chain to mine
Exchanges need to add new tokens, futures, ...
Dumb contracts have to be updated
People have to pay on-chain fees to rebalance
People get confused

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Splitting is expensive

Maintaining the PoW algorithm is expensive

and also somewhat quantiable!

The rst blocks until retarget have to be mined at olddiculty on both chainsreceiving about 2016 × 12.5 × (α + β ) in value for 2016 × 2 × dwork
vs 2016 × 12.5 × a value for 2016 × 1 × d work

For a given amount of hashpower, potentially a loss of an
entire two week's mining revenue

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Approaches to change
Model
Costs

Subsidising miners is expensive

If the PoW rules aren't changed, miners will strongly prefer thehigher valued chain
So to sustain the lower value chain until the value vs diculty
ratios equalise, subsidies are needed

eg, transactions paying higher fees, o-book payments tominers, miners not optimising for short-term prot

These aren't cheap  can cost over 20,000 BTC if one chain
is worth less than a quarter of the other

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Replay protection

First step to making chain splits not horrible: prevent replay
Ideally, do this generically, so that neither chain has to admitto causing the split by implementing replay protection
Ideally, get it implemented in core, so that whenever someone
random causes a chain split, everyone gets replay protection
for freeIf selling coins is easy, coins causing split have low expectedvalue, so splits aren't protable, and happen less?

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Replay protection

First step to making chain splits not horrible: prevent replay
Ideally, do this generically, so that neither chain has to admitto causing the split by implementing replay protection
Ideally, get it implemented in core, so that whenever someone
random causes a chain split, everyone gets replay protection
for freeIf selling coins is easy, coins causing split have low expectedvalue, so splits aren't protable, and happen less?

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Replay protection

First step to making chain splits not horrible: prevent replay
Ideally, do this generically, so that neither chain has to admitto causing the split by implementing replay protection
Ideally, get it implemented in core, so that whenever someone
random causes a chain split, everyone gets replay protection
for freeIf selling coins is easy, coins causing split have low expectedvalue, so splits aren't protable, and happen less?

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Replay protection

First step to making chain splits not horrible: prevent replay
Ideally, do this generically, so that neither chain has to admitto causing the split by implementing replay protection
Ideally, get it implemented in core, so that whenever someone
random causes a chain split, everyone gets replay protection
for freeIf selling coins is easy, coins causing split have low expectedvalue, so splits aren't protable, and happen less?

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Transactions commit to block history

An obvious way of preventing replay is for transactions tocommit to a particular block being in the history.
BIP 115 proposes OP_CHECKBLOCKATHEIGHTSide benet: makes recovering from some double spends
easier, even without consensus changes
Has the disadvantage that you need to explcitly specify theblock hash (or at least the ending bytes thereof )Requires two transactions to actually split the coin

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Signatures commit to block history

Instead of having an opcode, have a
SIGHASH_BLOCKCOMMIT ag.
Allow specifying a block as part of the signature

2 byte nHashOset in the signature, nLockTime from thetransaction,
block height is nLockTime − nHashOffset

Add the given block height's hash when calculating the hashto sign (as well as nHashOset)
If nHashOset is zero, use the genesis block to make locking atransaction to testnet or litecoin easy too

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Signatures commit to block history

Instead of having an opcode, have a
SIGHASH_BLOCKCOMMIT ag.
Allow specifying a block as part of the signature

2 byte nHashOset in the signature, nLockTime from thetransaction,
block height is nLockTime − nHashOffset

Add the given block height's hash when calculating the hashto sign (as well as nHashOset)
If nHashOset is zero, use the genesis block to make locking atransaction to testnet or litecoin easy too

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Signatures commit to block history

Instead of having an opcode, have a
SIGHASH_BLOCKCOMMIT ag.
Allow specifying a block as part of the signature

2 byte nHashOset in the signature, nLockTime from thetransaction,
block height is nLockTime − nHashOffset

Add the given block height's hash when calculating the hashto sign (as well as nHashOset)
If nHashOset is zero, use the genesis block to make locking atransaction to testnet or litecoin easy too

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Signatures commit to block history

Instead of having an opcode, have a
SIGHASH_BLOCKCOMMIT ag.
Allow specifying a block as part of the signature

2 byte nHashOset in the signature, nLockTime from thetransaction,
block height is nLockTime − nHashOffset

Add the given block height's hash when calculating the hashto sign (as well as nHashOset)
If nHashOset is zero, use the genesis block to make locking atransaction to testnet or litecoin easy too

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Benets

Can handle a chain split with just two pieces of information:

The height at which the chain split
The hash of the rst block on your preferred chain

Replay protection: just always commit to that block (or one
after it) when signing transactions
Wipeout protection: checkpoint that block, and don't it to bereorgedEasy to do even with SPV/light clients

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Additions
BIP 115 proposes only verifying block history back to about
52000 blocks
This way clients don't need to have even the complete set ofblock headers available to verify signatures
Can more or less duplicate this by allowing the signature to
specify the block hash explicitly:

Add the block hash to the signature, an extra 32 (or fewer)bytes of witness data
Require the specied block hash to match the actual block
hash at the given height (if known)
If the block being referenced is 52000+ blocks deep require thesignature to specify the block hashAnthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Additions
BIP 115 proposes only verifying block history back to about
52000 blocks
This way clients don't need to have even the complete set ofblock headers available to verify signatures
Can more or less duplicate this by allowing the signature to
specify the block hash explicitly:

Add the block hash to the signature, an extra 32 (or fewer)bytes of witness data
Require the specied block hash to match the actual block
hash at the given height (if known)
If the block being referenced is 52000+ blocks deep require thesignature to specify the block hashAnthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Additions
What happens if there's an orphan block?
Maybe some transactions were signed depending on the blockand become invalid

What if those transactions paid you, and you already spentthem? Argh.
nHashOffset > 100  consensus rule, transactions are only
invalidated if there's a huge reorg or there's a consensus split;
OR
nLockTime − nHashOffset + 100 < tip  standardness rule,transactions in mempool won't be invalidated but transactions
in a block might be

So perhaps add a rule:

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Replay protection 6= Price discovery

That's great for replay protection
But it doesn't really let you do price discovery in advance of a
split.
You can't commit to a trade until the rst forking blocks are
mined

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Commit to a BIP
Instead of committing to a block hash, commit to a BIP's
activation status
Same approach:

SIGHASH_BIPCOMMIT ag
Need a couple of bytes to specify a BIP
Also need a bit to specify whether the BIP should be active ininactive

Does require implementations to have a BIP number assigned,
and does require them to code that BIP number in theirimplementation.

But segwit2x doesn't have a BIP.
Well, they have BIP102...
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Commit to a BIP
Instead of committing to a block hash, commit to a BIP's
activation status
Same approach:

SIGHASH_BIPCOMMIT ag
Need a couple of bytes to specify a BIP
Also need a bit to specify whether the BIP should be active ininactive

Does require implementations to have a BIP number assigned,
and does require them to code that BIP number in theirimplementation.

But segwit2x doesn't have a BIP.
Well, they have BIP102...
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Commit to a BIP
Instead of committing to a block hash, commit to a BIP's
activation status
Same approach:

SIGHASH_BIPCOMMIT ag
Need a couple of bytes to specify a BIP
Also need a bit to specify whether the BIP should be active ininactive

Does require implementations to have a BIP number assigned,
and does require them to code that BIP number in theirimplementation.

But segwit2x doesn't have a BIP.
Well, they have BIP102...
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Commit to a BIP
Instead of committing to a block hash, commit to a BIP's
activation status
Same approach:

SIGHASH_BIPCOMMIT ag
Need a couple of bytes to specify a BIP
Also need a bit to specify whether the BIP should be active ininactive

Does require implementations to have a BIP number assigned,
and does require them to code that BIP number in theirimplementation.

But segwit2x doesn't have a BIP.
Well, they have BIP102...
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Commit to a BIP
Instead of committing to a block hash, commit to a BIP's
activation status
Same approach:

SIGHASH_BIPCOMMIT ag
Need a couple of bytes to specify a BIP
Also need a bit to specify whether the BIP should be active ininactive

Does require implementations to have a BIP number assigned,
and does require them to code that BIP number in theirimplementation.

But segwit2x doesn't have a BIP.
Well, they have BIP102...
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Making this soft-fork compatible
But what about soft-fork upgrades?
Version 0.19 comes out with BIP365 via UASF.
Everyone agrees that BIP365 support is essential.

Market valuation: cost of a pizza will be 20,000 non-BIP365
coins!

BIP365 is activated.
You make a transaction signed with SIGHASH_BIPCOMMIT
365 active.
If someone is still running 0.18 do they see your transaction as
valid?

No? Then it's not a soft-fork
Yes? How does 0.18 know BIP 365 is active when it wasn't
even written yet?
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Making this soft-fork compatible
But what about soft-fork upgrades?
Version 0.19 comes out with BIP365 via UASF.
Everyone agrees that BIP365 support is essential.

Market valuation: cost of a pizza will be 20,000 non-BIP365
coins!

BIP365 is activated.
You make a transaction signed with SIGHASH_BIPCOMMIT
365 active.
If someone is still running 0.18 do they see your transaction as
valid?

No? Then it's not a soft-fork
Yes? How does 0.18 know BIP 365 is active when it wasn't
even written yet?
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Making this soft-fork compatible
But what about soft-fork upgrades?
Version 0.19 comes out with BIP365 via UASF.
Everyone agrees that BIP365 support is essential.

Market valuation: cost of a pizza will be 20,000 non-BIP365
coins!

BIP365 is activated.
You make a transaction signed with SIGHASH_BIPCOMMIT
365 active.
If someone is still running 0.18 do they see your transaction as
valid?

No? Then it's not a soft-fork
Yes? How does 0.18 know BIP 365 is active when it wasn't
even written yet?
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Making this soft-fork compatible
But what about soft-fork upgrades?
Version 0.19 comes out with BIP365 via UASF.
Everyone agrees that BIP365 support is essential.

Market valuation: cost of a pizza will be 20,000 non-BIP365
coins!

BIP365 is activated.
You make a transaction signed with SIGHASH_BIPCOMMIT
365 active.
If someone is still running 0.18 do they see your transaction as
valid?

No? Then it's not a soft-fork
Yes? How does 0.18 know BIP 365 is active when it wasn't
even written yet?
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Making this soft-fork compatible
But what about soft-fork upgrades?
Version 0.19 comes out with BIP365 via UASF.
Everyone agrees that BIP365 support is essential.

Market valuation: cost of a pizza will be 20,000 non-BIP365
coins!

BIP365 is activated.
You make a transaction signed with SIGHASH_BIPCOMMIT
365 active.
If someone is still running 0.18 do they see your transaction as
valid?

No? Then it's not a soft-fork
Yes? How does 0.18 know BIP 365 is active when it wasn't
even written yet?
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Still able to be messed with
If an implementation knowns (and implements) the BIP's
rules, everything is ne.
If it doesn't, it needs to track unknown BIPs by what

If a block includes a signature saying a BIP is activated, thensignatures they see:no other transaction in the block can assert it's inactive
no transaction in any later block can assert it's inactive

If a block includes a signature saying a BIP is inactive, thenno other transaction in the same block can want it to be active

But this would let miners confuse things:

BIP 720 is written and sounds good to miners, but isn't
implemented anywhere
Miners mine a few transactions with SIGHASH_BIPCOMMIT
BIP720 active
When implementations come out, trying to avoid BIP 720
forces a huge reorg
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Still able to be messed with
If an implementation knowns (and implements) the BIP's
rules, everything is ne.
If it doesn't, it needs to track unknown BIPs by what

If a block includes a signature saying a BIP is activated, thensignatures they see:no other transaction in the block can assert it's inactive
no transaction in any later block can assert it's inactive

If a block includes a signature saying a BIP is inactive, thenno other transaction in the same block can want it to be active

But this would let miners confuse things:

BIP 720 is written and sounds good to miners, but isn't
implemented anywhere
Miners mine a few transactions with SIGHASH_BIPCOMMIT
BIP720 active
When implementations come out, trying to avoid BIP 720
forces a huge reorg
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Still able to be messed with
If an implementation knowns (and implements) the BIP's
rules, everything is ne.
If it doesn't, it needs to track unknown BIPs by what

If a block includes a signature saying a BIP is activated, thensignatures they see:no other transaction in the block can assert it's inactive
no transaction in any later block can assert it's inactive

If a block includes a signature saying a BIP is inactive, thenno other transaction in the same block can want it to be active

But this would let miners confuse things:

BIP 720 is written and sounds good to miners, but isn't
implemented anywhere
Miners mine a few transactions with SIGHASH_BIPCOMMIT
BIP720 active
When implementations come out, trying to avoid BIP 720
forces a huge reorg
Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Limited protection

Can x this by having implementations update regularly, andforbid activation of unknown BIPs while they're current.
0.18 comes out: for six months, it rejects any block that
contains a transaction with a signature requiring any unknown
BIP to be activated; but then relaxes this rule.
Six months after 0.18 comes out, 0.19 comes out: for six
months, it similarly rejects commitments to unknown BIPs
being active
And so on.

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Limited protection

Can x this by having implementations update regularly, andforbid activation of unknown BIPs while they're current.
0.18 comes out: for six months, it rejects any block that
contains a transaction with a signature requiring any unknown
BIP to be activated; but then relaxes this rule.
Six months after 0.18 comes out, 0.19 comes out: for six
months, it similarly rejects commitments to unknown BIPs
being active
And so on.

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Limited protection

Can x this by having implementations update regularly, andforbid activation of unknown BIPs while they're current.
0.18 comes out: for six months, it rejects any block that
contains a transaction with a signature requiring any unknown
BIP to be activated; but then relaxes this rule.
Six months after 0.18 comes out, 0.19 comes out: for six
months, it similarly rejects commitments to unknown BIPs
being active
And so on.

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Limited protection

Properties:

Unknown BIPs are rejected by current versions of node
software at all times
New BIPs are allowed by the latest updates (which know aboutthem) and older versions (because they've relaxed the rules)
Software releases must be somewhat regularThough only need a minor release bumping the timeout
Soft-fork deployments must have at least a six month period
between specication and explanation
Hard-forks can happen at any time, though

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Limited protection

Properties:

Unknown BIPs are rejected by current versions of node
software at all times
New BIPs are allowed by the latest updates (which know aboutthem) and older versions (because they've relaxed the rules)
Software releases must be somewhat regularThough only need a minor release bumping the timeout
Soft-fork deployments must have at least a six month period
between specication and explanation
Hard-forks can happen at any time, though

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Limited protection

Properties:

Unknown BIPs are rejected by current versions of node
software at all times
New BIPs are allowed by the latest updates (which know aboutthem) and older versions (because they've relaxed the rules)
Software releases must be somewhat regularThough only need a minor release bumping the timeout
Soft-fork deployments must have at least a six month period
between specication and explanation
Hard-forks can happen at any time, though

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Limited protection

Properties:

Unknown BIPs are rejected by current versions of node
software at all times
New BIPs are allowed by the latest updates (which know aboutthem) and older versions (because they've relaxed the rules)
Software releases must be somewhat regularThough only need a minor release bumping the timeout
Soft-fork deployments must have at least a six month period
between specication and explanation
Hard-forks can happen at any time, though

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Price discovery via BIP commitment
This is enough to establish Bitcoin-vs-Bitcoin markets
Which is enough to establish conditional valuations (ie,pE b, etc).

pN a,

It can be done mostly trustlessly
Markets oering a refund need some way to distinguishwhether alternative consensus rules have activated or a chain
split has occurred:

Trusted oracle
Crypto proof of split/activation
Economic incentive  each participant puts up a ransom, r ,which they lose if they lie

Provided the other chain is worth f (r )% of this coin's value,cheating isn't protable

No need for a trusted exchange, however!

Anthony Towns

Changes without unanimous consent

Introduction
Block Commitments
BIP Commitments
Conclusion

Conclusion

Consensus on consensus is hard, and getting harder.
Splits are easy.
We can make splits hurt less.
We can let the economy make better decisions on splits.
Thanks for listening!

Anthony Towns

Changes without unanimous consent