Introduction
The Bitcoin SV network continues to grow and evolve, as more users discover its power to handle large transaction volumes at low fee rates, and miners discover the greater long-term profitability of a massively scaled blockchain. These capabilities are leading a new transaction fee economy to emerge on BSV, where miners and application senders have more choices about fee rates and service levels for different types of transactions.
With the recent May 11, 2020 block reward halving on the BTC network, a significant amount of mining hash moved from BTC to Bitcoin SV. Beginning on May 12, 2020, some users also performed a public stress test of the Bitcoin SV network, sending millions of low fee transactions (including a vast majority lower than the default transaction acceptance (mining) fee of 0.5 sats/byte). These events led to a buildup of the mempool, which was ultimately cleared by TAAL mining a world record 309MB block on May 12.
These recent events, along with the emerging new transaction fee economy on BSV, provide learning opportunities for all participants in the Bitcoin SV network on how to best use the network and its new tools. Here is some guidance from the Bitcoin SV Node team to miners and application developers that need to propagate transactions.
A. Guidance for BTC miners now mining on BSV
Firstly, if you’ve recently joined the network from BTC, welcome to Bitcoin SV. We do things a bit differently around here. You can of course continue mining the way you did on BTC, but you’ll be missing some significant efficiency and revenue opportunities. Here’s how to take advantage of them:
1. Mining API
Firstly, if your mining pool software is using the old `getblocktemplate` RPC call from Bitcoin Core, you’ll have trouble mining big blocks. That call returns more than double the block size worth of mostly useless data, which is fine for a 1MB block on BTC, but will probably hurt your pool software if you start mining much bigger blocks on BSV. Of course, that also means you’ll be missing out on transaction fee revenues which are growing more and more significant.
On Bitcoin SV, we use `getminingcandidate` which returns a constant size response no matter how large the block is. It’s fairly easy to integrate into pool software. Learn more about it here:
https://github.com/bitcoin-sv-specs/protocol/blob/master/rpc/GetMiningCandidate.md
2. Set your limits high
On Bitcoin SV, nodes are a much more important part of the mining infrastructure than you’re probably accustomed to on BTC, and it’s import that they are configured properly. Some recommendations from the Bitcoin SV Node team are available here:
3. Get well connected!
We use compact blocks for block propagation which is pretty effective for now although a better solution is coming. This works best when you are connected to other powerful nodes. It speeds up your propagation time and reduces your orphan rate. Reach out to the Bitcoin Association and they will help put you in touch with other miners. It is in all miners’ interests to be well connected to each other, so you’ll find them more than willing to help.
4. Stop worrying about orphans
Having a block orphaned is a normal part of the Bitcoin protocol; it happens to everyone on Bitcoin SV but the difficulty adjustment takes care of that and means no one actually loses because it lowers difficulty to factor out the orphaned blocks. What orphans do is reward miners more for being well connected.
Mining small blocks is often touted as a solution to orphans, but on Bitcoin SV that will also mean you get less revenue. The sooner you become expert at fast block propagation, the more revenue you will earn and you will discover that even at much higher than 1MB the orphan risk is quite minimal.
5. Implement Miner ID and run a Merchant API endpoint
Miner ID is a way of identifying your pool like a coinbase string, but it is attached to a public key and cannot be forged like a coinbase string can. It allows you to own your mining history and use it to back up any information you want to make public. It also has potential economic value to you over the longer term.
The Miner ID reference client is built in such a way that you can integrate it with your pool software with just a few lines of code changed (sometimes as little as one line).
Merchant API provides an easy way users to submit transactions to you but more importantly, to discover your fee policy.
Miner ID and Merchant API both have reference implementations available under the Open BSV license (free to use on Bitcoin SV). More details for both can be found here:
6. Keep your bitcoind software up to date
The Bitcoin SV Node software is under rapid development with constant improvements to performance and resilience. We recommend keeping at least two nodes of different versions available as a precaution, but released versions undergo and extremely rigorous QA process including live testing on the Scaling test network (STN) and are considered stable by the SV team before release.
Releases are announced here:
And also tweeted by @BitcoinSVNode
B. Guidance for application developers (transaction senders)
1. Understand fee policies
If your application is sending transactions to the BSV network, be aware of fee discovery. Make sure you understand the implications of different fee rates across the network. Bitcoin is not binary in the sense your transaction either will or will not get mined. There’s a range of variable factors including how long it will likely take, and how well protected your transaction is against double spends, If that matters for your use case. The good news is that the information required to make sense of this IS actually available and can be reliable. This is not a claim that BTC or any other Bitcoin variant can make as it is a recent development only available on Bitcoin SV.
2. Use Merchant API to submit transaction
The Bitcoin SV peer-2-peer network is pretty good but it’s not always perfect. There are about 300 peers on the network currently, mostly Bitcoin SV instances, and I would guestimate only about 100 of those are doing anything useful. This means that sometimes, under high load, poorly provisioned bitcoin daemons can get in the way of your transaction’s propagation. Unless you have a direct connection to a miner you can’t get a definite assurance that your transaction reached them. Merchant API solved this problem by enabling you to bypass useless peers and submit directly to the miner using a simple REST API. If your transaction meets their quoted fee rate it will definitely get accepted and mined as soon as they find another block. You can even get a signed response from the miner indicating their intent to do so.
It doesn’t require any special relationship with the miner, the Merchant API was designed first and foremost to be a PUBLIC endpoint.
Merchant API helps for miners that are running it as early adopters. The next upcoming release of Merchant API will include an aggregator service that will help to make sense of the range of fee policies and understand what service level a given fee rate will get for you. As well as taking care of submitting to miners for you with the same signed acceptance responses.
You have a range of options for interacting with the BSV network. For example, some miners offer special rates for high volume clients. But the Merchant API will always support a default publicly available fee rate. There is also the option of direct broadcast to the peer-to-peer network.
3. Use Simplified Payment Verification (SPV) if you can
Simplified Payment Verification is described in section 8 of the Bitcoin white paper. This will become much easier to implement once we release the next iteration of Merchant API, in which merkle-proof callbacks are implemented. In the meantime, you can obtain merkle proofs from the Bitcoin SV Node software as an interim solution.
Many applications that currently use an instance of Bitcoin SV do not actually need to. It’s just the way it’s always been done and is a legacy of Bitcoin Core thinking. As applications scale, the cost of running a Bitcoin daemon will increase significantly and there will be a real economic imperative to switch to an SPV application model if it’s possible for your use case.
4. Don’t run bitcoind unless you need to and if you do…
The services that bitcoind provides can be used for more than just building blocks but it is generally overkill for many use cases. Remember that the Bitcoin SV Node team primarily considers its user base to be miners and we make engineering decisions on that basis. That means we may not be designing with your transaction producer or other application use case in mind and we are ALWAYS assuming the software will run on very well provisioned machine.
5. Run in minimal modes
If you need to run bitcoind, consider running in `blocksonly` mode and not maintaining a mempool. This can lighten the load on the software significantly and reduce memory and bandwidth requirements but you will not see transactions before they are confirmed in a block. Be aware that the tradeoff is that your connection may be deprioritised by other Bitcoin daemons it creates unnecessary load for other participants of the network without offering anything useful in return.
If you need to listen for unconfirmed transactions, consider using the ZeroMQ interface to get a stream of transactions and handling them in your own database or software. If you do this, you can use a much smaller mempool limit as you don’t need the Bitcoin SV Node software to hold onto the transactions once you’ve read them from ZeroMQ.
6. RPC
If you’re using RPC calls, consider whether a particular call can produce a huge response when the network is very busy. If it can, either make sure your software can handle the response as a stream or find another method to get that data.
The RPC interface was never designed for the volumes of data that the Bitcoin SV network handles. We have made many improvements to it, but some calls can still cause high load simply because we aren’t designing for that purpose and there are better ways to obtain most information than RPC.
7. Test on the STN
The Scaling test network is there for you test your application under high load conditions so you can be confident it will work well under stress. Running Bitcoin SV permanently on the STN can be expensive because we simulate the kind of network conditions we expect on mainnet in a year or two from now. However, you do not need to keep an instance online permanently. If you’re running a 64GB memory virtual machine for the few days needed to run your tests the cost is quite manageable. Talk to Brad, the STN operations manager and he may be able to advise on other options to test your application. For more information see:
Last words
The Bitcoin SV network is going through a process of rapid metamorphosis right now. Beginning from a state of a mesh network with many useless peers and difficult user interaction processes, and toward a state much more like Satoshi described where there is a densely connected network core with high powered nodes and users interacting (with easy interfaces) on the edges.
This model enables easier and more reliable user experience whilst eliminating much unnecessary load on the nodes so they can focus on the real work. A core principle of scaling archtitecture is “don’t do work you don’t need to”. And that’s precisely the model we are moving towards using Satoshi’s principle of peers interacting directly with each and not through middle men.
Such transformations inevitably come with growing pains as the participants slowly discard old ways of doing things that have been ingrained through 10 years of wrong thinking about Bitcoin should operate. But the Bitcoin SV ecosystem is making this transition very rapidly.
We’ve come a long way in a short time but there is more work do both on the core of the network and on the edges. We hope some of the above guidance is useful to you in finding the most efficient and profitable ways to use the Bitcoin SV network.
