Bitcoin Unlimited Concept

amincd

New Member
Mar 1, 2016
6
8
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.
 

amincd

New Member
Mar 1, 2016
6
8
Part 2

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:

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

 
  • Like
Reactions: YarkoL

amincd

New Member
Mar 1, 2016
6
8
Part 3

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.
 
Last edited:
  • Like
Reactions: YarkoL

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,693
@amincd
Welcome to bitco.in/forum, home of Unlimited!

Your proposal has a lot of consider and I hope that it gets enough feedback that you find useful. It is always possible to raise a BUIP (BU Improvement Process) for functional changes. My first impression of the GUI mock-up is that the graphics are complex for most users, even smart ones!

The overcoming of Schelling Points is a question mark for emergent consensus and might be considered a very human factor which degrades what would otherwise be a more efficient non-conscious process.

The 1MB is a special case because it is universally hard-coded in software. If we consider a post-1MB situation with a majority BU network and average block size ~2MB the effective emergent limit may be in the region of 5MB, constantly oscillating in a small range as miners and non-miners change their settings. I would expect that occasionally a miner will put out a large block for one reason or another (maybe even a spammer does it) and it will set a new record size. Then all the other miners know that this size is "safe", as an emergent consensus limit is unlikely to reduce significantly unless there is a major environmental problem affecting the whole network.

Record blocks may appear at irregular intervals, say its an average of weekly, each slightly larger than previously, as some which were just a bit too large get orphaned. These can be plotted, and a miner wanting to create a record sized block can have a good idea of the probability that it will be accepted by the network and built upon.

BUIP005 mentions the future generate size, and a proposed activation block height in multiples of 12000 blocks, which may be sufficient variables to allow miners to signal via the blockchain what their preferred future limit is.
 
Last edited:

amincd

New Member
Mar 1, 2016
6
8
Thank you for the welcome!

Thanks for the feedback. I guess when I try to put myself in other people's shoes: it is complex!

I was trying to fit in as much data in the rectangular space afforded by the client GUI while still providing space-based representation of data. The different sub-rectangle sizes are supposed to represent the magnitude of the change, with the largest sub-rectangles visualizing the largest max block size change.

Yes, it could turn out to be a challenge to overcome Schelling points, while at the same time making the max block size a result of non-conscious processes. The Network Health graphs on the right side of the GUI mock-up are an attempt to find a way to make the user choice on max block size a product of end-user priorities.

With respect to the post-BU-adoption environment, I believe there's a very good likelihood that the Coinbase-txn signalling proposed in BUIP005 would be sufficient to establish consensus on a limit change without using off-blockchain communication channels. I do think however that it would advantageous if users also had a Sybil-proof way to communicate.

One option is to multiply the block intervals and the percentage change sizes of this proposal by four, to make it consistent with the 12,000 block interval of BUIP005. Another is to reduce the BUIP005 interval to 3,000.

Yet another is to have two parallel signalling methods, so that there are multiple avenues for a max block size change.
 
  • Like
Reactions: AdrianX

YarkoL

Active Member
Dec 18, 2015
176
258
Tuusula
yarkol.github.io
@amincd
Thank you VERY much for putting so much thought into this. I'm happy to see that the BU vision is attracting such high quality input!

I have not thoroughly digested everything in this draft, but it seems to me to be along the right track. I will jot down here just some initial and immediate thoughts, that I'd be interested to know your response.

1. To encode MBSS on tx is absolutely a must. The user-agent advertizing of preferences is only a set of training wheels so to speak. The more a transaction spends, the more the MBSS will weight as a vote. However unless I missed it, there is no way to determine if the user-type bit of MBSS is a valid one. The miner has a way to prove it by putting the signal in coinbase, but how do you prove you are running a full node?

2. Have to agree with @solex that the graphs may appear too daunting, but I'll reserve the judgement until further perusal. I really like the idea of two curve displays (the fees and centralization pressure) for pedagogical reasons, as it kind of educates the user that more factors are involved than just coming up some number when making an informed decision.
Continuing on that theme, the selection of MBSS should reflect the real capacity of the user hardware to perform validation, initial sync etc, so we'd need some sort of self-diagnostic utility to provide suggestion of MBSS that adequately reflects the computing resources. Then the centralization pressure curve also becomes meaningful. (Who knows, this kind of thing could even mitigate the current civil war, because it shifts the discourse to actual figures and not just opinions)
 
  • Like
Reactions: Peter Tschipper

amincd

New Member
Mar 1, 2016
6
8
@YarkoL You're most welcome!

1. You are correct: there's no way to determine if the user-type bit of the MBSS indicating fully validating node status is valid. It's trusting in the honesty of the economic majority. I assume most wallets will make the default settings honest.

2. I'm glad you like the curve displays! The way I see it: the more information - that is pertinent to the determination of the optimal max block size value - that users can obtain from the blockchain, by way of their GUI, the less vulnerable Bitcoin will be to capture of TTP-controlled communication channels.

I agree that additional/other information could be shown to let users know the 'cost' of max block size increases, particularly what you mention: the capacity of the hardware the user is running. I was thinking the most useful user-subjective information would be bandwidth usage, given the other major concern users have expressed about running a fully validating node: storage usage, has become much less problematic since pruning was implemented, and bandwidth is by far the largest financial expense of running a node.

