The answer can be found here:


Bitcoin Days Consumed is an alias for Bitcoin Days Destroyed. Each transaction has a BDC that's calculated from multiplying the age of the UTXO it's spending by the value size of the UTXO.

So if you are spending a 1 year old 10 BTC transaction, the BDC would be 3650 (365 days * 10 BTC).

If I could get feedback on the following, it would be greatly appreciated:

I've created different versions of the PVRs to see if there's a clearer way to convey the data.

Here is the original:



Here is the PVR with the 'current max block size' sub-rectangle eliminated, leaving only three sub-rectangles in the PVR:



I also tried reversing the order of the 3-sub-rectangle configuration:



I was thinking that the last one might actually be more skeuomorphic, with the idea that the largest max block size change would be further away, and therefore visually smaller.

The three in the GUI:

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 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.


Network Health Graphs

To 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:

         
   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:

         

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:

      
   2. The total BDC of all TxIn in B[N] flagged as containing a MBSS is calculated. In pseudocode:

           
   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:

      
   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 buttons

To 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 Change

The 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 adjustment

If 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 change

If 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 adjustment

The 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 compatibility

With 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.

Yes exactly. And I'll add that when humans are involved, it should be through as few centralised intermediaries as possible. Here BIP 100's hash power mediated block size limit change mechanism is superior to the hard fork block size limit change mechanism, which is highly dependent on a small number of influential developers.

One might argue that pools are analogous to centralised intermediaries that will control the limit under a BIP-100-like regime, but hash power generators can point their machines at any pool they want, which transparently provides feedback to pool operators on whether they're serving their hash power generator well and provides them with a powerful incentive to do so, so it's really hash power generators - broad class of people for which there is no political barrier to entry to join - that have the power. And unlike the hard fork process for changing a consensus rule, pool operators don't need to download new software to express their will to change the limit.


Yes, and the danger is that when the Bitcoin protocol gets locked into a particular state, it also locks in a block size limit that is too low or too high. BIP 100 or some variation of it solves that. The protocol can reach a final state, and still have its limit fine-tuned, in response to changing market and technological conditions, by the community.

Not really. A protocol can remain static while overlay protocols are built on top of it, and technology is created to interact with it. A decentralized consensus protocol needs to be unchangeable for the sake of stability, immutability, and censorship resistance, IMHO.

1. There is no guarantee one of these 'uncontroversial' hard forks won't become controversial, especially as the community gets larger and there are more voices. What was once a consensus position can become contentious due to new information or ideas. This makes the market (people involved in the Bitcoin space) uneasy.

2. Hard forks centralize the community, because in practice, they require the community to coalesce around a small ad-hoc governing structure for the hard fork to have consensus. This makes frequent hard forks antithetical to the decentralized quality of Bitcoin.

Motivation

BIP 100 proposes a limit determined by super-majority miner vote, up to a maximum explicit limit of 32 MB. Specifically, the preferred block size limit of a miner is expressed in the Coinbase transaction, and the minimum block size limit value of the middle 60 percent of the values of the last 12,000 blocks becomes the new limit, with a maximum change of 2x in either direction.

The original draft of BIP 100 did not contain the explicit 32 MB limit, but this restriction was added due to concern about the potential for the mining network to decide to increase the limit to levels detrimental to network decentralization.

While eliminating one risk, the addition of the 32 MB limit introduced a new one: a future hard fork to raise the 32 MB limit. As has been witnessed over the last year in the debate over replacing the 1 MB limit, hard forks that deal with the block size limit are highly contentious, due to their far-reaching consequences. This contention makes such hard forks risky, as it increases the risk of a hard fork without full consensus occurring, which would carry with it a significant risk of Bitcoin splitting into two distinct and non-interoperable networks and blockchains.

The Bitcoin userbase and development community will undoubtedly be significantly larger, with more diversity of views, and less cohesion amongst the various stakeholders in the Bitcoin economy, when conditions require executing a hard fork to raise the 32 MB limit, and therefore the risks associated with the hard fork will likely be much greater than the already considerable risks associated with the hard fork to replace the static 1 MB limit.

