Early this year, when the debate on how to manage the meta-consensus issue of hard fork management arose I wrote an article about emergent consensus. This basically outlined the idea behind Bitcoin Unlimited‘s proposal of letting the network decide when it is collectively ready to move the block limit higher, and by what amount. At the time, I wrote that the issue was lack of good UX tools which would be able to track network participants (whether mining node, or regular full-node) votes and show them in real time. After all, emergent consensus can only work if there is a sufficient feedback loop so that the collective group decision making process can be facilitated, and overestimates and underestimates can be corrected. This is much like how a liquid market of bid/asks facilitates price discovery in every financial market since the beginning of human commerce. It is only by repeated and constant dogmatization of the block size limit as a ‘sacrosanct’ part of the protocol, has the proponents of a smaller block restricted Bitcoin been able to convince everyone that the limit cannot be changed, lest the network be subject to catastrophic attacks or instability.
Well, I’m happy to say that in the prevailing year, many such tools have been developed, and we can now very easily see what the network is signalling. For both miners and full-nodes (yes, even if you just run 1 node, your vote still counts!) if you run BitcoinUnlimited, you will be very safe (even more safe than if you run Bitcoin Core) from being forked off the main chain in the event of a hard fork. Hard forks being dangerous is now a thing of the past. While some proponents decided to enforce consensus by way of protocol limits, BU introduces the most effective tool for coming to consensus –humans. (coupled with Nakamoto PoW incentives, of course)
Wait, hard forks that will tend to self-converge on consensus? Too good to be true you say? Well believe it. The argument that hard forks are dangerous was mostly built on the tenet that humans cannot possibly come to consensus on the exact details of a block size increase (limit, lead time, activation date, flag date, dynamic vs static etc) and that the only solution was to give up and pursue soft forking strategies which only continue to build up technical debt and code complexity. But if the network nodes (all of them, mining and non-mining) could signal to each other in quasi-realtime what they were willing to accept as a block size, and at which point they would be willing to tolerate an excessive block, then a collective decision making process to determine block limit in real time can be achieved. If you need more convincing that it works check out Andrew Clifford’s article on the topic.
How to use emergent consensus:
Basically all nodes will set a signalling string as defined by BUIP001 and BUIP005. The easiest way to do this is to run BitcoinUnlimited client, but any client can implement this as long as they stick to the specification.
The signalling string will have several important fields:
- EB – Excessive block size, a size of block which exceeded, will not be relayed, or accepted as a valid tip.¹
- AD – The depth of blocks after which a previously received excessive block will be accepted
- MG – The maximum size of block that will be generated (if a mining node)
- FG – The maximum size of a block that will be generated in the future (see ABH)
- ABH – Activation block height, the block height at which the new FG generation size will be put into effect (ABH – current blockchain height) / 12000 rounded up
eg /MG2.0/EB3.5/AD4/[email protected]/
¹ Subsequent >EB blocks received after the first one in the last 6*24 blocks will be accepted.
This means that if this was a mining node, it will generate up to 2mb blocks, accept only blocks up to 3.5, unless they have been accepted 4 blocks deep, (in which case >3.5mb will be accepted). This miner is also planning to increase the size of blocks they will generate to 2.5mb sometime in the future (3 12000 block windows from now)
What should I do to make sure the network remains in consensus through a fork?
What strategy you should take depends on whether or not most of the network has upgraded to a BUIP005 emergent consensus compatible client. Once most clients are BUIP005 compliant, the risk of hard forks (based on block size) causing a consensus failure is largely eliminated.
Before the first fork: (when a minority of the nodes of the network are still running non-BUIP005 complaint clients)
Full Node (who likes bigger blocks, but will go along with majority consensus)
- Accept default Bitcoin Unlimited settings, allow blocks up to 16mb (customizable) but will go along with the majority in order to avoid a contentious fork.
Full Node (who likes smaller blocks, but will go along with majority consensus)
- Accept and only relay/validate <1mb blocks, but will accept if the majority is against them, to avoid a contentious fork
Miner Core client compatibility mode***
- Accept 1mb, generate 1mb, Accept depth 6 blocks
*** using core compatible mode until most of the network has adopted BUIP005 is necessary to avoid being aggressively forked off the network before a majority has upgraded.
Triggering the first fork
Once a sufficient number of nodes (mining and non-mining) have upgraded and signalled their readiness, a majority of the mining pools can coordinate increasing their EB higher and moving to a more flexible AD4. Once enough miners have signalled their >1mb EB, the first mining pool can change their MG >1 as long as it is a conservative value that all of the network (the Lowest common denominator of mining and non-mining nodes) has signalled that it is ready to accept.
After the first successful hard fork: BUIP005 compliant world
After most of the nodes in the network are running BUIP005 compliant clients, nodes will be able to more strongly express their opinions on what they think the max size *should* be, which will be different for every node operator and mining pool. In a BUIP005-compliant world, node owners will be watching and monitoring the network consensus/avg EB levels and AD levels. They will be able to judge for themselves what they can safely set the parameters to, whether individually, or together as a group or union in order to have their voices more strongly heard.
Mining Pool Operators
Watch, monitor network consensus tools for the average EB size that the network is reporting (among mining and non-mining nodes) and set your MG size (and optionally FG and ABH if you want to coordinate a flag day to change MG in the future) to suit your own bandwidth capabilities and risk appetite (orphan risk).
Set your EB to levels which you feel comfortable accepting given your unique bandwidth capabilities, and set your AD depending on your own resolve to enforce that EB. This should be tempered by your capacity to handle chain reorgs without affecting your clients or business adversely.
Set your EB to a level which you feel is ideologically aligned with your beliefs. Set your AD to a level at which you are willing to stand by your EB setting. Given that a solo full-node which isn’t serving as anything other than a personal view on the blockchain shouldn’t terribly sensitive to reorgs, you can likely set AD to a really large number, and simulate the current behaviour of Bitcoin core client. (never give up, never surrender!)
For details on how to set your parameters, check here.
Future documents will detail more scenarios for consensus parameters. Check BitcoinUnlimited for updates.
What can you do to help?
Node operators (mining and non-mining):
Upgrade to a BUIP005 compliant client, and signal your EB, AD, and MG.
Bitcoin Node Developer:
Patch your client to be BUIP005 compliant so as to remain in consensus in the case of a fork.
BUIP005 compliant clients:
- Bitcoin Unlimited
- others (coming soon)