Really, any information can be shown in the curve displays, and different wallets can choose to display different kinds of information.

I was thinking that eventually it might make sense for full node GUIs to show a bandwidth usage curve in place of the 'centralization level of tx generation' curve shown in the mock-up, while SPV nodes show the 'centralization level of tx generation', since they don't have first hand information of the bandwidth costs of running a full node.

Having a self-diagnostic utility like you describe would be great!
[doublepost=1457145627][/doublepost]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:





 
Last edited:

YarkoL

Active Member
Dec 18, 2015
176
258
Tuusula
yarkol.github.io
@amincd
I'm not sure if the rectangle representation is the best way to convey information - unless you can provide additional grounds for making that choice. How about histograms, we are much more accustomed to them.

One thing that strikes me is that instead of optional local MBS change, we could make dynamic max block size on the protocol level based on similar procedures that you have described, since the data is on the chain. Then miners could be 100% sure that the blocks will be accepted, but the max size will still be determined by nodes informed by stats and not by pure algorithm or devs.

About your centralization level metric: it is basically the ratio of non-full nodes spending to full nodes spending, but I'm not sure if that'll work. First of all I'm not even sure where inputs flagged as non-full node would be coming from? SPV wallets? But how does that then give us any idea of centralization?

I believe transacting on the network is actually quite "centralized" since so many people use web wallets. Not sure what the percentage of blockchain.info and Coinbase txs is, but I'd hazard a guess that it might be around 70%, which also means that they largely get to determine the block size if all transactions going thru them express their preferences... or does the Bitcoin Days Consumed mitigate that? (I'm not sure)

So here are some more thoughts. I'm positive that your (I mean Theymoses ;)) approach is the most promising one but need some more tossing around and refinement.
 

amincd

New Member
Mar 1, 2016
6
8
@YarkoL

Thank you for your comments.

I'm not sure if the rectangle representation is the best way to convey information - unless you can provide additional grounds for making that choice. How about histograms, we are much more accustomed to them.
I'm not sure either. I favor it but it's hard for me to assess this without bias, given the rectangular visualization is the first one I chose.

A histogram could work too:



For comparison, the reverse 3 increment PVR:



My reasoning for the rectangle is that it allows each increment to remain a constant size regardless of percentages. It's the color scale that represents intensity of preference, rather than size. The uniformity of size for each sub rectangle across different percentages reinforces the idea of static increments.

The progressive change in the size of the sub-rectangles, all forming one rectangle, achieves the following:

It allows for a one-dimensional directionality to be conveyed - as people associate largest->smallest, or smallest->largest as a progression - and yet uses two-dimensions space. Given the GUI is rectangular, using both dimensions makes better use of the space the GUI affords.

So to reiterate, the PVR achieves all of the following:

* static increment sizes
* conveys one-dimensional directionality
* uses two-dimensions of space

But again, I'm very biased. Maybe removing the percentage text (since the color already indicates the percentage of support), and putting a gradient color key above each row of PVRs, would make it look less cluttered? I'm not sure, but I think the PVRs can be refined.

Or the whole PVR idea might be sub-optimal, and I'm just being biased.

One thing that strikes me is that instead of optional local MBS change, we could make dynamic max block size on the protocol level based on similar procedures that you have described, since the data is on the chain. Then miners could be 100% sure that the blocks will be accepted, but the max size will still be determined by nodes informed by stats and not by pure algorithm or devs.
There are perhaps advantages to keeping the signalling outside of the consensus rules, in making the final max block size value more 'emergent'. Any network enforced rule on max block size changes reduces the flexibility of the consensus process to incorporate new factors in the determination of the value, which perhaps makes it less adaptive/evolutionary.

However, making the MBSSs part of the consensus rules is certainly an option. It does remove the uncertainty and therefore risks involved, which is quite important in financial protocol.

First of all I'm not even sure where inputs flagged as non-full node would be coming from? SPV wallets? But how does that then give us any idea of centralization?
Yes, SPV and web wallets. It gives us an approximation of the change in the percentage of users running fully validating nodes. To account for the fact that some who run full nodes may interface with the full node remotely using an SPV wallet, an SPV/lite wallet can be made to signal fully validating node status if they're relying on a full node controlled by the SPV wallet owner as their transaction data source.

There are big questions marks around this. For example, will large off-chain transaction processors mark the on-chain settlement transactions they create between each other as fully-validating node (FVN) on?

Would that be desirable? On the one hand, reliance on off-chain transactions could be a result of full nodes being too expensive to run, and users opting to use e-wallets that effect off-chain transactions instead. On the other hand, I'd say it's more likely that reliance on off-chain transactions would be a result of SPV clients becoming impractical due to tx fees becoming too high, in which case the 'centralization of tx generation' metric decrease would actually be good, as it would encourage users to raise the max block size value.

Not sure what the percentage of blockchain.info and Coinbase txs is, but I'd hazard a guess that it might be around 70%, which also means that they largely get to determine the block size if all transactions going thru them express their preferences... or does the Bitcoin Days Consumed mitigate that? (I'm not sure)
Yes, large web wallets would be in a position to heavily influence the MBSS signalling, as a result of their control over tx generation. One would hope that the market punishes large web wallets that don't give end users control over the MBSS embedded in their own txs.
 
Last edited:

Members online