For these reasons, it would be preferable to modify BIP 100 to remove the explicit 32 MB limit, and find an alternate means of mitigating the risks to network decentralization from allowing miner preference to set the block size limit.


Proposal

The proposed solution is to create a predefined schedule of growing upper and lower bounds for the block size limit value, within which miner preference determines the exact value using the same mechanism as proposed in BIP 100, but which cannot be escaped through miner vote.


Specifications

Two variations of the bounded solution are offered, a 'simple bounded hash power mediated limit', and an 'enhanced bounded hashpower mediated limit'.

Simple bounded hash power mediated limit (SBHML):

The 'minimum block size limit' increases by 10 percent a year, and the 'maximum block size limit' increases by 40 percent a year, for 30 years. After 30 years, the minimum block size limit increases by 0 percent a year, and the maximum block size limit is increased by 30 percent a year.

Enhanced bounded hash power mediated limit (EBHML):

At every block, a base block size limit, B, is calculated from the central moving average of the block size limit 262500 blocks (approx 5 years) in the past, with the mean calculated from the 52,500 blocks on each side of the central block, plus the central block.

The minimum block size limit of a given block is 1.61051 (10 percent annual growth for five years) times B, for 30 years.

The maximum block size limit of a given block is 5.37824 (40 percent annual growth for five years) times B, for 30 years.

The annual growth factor changes to 0 and 30 percent, for the minimum and maximum block size limit, respectively, after 30 years.


Comparison between EBHML and SBHML

At the cost of greater complexity, the EBHML proposal reduces the range of possible block size limit values over nearer-term time-scales, thus increasing the predictability of the block size limit, and reducing, in proportion to how near-term the time frame, the maximum size of swings in the block size limit.

The difference between the minimum and maximum block size limit, and by extension, the maximum potential size of the swings in the miner defined block size limit, grows with time in the SBHML proposal, increasing the risks posed by irresponsible stewardship of the block size limit by the mining majority, while the EBHML lacks this negative quality.

EBHML is therefore recommended over SBHML.


Rationale

By having an automatically increasing upper and lower bound for the block size limit, the risk that BIP 100 contains that another hard fork will be needed in the future to accommodate the need for larger blocks is significantly reduced. The dynamic limit also provides the same function as the explicit 32 MB limit in the BIP 100 proposal, in limiting the potential damage done to decentralization from the mining network choosing a too-high limit.

The choice of 10 and 40 percent per year growth for the minimum and maximum block size limit, respectively, for the first 30 years is premised on projected minimum and maximum growth in broadband cost-performance. These figures are reduced to 0 and 30 percent per year after 30 years because of the assumed likelihood of investments in broadband growth eventually seeing diminishing returns as low hanging fruit for cost-performance gains become increasingly scarce.

I was informed by gmaxwell that adding round-trips to the payment protocol is a non-starter, and that there's a way to enable merge avoidance without additional round trips by including a BIP 32 chain code in the PaymentRequest message.

Proposal to add Merge Avoidance extension to Payment Protocol

The motivation behind the proposed extension is to encourage Merge Avoidance in Bitcoin usage, by having intermediary steps, between the PaymentRequest message from the merchant's server and the Payment message from the customer's wallet app, wherein the customer's wallet app notifies the merchant's server of how many UTXOs they will spend to satisfy the payment request, and the merchant's server subsequently provides a corresponding number of receiving Bitcoin addresses (Outputs in the Payment Protocol)  for the customer's wallet app to send the payment to.

By matching the number of receiving Bitcoin addresses with the number of UTXOs spent, the merging of outputs from the customer's wallet app is avoided.

The proposed additions to the payment protocol are:

new 'optional uint64 total_amount' field in the PaymentDetails message.

This will be field 8 in the PaymentDetails message:

