New transaction fee toolsets coming to Bitcoin SV

TLDR;

• Cheaper transaction fees, fiat stable pricing and a highly flexible framework for dynamic fee rate discovery are all on the horizon for Bitcoin SV.

Since a recent price rise of BSV in fiat terms and the announcement of WeatherSV’s transaction fee deal directly with a mining pool (Mempool), the subject of transaction fees has become a hot topic in the Bitcoin SV space   It’s an important topic to think through as BSV finally unlocks Bitcoin’s massive scaling capability and has opened the door to new business models for use of the blockchain to record large and continuous volumes of data.  Transaction fees on Bitcoin SV are still far less than on competing blockchains (especially BTC and Ethereum), but we can do more to ensure that fees are reliably low, so applications can properly plan their business models while miners are also economically agile.

I’ve discussed this issue with several mining groups and many Bitcoin app developers. There are some common themes and opinions about future direction along with a general consensus that the toolset we inherited from BTC and BCH-ABC for managing transaction fee rates is clunky and inflexible. 

We’ll begin by examining the common concerns among both users and miners of Bitcoin SV. Then we’ll survey the current state of play and what’s possible with the existing transaction fee toolset before turning our attention to where that toolset is heading on BSV.  Finally we will consider what can be done between now and when it is fully available.

Concerns

Lack of fee discovery

It is astonishing that after 10 years, Bitcoin wallets still have no way to reliably determine what fees are required to get a transaction mined.  Most rely on complex and unreliable mechanisms.  This is partially a consequence of the Bitcoin Core model of a fee market where miners are price takers rather than price makers.  Bitcoin SV turns this model on its head so there’s no excuse for miners not to be able to provide definitive fee quotes barring an implementation.

Price too high

The current fee rate is inherited from the default in the Bitcoin ABC implementation for BCH.  It is denominated in satoshis per byte and currently equates to about $1.20 USD per MB. There is no particular reason for this price level and it appears to be widely agreed among the BSV ecosystem that rate is currently too high for data transactions (as compared to payment transactions).

Fiat stability

When you build a business model based on an operational cost of X and the volatile BSV market makes that price jump to 2X overnight, it’s very hard to make safe predictions about the viability of your business.  Fiat stable pricing, e.g. $0.XX per MB, is something we’ve heard many enquiries about from businesses seeking certainty.

We don’t know the floor

No one really knows what the cost of processing a transaction is. It is very hard to model this as the inputs to the model are highly variable and some require guesses at future transaction volume.  There are variable costs like cost/MB-bandwidth-use that are relatively proportional to the amount of transactions; that’s the easy part. The harder part are the fixed costs that must be amortised over many transactions without knowing exactly how many.  There is some work beginning by some of the miners to start building these models and understanding the zones of risk.  But it is only just beginning now because it’s only just started to matter.  Until this is better understood I predict there will be some reluctance by miners to lower costs in an extreme manner because it is much harder to ask the market to bear a later increase than is to continually lower prices until the floor is found naturally.

Disparities in data value

Suffice to say, some data is worth more than other data from a miner’s point of view. We’ll address this further in the next section.

The current state of play

Right now miners have only two manual configuration options in Bitcoin SV to manage fees and changing either requires a restart of the node.  These form the “transaction fee toolset” currently available to BSV miners:

• There is the “actual fee rate” that miners accept to mine a transaction denominated in sats/byte. 
• There is an additional option “minrelaytxfee” which should be lower and is the fee rate required for a miner to even bother validating a transaction and subsequently relaying it to peers. 

To my knowledge almost all miners currently use the default settings which are both set to 1 sat/byte.  However, it is actually important for a safe 0-conf fee market to emerge that minrelaytxfee is set lower by some margin than the actual fee rate, so for the purposes of this discussion we will assume that the default minrelaytxfee is actually 0.5 sats/byte. The existence of this range of fee rates is important to enable room for miners to be competitive whilst still protecting the “first see rule” that is a fundamental pillar of 0-conf security. I have referenced the idea of a “secondary mempool” in many of my public presentations that is for miners to keep some transactions for double spend protection even if they don’t intend to mine them.  There is a lower bound to the fee rate where this protection kicks in simply to discourage the excessive use of zero fee transactions. 

To illustrate the use of this range, let’s assume that all miners except one use the defaults and that one “exception miner” accepts a fee rate of 0.8 sats/byte.  If confirmation time is not important to you, you might use this fee rate; the “majority miners” will accept the transaction into the mempool and refuse to allow it to be double spent because the fee is higher than 0.5 sats/byte, but because it is below the one 1 sat/byte fee rate that all the majority miners are using, only the one exception miner will try to mine it into a block so likely you’ll have to wait many blocks for it to be mined. 

Let’s try a second scenario where one exception miner uses a fee rate of 0.3 sats/byte.  This is below the 0.5 sats/byte threshold so the majority miners will not even accept or relay it let alone mine it.  In this case most miners have forgotten the transaction and cannot do a double spend check in order to respect the first seen rule.  For some use cases this might be ok (e.g. WeatherSV since they won’t double spend themselves).

With these examples along with the diagram above we can clearly see four distinct classes of transaction properties based on the chosen fee rate:

1. Offline, miners will ignore them. This can be useful if you consider that using CPFP you can later upgrade a transaction to one of the later classes
2. Slow to mine, no double spend protection
3. Slow to mine, full double spend protection
4. Fast to mine, full double spend protection.

These properties have progressively higher value dependant on use case and you should be able to select what is most appropriate for your situation.  And in fact some of those properties are not just black and white.  E.g. time to mine can be improved by choosing a fee rate that will satisfy xx% of miners without choosing the highest fee rate.

What this highlights is that not all transactions are created equal, and it would be nice if miners could compete on each class or specialize in some.  But right now there is only one fee rate for everything.

