The BSV blockchain team recently received this request on the BSV github issue tracker.
“request to change the default script size limit from 10KB to 500KB”
The use case presented looks like a valuable one that we would like to see explored. However BSV blockchain soundly rejected the model of “governance by developer decree” in favour of the original Bitcoin model where limits are determined by the competitive actions of miners. Which triggers the unseen hand of markets to define limits as emergent properties.
When Genesis activated the BSV blockchain team made this public statement directly to miners:
“We would like to thank all of the miners that participated in the upgrade and offered assistance in various ways. The governance of Bitcoin consensus parameters is now in your hands. We will be available to advise but we will resist making recommendations and will no longer be making any decisions on your behalf. We know you will take this significant responsibility seriously perhaps because you care about Bitcoin but most certainly because it’s in your economic interest to do so.”
This is important to emphasise because the “governance by devs” model is what led to the strangulation of Bitcoin Core. We saw in the block size debates, a clear majority of miners in favour of raising block size but because it was established that devs made those decisions the miners submissively accepted their decision not to scale.
It is miners who collectively, but competitively, operate the Bitcoin network service and it is they that bear the risks of changing their own policy or consensus limits. It is not the role of the BSV infrastructure team to impose additional risk on miners without a clear signal from miners that that is what they want.
Why have policy limits at all?
Policy limits are different to consensus limits in that they are chosen by individual miners and do not need to match a majority of other miners to avoid the risk of forking off the network. Many of those limits have a matching consensus limit that is set to a much more liberal value. All of those limits exist to mitigate some sort of risk to node stability in unusual or attack conditions. Without them the alternative would be to have no protection against potential crashes.
They exist in order to enable miners to make individual decisions about which risks to accept and in what quantity. Any miner is free to increase or decrease any of these limits. It is common for businesses to make decisions to accept risk if they expected reward outweighs the risk. It is also common for different businesses to have a different perception of risk and reward and make different decisions about the same risk.
How to get a policy limit raised?
The ancestor limit is a clear example of how this governance process should work, where the demand originated from the users and that translated into the miners wanting it and making that known to the BSV blockchain team. Our customers are the miners. Their customers are the users of Bitcoin. The demand drivers of change flow from users -> miners -> infra-developers.
The right approach is to talk to the miners directly. They can change this limit right now with a config setting. So explain your use case, explain that you will generate additional transaction fees if they allow this. Once the demand is clear what usually happens is that miners talk to the BSV Infra team and ask us to help them understand the risk profile of the change. Part of this risk profile is inevitably the increased orphan risk of accepting a transaction type that other miners might not.
If the risk is acceptable the miner will make the change. This usually results in more miners following suit so they can share in the transaction fees this new use case is generating. Eventually when enough miners adopt it, this orphan risk flips on its head and becomes a risk to the miners that haven’t adopted the new policy limit rather than the ones that have. At this point the signalling of miner demand is clear and BSV Infra team will usually make a change to the default.
This is not the quick fix you’re looking for
Suppose, as a hypothetical, that the BSV blockchain team decided to bypass the usual governance mechanism and attempted to impose a new limit on miners by releasing a new version of software with the default changed. Would it achieve the goal of increasing this limit across the board?
The short answer is ‘no’. Bitcoin miners can be broadly divided into two camps:
- Those are that are pro-BSV
- Those that aren’t very interested in BSV and are just here for the block rewards.
Miners like TAAL, Mempool, MatterPool and a few others are in the first camp and routinely adopt new versions of BSV quite quickly. But those are also the miners that are also proactive in responding to user demand by changing policy settings to accommodate new use cases. They could put this change into effect today, whereas the BSV blockchain team couldn’t do it until the next release at earliest.
There are quite a few in the other group as well. Many of them are absent right now because of the BTC price boom pushing up block reward profitability on BTC but we do expect them to return. This other group doesn’t tend to adopt new versions of BSV very quickly at all. In fact we believe there are some still running v1.0.0. Changing the default will have no effect on them unless they upgrade to the latest version. Which they probably won’t any time soon if past behaviour is any indication..
So the end result is likely worse and slower to adopt than approaching the miners directly. For that reason we will not be implementing this change until we have a clear signal from enough miners that this is the new normal.
How to make this process even smoother
There are some changes coming to BSV node that will lower the risks to early adopting miners and make the path for limit increases even easier.
The first risk we can mitigate is that whilst the particular use case that is driving the request to increase the limit might be known to be safe, we may not know what other use cases there are that might cause problems. In this example the request is to raise the script size limit from 10kb to 500kb. This allows a particular type of smart contract to be accepted. But it also allows every possible script that can be expressed in less than 500kb. And since this hasn’t been exhaustively tested we can’t be sure that doesn’t enable an attack vector.
A potential solution to this is to limit the raised limit to specific known users with known use cases. mAPI can allow this with a change to bitcoind that allows mAPI to flag a transaction to be allowed to ignore a policy limit. That mAPI operator can allow this much more easily than if they had to modify the BSV software itself.
The second risk we can mitigate is orphan risk. Since mAPI has the ability to bypass some of the policy limits set on bitcoind, it is relatively simple for a miner to setup up a mAPI token for another miner that allows them to send them transactions that they are mining but do not meet standard policy limits. This allows the transaction to be kept in the other miner’s mempool and eliminates the additional cost of block propagation from that transaction. It’s not a perfect solution but it’s one that can be implemented relatively quickly and enables more flexibility.
Both of these mitigations will be enabled by the same feature in bitcoind which we previously mentioned. mAPI uses the ‘submitrawtransaction’ RPC call to send transaction to the node. It already takes an optional parameter to indicate that the node should bypass it’s fee checks. The feature allows an additional parameter to allow the node to bypass policy checks as well.
This feature is targeted for release in BSV v1.0.9