message PaymentDetails {
        optional string network = 1 [default = "main"]; // "main" or "test"
        repeated Output outputs = 2;        // Where payment should be sent
        required uint64 time = 3;           // Timestamp; when payment request created
        optional uint64 expires = 4;        // Timestamp; when this request should be considered invalid
        optional string memo = 5;           // Human-readable description of request for the customer
        optional string payment_url = 6;    // URL to send OutputDetails and get AddressDetails
        optional bytes merchant_data = 7;   // Arbitrary data to include in the OutputDetails and Payment messages
        optional uint64 total_amount = 8    // total amount requested in integer-number-of-satoshis
}

new OutputDetails message that is sent by the customer's wallet app:

message OutputDetails {
        required uint32 output_number = 1       // Number of UTXOs payer will use to pay PaymentDetails.total_amount
        optional bytes merchant_data = 2        // From PaymentDetails.merchant_data
}

new PaymentRequestFinal message that is sent by the merchant's server:

message PaymentRequestFinal {
        optional uint32 payment_details_version = 1 [default = 1];
        optional string pki_type = 2 [default = "none"];  // none / x509+sha256 / x509+sha1
        optional bytes pki_data = 3;                      // depends on pki_type
        required bytes serialized_address_details = 4;    // AddressDetails
        optional bytes signature = 5;                     // pki-dependent signature
}

new AddressDetails message that is wrapped in the PaymentRequestFinal message that is sent by the merchant's server:

message AddressDetails {
        repeated Output outputs = 1             // Where payemnts should be sent, number of Outputs should match OutputDetails.output_number
        optional bytes merchants data = 2       // From PaymentDetails.merchant_data
}

The flow of the payment protocol with the Merge Avoidance extension is:

1. When the PaymentDetails message is sent, the new PaymentDetails.total_amount field notifies the customer's wallet app the total amount to be paid.

2. If the customer's wallet app supports the Merge Avoidance extension, it sends an OutputDetails message to notifies the merchant's server how many UTXOs they will spend to satisfy the total amount requested to be paid. If the customer's wallet app does not support the extension, they proceed according to the original protocol, and send the Payment message.

3. If the customer's wallet app sends an OutputDetails message, the merchant's server responds with a PaymentRequest_Final message which contains an AddressDetails message notifying the customer's wallet app of which bitcoin addresses to make the payment to.

4. The customer's wallet app spends each UTXO to a different receiving address, which enables merging of outputs at common addresses to be avoided. From this step onward, the protocol works like the original version, as the customer's wallet app sends the Payment message and optionally publishes the payment transaction(s) to the Bitcoin P2P network

I am also very much interested in the answer to this question. A detailed breakdown of the specifications and strengths and weaknesses of the different Colored Coin protocols would be welcome.


This is what I would be leaning toward as well.

The goal of the 'proof of UTXO_set storage' scheme is to give the network a means of automatically gauging how decentralized the full node distribution is. Some parts of it got inspiration from gmaxwell's 'proof of storage' concept, found here:
 
https://bitcointalk.org/index.php?topic=310323.0
 
The idea:
 

This proposal is incomplete and totally impractical in its current form. However, it has the following strengths:

• BDD is hard (economically) to spoof.
• Users are not going to trust third parties to store their private key for them. If they want to use their privkey to create signed UTXO_sets, they will have to have a local copy of the UTXO_set so that they can sign them.
• For trusted third parties who control BTC on behalf of their users, there is an economic cost to creating many txs with UTXO_set proofs just to 'fool' the network, since on-chain txs require fees be paid, while off-chain txs do not.

So maybe someone can utilize the interesting elements in it to create a workable proposal that could provide the network a means of automatically gauging read-access (fully validating node) distribution.

It will stop after doubling 10 times, meaning at 16.8 MB * 2^10. The maximum maximum block size will become 16 GB on Jan 1 2035. It won't increase any more after that.

+1 And you will not find a single prominent proponent of a permanent 1 MB limit give a compelling counter-argument to this.

^ Gavin is actually proposing increasing the limit to ~16.8 MB, and then having it increase by 1.4X every year, for 20 years.

