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 idea since
October of last year.
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 methodA 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
MinersMiners 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').
UsersUsers refers to Bitcoin economy participants that generate non-Coinbase transactions. Users embed their MBSS in the nSequence field of transactions they generate.
GUI displayThe 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 RectanglesFour 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.
Network Health GraphsTo the right of the four preference visualization rectangles, two graphs show changes over the last 3000 blocks in the average transaction fee and the centralization level of tx generation, respectively.
average transaction fee
The average transaction fee (ATF) of each block B[N] is calculated by the following steps:
1. A BDC weighted median per kB transaction fee, or rawMed, is calculated for B[N]. This is done by transactions in B[N] being ordered by per kB tx fee, and the BDC-weighted median being returned.
2. The effective median per kB transaction fee, or effMed, is calculated by taking the smaller of the two: the ATF of the previous block multiplied by 2, or the rawMed of the current block. In pseudocode:
B[N].effMed = min(B[N-1].ATF * 2, B[N].rawMed);
3. The ATF of B[N] is calculated by taking the moving average of the effMed values of the 100 previous blocks, current block inclusive, or in pseudocode:
B[N].ATF = sum(B[(N-99)..N].effMed)/100;
centralization level of tx generation
The average centralization level (ACL) of each block B[N] is calculated by the following steps:
1. The total BDC of all TxIn in B[N] flagged as containing a MBSS and with the fully validating node (FVN) flag of the MBSS set to false is calculated. In pseudocode:
nfvnSum = 0
foreach (tx, B[N].Txs)
foreach (txin, tx.vin) {
if (txin.MBSS.int > 0 && txin.MBSS.FVN == false)
nfvnSum += calcBDC(txin)
}
}
2. The total BDC of all TxIn in B[N] flagged as containing a MBSS is calculated. In pseudocode:
sum = 0
foreach (tx, B[N].Txs)
foreach (txin, tx.vin) {
if (txin.MBSS.int > 0)
sum += calcBDC(txin)
}
}
3. The CL of B[N] is calculated as a percentage of the BDC of the MBSS-containing TxIn in B[N] that belongs to TxIn with the FVN flag set to false. In pseudocode:
B[N].CL = nfvnSum/sum * 100
4. The ACL of B[N] is calculated by taking the moving average of the CL values of the 100 previous blocks, current block inclusive
Reduce fee/centralization pressure buttonsTo the left of each network health graph is a button letting the user adjust their preferred max block size value to attempt to reduce fee/centralization pressure.
If their mouse hovers over the 'reduce fee pressure' button to the left of the Average Transaction Fee graph, a pop-up message appears stating that fee pressure declines with increases in the max block size, and that they can attempt to influence the network to increase the max block size value by signalling a preference for an increase in the max block size value. A warning also appears that increases in the max block size increase centralization pressure. To the left of this message, the various max block size values that the user can select a preference for are presented, and selectable.
If their mouse hovers over the 'reduce centralization pressure' button to the left of the Average Centralization Level graph, a pop-up message appears stating that centralization pressure declines with decreases in the max block size, and that they can attempt to influence the network to decrease the max block size value by signalling a preference for a decrease in the max block size value. A warning also appears that decreases in the max block size increase transaction fee pressure. To the left of this message, the various max block size values that the user can select a preference for are presented, and selectable.
Max Block Size ChangeThe base max block size (BMBS) defines the 'current max block size value' in the PVRs at the beginning of a 3,000 block period. The BMBS is reset every 3,000 blocks. If at the end of a 3,000-block period, the max block size (MBS) is different than the BMBS, the BMBS will change to match the MBS.
max block size increase
If a miner creates a block that is larger than the MBS and the node's EBS, the wallet GUI will give the user the option to accept the block if:
* The user increase PVR indicates >= 80% of BDC and the miner increase PVR indicates >= 50% of hashpower have signalled a preference for the MBS
OR
* The user increase PVR indicates >= 50% of BDC and the miner increase PVR indicates >= 80% of hashpower have signalled a preference for the MBS
A user or miner accepting a block with a size exceeding the prevailing MBS does not result in the user/miner's MBSS changing, but it will update their EBS to the smallest PVR increment that will accept the block.
For example, if the prevailing MBS is 1 megabyte, and a miner generates a block that is 1.01 megabyte, users and miners that opt in to accepting the block will see their EBS automatically set to 1.025 MB, which is the BMBS (1 megabyte) + 2.5% of BMBS (0.025 megabyte), and therefore subsequently will automatically accept blocks of any size up to 1.025 MB.
max block size decrease
If at the end of a 3,000 block period, the following is true:
* The user decrease PVR indicates >= 80% of BDC and the miner decrease PVR indicates >= 50% of hashpower have signalled a preference for a MBS that is below the BMBS
OR
* The user decrease PVR indicates >= 50% of BDC and the miner decrease PVR indicates >= 80% of hashpower have signalled a preference for a MBS that is below the BMBS
The BMBS changes to the smallest MBS value that meets the preference threshold, and all user and miner nodes automatically set their EBS to match the BMBS, which effectively sets the MBS to match the BMBS. Miner nodes additionally automatically set their Maximum Generate Size (MGS) to match the BMBS.
MBSS at 3,000-block period adjustmentIf at the end of a 3,000 block period, the BMBS changes, the following occurs:
1. Nodes that are signalling a preference for a MBS value that is smaller than the new BMBS will prompt their owners to change their preferred MBS value to match the new BMBS. If the node owner chooses to not change their preferred MBS value to match the new BMBS, the MBSS integer value that the node is set to publish will automatically change by the inverse number of increments that the BMBS is changing by.
For example, if the BMBS increases one increment from 1 megabyte to 1.025 megabyte at the end of a 3,000 block period, and a node had been publishing MBSS integer values of 3, meaning it has been signalling a preference for a 2.5 percent decrease in the MBS, it will reduce its MBSS integer value by one, to a value of 2, to signal a preference for a 5 percent decrease in the MBS in the new 3,000 block period.
2. Nodes that are signalling a preference for a MBS value that equals the new BMBS will not prompt their owners to make any changes to their preferred MBS, and the MBSS integer that the node is set to publish will automatically update to 4, to signal a preference for the current block size value.
3. Nodes that are signalling a preference for a MBS value that is larger than the new BMBS will not be prompted to make any changes to their preferred MBS, and the MBSS integer value that the node is set to publish will automatically change by the inverse number of increments that the BMBS is changing by.
For example, if the BMBS decreases one increment from 1 megabyte to 0.975 megabyte at the end of a 3,000 block period, and a node had been publishing MBSS integer values of 5, meaning it has been signalling a preference for a 2.5 percent increase in the MBS, it will increase its MBSS integer value by one, to a value of 6, to signal a preference for a 5 percent decrease in the MBS in the new 3,000 block period.
The automatic MBSS integer updates are limited to the 1..7 range, which caps the preferred MBS value change to a 7.5 percent decrease or increase.
For example, if a node has a MBSS integer of 1, meaning it is signalling a preference for a 7.5 percent decrease in the MBS, and the BMBS increases by 1 increment, with the node owner opting to not change their MBSS integer setting to match the new BMBS, their node's MBSS integer value does not change, since the MBSS integer cannot decrease to less than 1, so the node continues to signal a preference for a 7.5 percent decrease in the MBS.
PVR data displayed and max block size changeIf a node owner opts into a MBS change, the MBS values displayed in the PVR sub-rectangles remain unchanged, but the max block size deltas displayed in the sub-rectangles are adjusted to reflect the new difference between the prevailing MBS and the MBS value options displayed in the PVR sub-rectangles. See graphical depiction:
Pre MBS change:
Post MBS change:
PVR calculations and 3,000-block period adjustmentThe MBSS integers that were published before the most recent 3,000-block period adjustment are reinterpreted according to the change in the BMBS that occurred at the most recent 3,000-block period adjustment.
If the BMBS decreased at the most recent 3,000-block period adjustment, the pre-adjustment MBSS integers are interpreted to have increased by the same number of increments that the BMBS decreased by.
If the BMBS increased at the most recent 3,000-block period adjustment, the pre-adjustment MBSS integers are interpreted to have decreased by the same number of increments that the BMBS increased by.
The interpreted pre-adjustment MBSS integer values are limited to the 1..7 range, which caps the preferred MBS value change to a 7.5 percent decrease or increase. As an example of what this entails: if a pre-adjustment MBSS integer value is 1, meaning if it is signalling a preference for a 7.5 percent decrease in the MBS, and the BMBS increased by one increment at the most recent adjustment, the interpreted pre-adjustment MBSS integer value is also 1, meaning it also signals a preference for a 7.5 percent decrease in the MBS, since the MBSS integer value cannot decrease to less than 1 (or increase to more than 7).
If there was no change in the BMBS at the most recent adjustment, the pre-adjustment MBSS integer is interpreted to not have changed.
Proposal extension: SPV compatibilityWith this extension implemented and supported by at least 50 percent of the network hashrate, SPV clients can obtain a majority hashpower validated account of the network health metrics (ATF and ACL), BMBS values, and the percentage of economic stake signalling support for each percentage change in the MBS value, for any block.
This extension would reduce the need for SPV clients to rely on trusted third parties to fully participate in establishing the emergent consensus on the max block size.
To provide this majority hashpower validation, each miner node publishes:
* the four MBS preference percentages of each PVR, to one decimal place (e.g. 98.6 percent)
* the Average Transaction Fee (ATF) and Average Centralization Level (ACL) of the block they generate,
* the current Base Max Block Size (BMBS)
In the scriptSig of the coinbase tx.
The published values must be validated by at least 8 of the subsequent 15 blocks in order to be considered valid. A miner node sets each of 15 flag fields in the scriptSig of the Coinbase transaction as either true or false to indicate whether it considers each of the last 15 blocks to have a valid set of published values.