So back to the current transaction fee toolset currently available. These two settings are buried inside the Bitcoin SV Node software itself.  That means if you want to modify how they work you have to modify the node code.  Because the node code handles some other very sensitive parts of the Bitcoin network, our Bitcoin SV Node team has very onerous QA processes and few other people are willing to risk touching it.  The consequence is that changes to these mechanisms are slow and complex to implement and can only be implemented by one team (unless you want the overhead of maintaining a full Bitcoin codebase).  This is the opposite of what is needed to enable multiple players to dynamically implement new mechanisms and engage in a real-time process of price floor discovery.  I’m going to drop a controversial word here and say that Bitcoin needs a fee market.  But unlike Bitcoin Core we aren’t using a market to discover how high transactions fees can be, we are using it to discover how low they can go.

A further issue with this setup is that the general public doesn’t have any visibility into these settings.  So the actual price that miners are asking is unknown to the people who need to set the transactions fees in the transactions they create. There are all sorts of horrible fee estimation algorithms out there that we inherited from Bitcoin Core but they rarely give the best price, no assurance that you’ll even get it high enough and give you no visibility of what fee rate will actually provide 0-conf safety.  We are currently saved from the disaster this could become by virtue of the fact that almost all miners currently use the defaults.  This works until miners start changing them which they will likely do very soon.

Lastly, there is the lack of granularity.  There is no mechanism to price different types of transactions at different rates.  Data bytes cost less to process than ECDSA signatures but miners cannot reflect that in the current pricing model. Some types of data might be worth more from a miner’s point of view than others. For example, it could be argued that weather data is more valuable than pictures of someone’s cat as the weather data is a public utility that enhances the value of the blockchain as a data store.

Near future tools

For Bitcoin SV, there are three tools in the pipeline directly applicable to most of these concerns around transaction fees.  The second might make the first one redundant but it illustrates one of the points above.

1. The ability for miners to price data bytes differently to the rest of the bytes in a transaction.
2. Moving the fee evaluation function OUT of the Bitcoin SV Node software.
3. Providing a fee discovery mechanism to end users

Change 1 is a change to the Bitcoin SV code that has been in pipeline for quite some time and will likely make it to release around Feb 2020.  Its function will be easily replicated by change 2.  Along its journey through the change pipeline it has dealt with competing priorities (e.g. the Genesis hard fork) and only being worked on by the Bitcoin SV team due to the myriad complexities of it being embedded in that code. This alone is a great justification for change 2.

Change 2 will have its first implementation in our planned Merchant API but it requires a change in the Bitcoin SV Node to open up a gateway.  In essence, the Bitcoin SV Node needs a mechanism to accept transactions from a trusted source and because that source is trusted it will not check fee policies, rather it will just check the transaction is valid and append it to a block.  This means delegating fee evaluation to an external module.  There can be many implementations of these and anyone can build and maintain one without having to touch the Bitcoin SV code. The requirements for such a module are quite small so a project like this is not terribly onerous.

Change 3 is also a part of Merchant API but it doesn’t require changes to the node for its first iteration, so fee discovery will be available as a beta implementation in the coming weeks.

Let’s take Merchant API as an example of externalising fee evaluation, since it already has the facility to provide fee quotes to users and accept transactions it is a logical place to perform fee evaluation.  It is embodied as a REST API which every developer on Earth knows how to use.  So consider a few possibilities of what it might be able to do:

• User based fee policies – public connections might be offered one fee rate whilst authenticated users might offered fees based on their particular contractual arrangements.
• FeeQuote mechanism enables rapid changes to fee policies whilst users remain fully informed.
• Lower pricing for data bytes compared to signature bytes.
• That ability makes fiat stable pricing possible, fees can be updated daily or hourly to ensure they cost the same amount in USD rather than floating with the BSV price.
• Per protocol pricing – Using the widely adopted OP_RETURN protocol_id standard to price different protocols according to their perceived utility e.g. plaintext data available to all users may be cheaper than encrypted data accessible to only one.
• Volume discounts for bulk submission.
• Out of band payment – “Hi Amazon, for $X/month payed with your credit card we’ll take care of getting all your transactions mined”.

The range of possibilities is endless when this functionality is pushed into the hands of miners and payment processors. The fee quote mechanism has been designed to very flexible going far beyond the traditional “satoshis per byte” mechanism we have today.

Merchant API and its companion tool, Miner ID, are beginning private beta testing over the next couple of weeks and we’d expect to make the endpoints public early in 2020.

Interim measures

But can we do something right now with the blunt instruments we currently have at our disposal?  The answer is probably yes. From the discussions I’ve had with many actors (including miners) around the ecosystem there are clearly a couple of common themes:

1. There is a strong appetite to cut transaction fees significantly in the near term.
2. It is widely recognised that volatile pricing in fiat terms needs to be addressed to provide operational cost stability to businesses using Bitcoin SV so whatever solution is presented for the first point will probably be accompanied by a periodic review of pricing to keep them relatively stable in USD equivalent until automated mechanisms are enabled.

I think it’s reasonably safe to say these changes are imminent, it’s only a question of when and by how much.  But what is probably important to note is that Bitcoin SV is already cheapest of all major blockhains to transact upon for real utility, both in satoshis and in fiat terms, any cut will send a clear signal to the market the cost of using Bitcoin SV is going in only one direction, down.  This is only economically possible because the future of Bitcoin SV is to massively scale.

We’re just now experiencing how Bitcoin’s economic system should have played out for many years before. It will take the BSV ecosystem some time to adjust to this new reality, but we will do so by developing flexible new transaction fee toolsets and constructive business approaches.  These steps will ensure a healthy and long-lasting transaction fee market that that is flexible and meets the economics needs of both application builders and miners.