1. these are protocols used for changing the bitcoin network protocols

2. these are pro.to.cols used for chan.ging the bit.coin net.work pro.to.cols

3. dining philosophers
5 mute philosophers have 5 forks to eat their supper. their spaghetti requires 2 forks to eat. how do they share?
used to show how to coordinate concurrency.

4. dining cryptographers
3 cryptographers have dinner. the waiter tells them the bill is paid, either by one of them or the NSA. how can they tell if the NSA treated and not reveal who paid if not?
used to show how to coordinate cryptographic privacy.

5. dining bitcoiners
3 bitcoiners have a picnic. they realize there are no forks on the table. how do they select utensils everyone agrees on?
used to show how to coordinate protocol changes.

6. what is a “fork” linux cryptocurrency run whatever you like
don’t need Linus to merge on master your patches to use them
vitriolic to convince Linus
all must run same code
patches must get merged on master to work
extra vitriolic to convince world
no-one in control

7. basic types of bitcoin fork
HARD fork
soft fork
breaking change that requires the entire network to update immediately. example: increase block size to 2 MB
backwards compatible change that is only an additional rule on top of the existing rules. example: decrease block size to 0.5 MB

8. pro/con of forks HARD soft + Better Code Quality
Centralized decision making
Can’t make everyone happy
More types of changes means more arguing
Lower Code Quality
+ Can’t ensure everyone
runs latest version
“Closed Source” changes?
+ Fewer types of change
means less arguing

9. altcoin solutions tezos stellar
network has built in code amendment compatibility checking & basic voting like “nomic”.
network consensus among a “blocking set”, nodes that could stop progress. blocking set can force upgrades to the protocol.

10. Bitcoin Soft Forks

11. nop  verify upgrades
`OP_NOP<N>`  `OP_CHECK<t>VERIFY` e.g. to add SHA3… `<x> <SHA3(x)> OP_CHECKSHA3VERIFY`

12. segwit
`0 <h(x)>`  run script x with v0 UPGRADE TIME `1 <h(x)>`  run script x with v1 (if no v1 interpreter, always true)

13. How do Soft forks get made

14. after block height h, new rule
height based
after block height h, new rule

15. bip9: versionbits
Use Bitcoin’s 32-Bit version flag to deploy simultaneous soft-forks
Soft fork has a name, a bit (0-28), a start time, and a timeout
Check that 95% of the preceding 2016 blocks set the bit

16. Where Versionbits Went WRONG

17. a small misunderstanding
a big disagreement

18. BIP9 is supposed to signal readiness not votes to accept/reject
signaling vs voting
BIP9 is supposed to signal readiness not votes to accept/reject

19. if a soft fork made it to BIP9 developers assumed it would activate
signaling vs voting
if a soft fork made it to BIP9 developers assumed it would activate

20. but miners had a different idea to use it as a vote for/against
signaling vs voting
but miners had a different idea to use it as a vote for/against

21. signaling vs voting
they are supposed to vote against before it ever gets to BIP9, in the rough-consensus process

22. penny wise
pound foolish

23. it doesn’t cost miners anything to signal yes/no, or even to change
honest signaling
it doesn’t cost miners anything to signal yes/no, or even to change

24. signaling should have costs so we know signals are true
honest signaling
signaling should have costs so we know signals are true

26. if the time remaining is known behavior can be conditioned on it
timeouts make delays
if the time remaining is known behavior can be conditioned on it

27. this makes for more urgency if the time remaining runs short
timeouts make delays
this makes for more urgency if the time remaining runs short

28. this urgency gives power to those who wish to control bitcoin
timeouts make delays
this urgency gives power to those who wish to control bitcoin

29. Fixing these problems

30. spork
sorta probably a fork

31. simple spork probabilistic block filter
d > hash(hash(block)||“upgrade name”)
activate after above condition met

32. demo op_cbhv rough consensus on idea
bitcoin wants replay protection
allow invalidate txns in reorg
requires mempool rewrite

33. NOP8  OP_CHECKBLOCKATHEIGHTVERIFY
demo op_cbhv bip Draft
NOP8  OP_CHECKBLOCKATHEIGHTVERIFY
E[activation of rule] = ~6 months
h(h(block)||“cbhv”)/(2256-1) < 4e-5

34. demo op_cbhv bip feedback+rough consensus
unintended header parsing
scriptSig: <header>
scriptPubKey:
dup sha256 <height> <hash> cbhv dropX3
solution: non-sha256 hash

35. demo OP_CBHV reference implementation
bitcoin-core implements spec
v backports to v.014

36. demo OP_CBHV chain rollout
6 months
6 months N
6 months

37. by the time an upgrade is on spork rough consensus has been reached
analysis: voting
by the time an upgrade is on spork rough consensus has been reached

38. each miner can vote against by refusing to build on such blocks
analysis: voting
each miner can vote against by refusing to build on such blocks

39. but voting against may require orphaning their blocks
analysis: honesty
but voting against may require orphaning their blocks

40. but difficulty adjusts if rejected it doesn’t cost all miners forever
analysis: honesty
but difficulty adjusts if rejected it doesn’t cost all miners forever

41. but there is a large incentive for an individual to activate
analysis: honesty
but there is a large incentive for an individual to activate

42. the probabilistic filter’s algorithm is an independent trial process
analysis: timeouts
the probabilistic filter’s algorithm is an independent trial process

43. meaning it is time-invariant the expected activation is constant
analysis: timeouts
meaning it is time-invariant the expected activation is constant

44. if we set E[tactivate] = 6 mo ∀N, E[tactivate | tpassed=N] = 6 months
analysis: timeouts
if we set E[tactivate] = 6 mo ∀N, E[tactivate | tpassed=N] = 6 months

45. making people wait for activation gains a miner no influence
analysis: timeouts
making people wait for activation gains a miner no influence

46. spork extensions spork start height n-block phase delay
n-block pass enable
early-adopter rule
orphan-proof activation

47. spork start height
spork rollout can’t be before height to give time to be spork-compatible

48. enable feature n blocks after pass gives time “to adjust” after lockin
n-block phase delay
enable feature n blocks after pass gives time “to adjust” after lockin

49. enable after n blocks pass filter to reduce variance & give warning
n-block pass enable
enable after n blocks pass filter to reduce variance & give warning

50. invalidate block-reward
early-adopter rule
if activating block not compatible
invalidate block-reward
incentivize compatibility earlier

51. orphan-proof activation
activate via proof of valid-pow header
harder to prove self-orphan
reduce antagonistic orphaning 1 🚀
1😼😼
2😼😼 3 🚀