He picked this number after running experiments to see how a full node would function with 20 MB blocks, and seeing that it could easily handle it.

We do have some data on what happens when blocks hit a limit, as they've hit a soft limit at 250 KB before. It wasn't an extended experiment, but it did give us an idea what happens at the outset. What happened is that people had to wait a few blocks to get a confirmation, which was inconveniencing people.

Doing a longer experiment on block subsidy would provide with even more data, and create incentives to come up with off-chain solutions. However, I don't think it's wise to run such an experiment, because it comes with some pretty big risks. Here's why I don't think now is the time for a block subsidy experiment:

1. it could turn a lot of people away from Bitcoin as they have difficulty getting txs to confirm.

2. off-chain solutions might not get invented. We actually don't know if there are adequate off-chain solutions for scalability. We hope there are, but it's possible they are all inadequate. If that's the case, then during the entire block scarcity experiment, users would be left without a way to transact in bitcoin

3. due to 1 and 2, it could hurt Bitcoin's momentum. Deploying a technology and achieving mass adoption is about maintaining momentum. Eventually a technology will fade from the public consciousness, so it's important the opportunity to achieve mass adoption is seized. Further, governments are creating new legislation all the time put Bitcoin under greater restrictions. Mass adoption is the best defense against new legislation, as we saw with the internet.

4. we have plenty of opportunities to conduct scarcity experiments when we actually need to limit block sizes. There will come a time when Bitcoin blocks simply cannot get larger without harming decentralization. At that point, blocks will have to be artificially limited in size, and then we will get all of that experimental data you want on how a system behaves under scarcity.

In conclusion: at 1 MB, 4 MB, or 5 MB, is absolutely not the right time to conduct a block subsidy experiment. Additionally, we don't need a hard limit to run a scarcity experiment. A hard limit is a crude and dangerous way to limit block space, because if we find the experiment is harmful, a hard limit is difficult to quickly remove. Experiments with block scarcity should be done with soft limits, not with unchangeable protocol rules.

+1

Yes, a geometric increase is what I meant. Gavin's current proposal is for it to double every two years, meaning it increases 1.4X every year, which gives it a reasonably high chance of staying behind consumer bandwidth growth (and thus keeping the network highly decentralized).

So to answer your question, yes I would support something along the lines of what you're proposing. I think 5 MB would be much better than 2 MB though, because Bitcoin has a tendency to see sudden spurts in adoption, and so it'd be nice for it to have some room to grow quickly in the coming years.


Thanks for posting.

And I think one thing that often gets lost in the discussion on the hard limit, and that I can't stress enough:

There are other ways to stop bloat besides a hard limit in the protocol. A protocol limit is the most crude and inflexible way to counter spam/bloat. If a 40-50% increase per year ends up being faster than connection speed increases, it is very unlikely that other means will not be found to limit block sizes.

Hey I'd be fine with a 5 MB block size limit, and some percentage increase every year afterward. I think 20 MB would probably be better, but that's far less important than putting in place some dynamic hard limit, ANY dynamic hard limit, that steadily increases, year by year, so that we never have to do a hard fork again to change the limit.

Should we need a stricter limit in the future, it should be done through a SOFT FORK, with >50% of miners enforcing it. Static hard limits are dangerous, and should not be the way Bitcoin controls bloat.

Altcoin pumpers have seriously lowered the quality of the discussion surrounding the hard fork. Kazuki49 is one of the worst.

Satoshi Nakamoto is not John Nash. Nash is 86 years old. Please discuss your fringe theories in a different thread. This is really not the place to be pushing them. We're discussing something serious, and important for Bitcoin and the future of cryptocurrency, and you're trying to get everyone to listen to your weird theories about Satoshi's identity, and why this somehow means we shouldn't allow Bitcoin to scale.


Exactly. It's not exactly a coincidence that most of those vigorously arguing against the hard fork in this thread are involved in altcoins. They're not in favour of Bitcoin gaining more competitive advantages, and they've all but admitted it already.

And it's only 3 transactions per second, not 7.