Part 1
The idea behind Bitcoin Unlimited is to allow users to adjust their own MAX_BLOCK_SIZE value, in order for the network wide max block size to be a result of the emergent consensus of end users rather than the decision of a full node implementation development team.
I believe that the emergent consensus on the max block size is the only value that is likely to be optimal, and have been promoting this since October last year:
https://www.reddit.com/r/bitcoinxt/comments/3nwnp2/theymos_personalized_block_size_limit_miner/
Ironically, the first person that I know of who proposed this idea was Theymos, of /r/bitcoin censorship infamy.
However, for the vision of emergent consensus on the max block size value to be fully realized, individualized control over the max block size via a GUI input is not enough. Bitcoin Unlimited needs to factor in a key element of consensus rule changes: Schelling points. A Schelling point is the most common chosen value by participants who are not in communication. In the absence of communication, the Schelling Point for Bitcoin Unlimited will always be the current limit. No miner will risk raising their limit unless they receive reliable communication indicating that most nodes will accept blocks that accept such a limit.
This brings us to the need to communicate to coordinate hard limit changes. As long as the communication channels used by Bitcoin economy participants are under the control of trusted third parties (TTP), communication cannot be guaranteed to be without censorship. The recent /r/bitcoin debacle is a perfect demonstration of the weakness of TTP intermediated communication in guaranteeing this quality. Therefore, as long as the current communication situation persists, the max block size cannot be guaranteed to be a result of an emergent consensus, even if all users switch to clients that have user configurable settings for the Excessive Block Size (EBS) and Excessive Acceptance Depth (EAD).
Accordingly, I contend that for Bitcoin Unlimited to work as intended, participants need to be empowered to signal their preferred max block size to each other through messages published on the blockchain, which is the only trust-minimized and Sybil-proof communication channel that is known to exist, and displayed on client GUIs. There are already some well-developed proposals on the Bitcoin Unlimited forum on methods to signal individual node max block size policy through the blockchain and through the Bitcoin P2P network, and the method proposed here is fully compatible with these methods, and can serve to complement them.
Proposed signaling method
A 4-bit message (max block size signal, or MBSS), encodes the preferred max block size and fully validating node status of a Bitcoin economy participant, which can be either a miner or a user. The most significant bit of the 4-bit message is a flag to indicate whether the user is using a fully validating node to generate the transaction. A 0b1 value is suggested as the flag to indicate fully validating node status.
The remaining bits are reserved for an unsigned 3-bit integer (0..7) (MBSS integer). The values and the preferences they are signalling are the following:
0: no-signal. This indicates that the participant is not signalling either their preference on the max block size, or their fully validating node status. All other bit fields in the MBSS are ignored in this case.
1: reduction of max block size by 7.5 percent
2: reduction of max block size by 5 percent
3: reduction of max block size by 2.5 percent
4: current max block size
5: increase in max block size by 2.5 percent
6: increase in max block size by 5 percent
7: increase in max block size by 7.5 percent
Miners
Miners refers to participants that generate blocks. Miners embed their MBSS in the Version field of the block header, or in the scriptSig field of the Coinbase transaction (which location makes more sense is outside the scope of this proposal. For the remainder of this proposal, the location where the MBSS is embedded will be referred to as the 'Miner field').
Users
Users refers to Bitcoin economy participants that generate non-Coinbase transactions. Users embed their MBSS in the nSequence field of transactions they generate.
GUI display
The full node client displays a visualization of the aggregate max block size preferences of miners and users over the last 3,000 blocks, and network health graphs to provide miners and users with information pertinent to the max block size to help them make an informed decision on which max block size value to signal a preference for. See graphical depiction:
Preference Visualization Rectangles
Four preference visualization rectangles (PVRs) are displayed on the GUI: two for miners and two for user. For both miners and users, one of the rectangles shows the preference for a max block size increase, and one shows the preference for a max block size decrease.
The two max block size increase PVRs show the economic stake signalling a preference for each of the following four max block size values: the current value, the current value + 2.5 percent, the current value + 5 percent, and the current value + 7.5 percent
The two max block size decrease PVRs show the economic stake signalling a preference for each of the following four max block size values: the current value, the current value - 2.5 percent, the current value - 5 percent, and the current value - 7.5 percent
The current max block size value is identical between the increase and decrease PVRs. For example, if the user increase PVR indicates 95% support for the current max block size value, then the user decrease PVR will also indicate 95% support for the current max block size value. The degree of support for the current max block size value is included in both PVRs solely for producing a consistent visualization of the data.
The PVRs display the support for a particular max block size value change, inclusive of preference for greater magnitude max block size changes. For example, if 25 percent of economic stake is signalling a preference for a 2.5 percent increase in the max block size value, and 50 percent is signalling a preference for a 5 percent increase in the max block size value, the 2.5 percent increase sub-rectangle will display the combined preference for the 2.5 and 5 percent max block size increases, so a 75 percent preference. This is based on the assumption that Bitcoin economy participants that prefer a particular magnitude change in the max block size will prefer smaller magnitude changes in the max block size in the direction of their preferred change, over no change.
The economic stake signalling a preference in the miner PVRs refers to the percentage of the last 3,000 blocks that contain an MBSS in the Miner field signalling a preference for a particular max block size value.
The economic stake signalling a preference in the user PVRs refers to the percentage of the Bitcoin Days Consumed (BDC) in the last 3,000 blocks that were spent by transactions containing an MBSS in the nSequence field signalling a preference for a particular max block size value. To reduce the potential of a single very old and large value UTXO being consumed and causing a spike in the percentage of BDC signalling preference for a particular max block size value, the amount of coinAge used in calculating the BDC of a transaction is capped at one year.
The idea behind Bitcoin Unlimited is to allow users to adjust their own MAX_BLOCK_SIZE value, in order for the network wide max block size to be a result of the emergent consensus of end users rather than the decision of a full node implementation development team.
I believe that the emergent consensus on the max block size is the only value that is likely to be optimal, and have been promoting this since October last year:
https://www.reddit.com/r/bitcoinxt/comments/3nwnp2/theymos_personalized_block_size_limit_miner/
Ironically, the first person that I know of who proposed this idea was Theymos, of /r/bitcoin censorship infamy.
However, for the vision of emergent consensus on the max block size value to be fully realized, individualized control over the max block size via a GUI input is not enough. Bitcoin Unlimited needs to factor in a key element of consensus rule changes: Schelling points. A Schelling point is the most common chosen value by participants who are not in communication. In the absence of communication, the Schelling Point for Bitcoin Unlimited will always be the current limit. No miner will risk raising their limit unless they receive reliable communication indicating that most nodes will accept blocks that accept such a limit.
This brings us to the need to communicate to coordinate hard limit changes. As long as the communication channels used by Bitcoin economy participants are under the control of trusted third parties (TTP), communication cannot be guaranteed to be without censorship. The recent /r/bitcoin debacle is a perfect demonstration of the weakness of TTP intermediated communication in guaranteeing this quality. Therefore, as long as the current communication situation persists, the max block size cannot be guaranteed to be a result of an emergent consensus, even if all users switch to clients that have user configurable settings for the Excessive Block Size (EBS) and Excessive Acceptance Depth (EAD).
Accordingly, I contend that for Bitcoin Unlimited to work as intended, participants need to be empowered to signal their preferred max block size to each other through messages published on the blockchain, which is the only trust-minimized and Sybil-proof communication channel that is known to exist, and displayed on client GUIs. There are already some well-developed proposals on the Bitcoin Unlimited forum on methods to signal individual node max block size policy through the blockchain and through the Bitcoin P2P network, and the method proposed here is fully compatible with these methods, and can serve to complement them.
Proposed signaling method
A 4-bit message (max block size signal, or MBSS), encodes the preferred max block size and fully validating node status of a Bitcoin economy participant, which can be either a miner or a user. The most significant bit of the 4-bit message is a flag to indicate whether the user is using a fully validating node to generate the transaction. A 0b1 value is suggested as the flag to indicate fully validating node status.
The remaining bits are reserved for an unsigned 3-bit integer (0..7) (MBSS integer). The values and the preferences they are signalling are the following:
0: no-signal. This indicates that the participant is not signalling either their preference on the max block size, or their fully validating node status. All other bit fields in the MBSS are ignored in this case.
1: reduction of max block size by 7.5 percent
2: reduction of max block size by 5 percent
3: reduction of max block size by 2.5 percent
4: current max block size
5: increase in max block size by 2.5 percent
6: increase in max block size by 5 percent
7: increase in max block size by 7.5 percent
Miners
Miners refers to participants that generate blocks. Miners embed their MBSS in the Version field of the block header, or in the scriptSig field of the Coinbase transaction (which location makes more sense is outside the scope of this proposal. For the remainder of this proposal, the location where the MBSS is embedded will be referred to as the 'Miner field').
Users
Users refers to Bitcoin economy participants that generate non-Coinbase transactions. Users embed their MBSS in the nSequence field of transactions they generate.
GUI display
The full node client displays a visualization of the aggregate max block size preferences of miners and users over the last 3,000 blocks, and network health graphs to provide miners and users with information pertinent to the max block size to help them make an informed decision on which max block size value to signal a preference for. See graphical depiction:
Preference Visualization Rectangles
Four preference visualization rectangles (PVRs) are displayed on the GUI: two for miners and two for user. For both miners and users, one of the rectangles shows the preference for a max block size increase, and one shows the preference for a max block size decrease.
The two max block size increase PVRs show the economic stake signalling a preference for each of the following four max block size values: the current value, the current value + 2.5 percent, the current value + 5 percent, and the current value + 7.5 percent
The two max block size decrease PVRs show the economic stake signalling a preference for each of the following four max block size values: the current value, the current value - 2.5 percent, the current value - 5 percent, and the current value - 7.5 percent
The current max block size value is identical between the increase and decrease PVRs. For example, if the user increase PVR indicates 95% support for the current max block size value, then the user decrease PVR will also indicate 95% support for the current max block size value. The degree of support for the current max block size value is included in both PVRs solely for producing a consistent visualization of the data.
The PVRs display the support for a particular max block size value change, inclusive of preference for greater magnitude max block size changes. For example, if 25 percent of economic stake is signalling a preference for a 2.5 percent increase in the max block size value, and 50 percent is signalling a preference for a 5 percent increase in the max block size value, the 2.5 percent increase sub-rectangle will display the combined preference for the 2.5 and 5 percent max block size increases, so a 75 percent preference. This is based on the assumption that Bitcoin economy participants that prefer a particular magnitude change in the max block size will prefer smaller magnitude changes in the max block size in the direction of their preferred change, over no change.
The economic stake signalling a preference in the miner PVRs refers to the percentage of the last 3,000 blocks that contain an MBSS in the Miner field signalling a preference for a particular max block size value.
The economic stake signalling a preference in the user PVRs refers to the percentage of the Bitcoin Days Consumed (BDC) in the last 3,000 blocks that were spent by transactions containing an MBSS in the nSequence field signalling a preference for a particular max block size value. To reduce the potential of a single very old and large value UTXO being consumed and causing a spike in the percentage of BDC signalling preference for a particular max block size value, the amount of coinAge used in calculating the BDC of a transaction is capped at one year.