During the past couple of weeks, many users experienced a period of higher than usual fees when using the Bitcoin network. A lot of this has been caused by the dynamics around the halving of the block reward on May 11th.
The halving causes difficulty for inefficient or high cost miners, given the smaller block reward relative to their overhead expenses. As expected, the Bitcoin network’s hashrate declined about 20-30% shortly after the halving, presumably from unprofitable mining operations turning off their machines.
However, a critical aspect of Bitcoin’s design known as the “difficulty adjustment” wouldn’t occur for another week after the halving. The difficulty adjustment calibrates the amount of work that needs to be done by the miners to produce a valid block of transactions. The amount of work necessary to create a valid block is called the “difficulty level” and is based on how much computing power is active on the network. The difficulty adjustment happens every two weeks and its purpose is to keep the network’s block production time as close to 10 minutes as possible throughout the lifetime of the network. The goal of 10 minute blocks isn’t an end in of itself but is rather there to maintain a fixed and predictable production (inflation) rate.
Since the network was operating under a difficulty regime based on the network’s hash power before the halving, and about 20-30% of hashing power exited the network, it was tougher for the network to make progress and create valid blocks in the target time of 10 minutes. A slightly slower network results in higher confirmation times and a backlog of transactions competing for blockspace. Essentially there was less block space per unit of time until the next difficulty adjustment took place.
In addition, there was a noticeable increase in volumes across exchanges and the network before, during, and after the halving. A slower network and more network traffic is a recipe for high fees.
The fee pressure has somewhat subsided since the network adjusted its difficulty level on May 18th, about a week after the halving. And exchange volumes as well as network activity have somewhat decreased. However, fees are still somewhat high, especially for smaller payments.
The Threat of High Fees to Bitcoin
Fees are a necessary part of the Bitcoin network. Miners need to be paid for their work, processing transactions and securing the network.
Miners are paid via new units of Bitcoin (inflation) and transaction fees. As the inflation rate drops over time to 0, fees will have to make up a larger and larger percentage of the rewards allocated to miners, eventually making up 100% of the revenue of miners about a 100 years from now.
Due to the increasing demand (transactions) for block space, micro-transactions and smaller payments that were possible in the early days of the network are no longer possible because the fee needed to be included in the next few blocks makes that payment irrational. An irrational fee is a fee that is larger or close in size to the actual payment trying to be made. Not many people want to make a $2 payment that requires $1 or more in fees to get it confirmed in a reasonable amount of time.
The Bitcoin community has routed around this problem by building an additional layer called the Lightning network, where microtransactions and small payments can be made extremely quickly at a very low cost. However, Lightning developers are also concerned that high transaction fees on the base layer, the Bitcoin blockchain, can make smaller payments on the Lightning network economically unattractive and insecure.
As fees rise on the base chain, progressively larger micropayments on the Lightning network become uneconomical to claim on the Bitcoin blockchain, because claiming them on the main chain will be more expensive than the value of the micropayments themselves. The security of Lightning payments depends on the threat of on-chain settlement. If this isn’t a threat because it becomes economically irrational to claim the payment, some payments may be put at risk. Most lightning nodes wouldn’t steal funds as they have strong incentives to behave and maintain connections with peers, but you would no longer be transacting trustlessly.
In addition, if the value of micropayments are lower than the current dust limit, hashed time lock contracts (HTLCs), the core technology used to trustlessly route payments in Lightning, cannot be used. If a channel broadcasted those micro-payments that are below the dust limit to the base chain, they wouldn’t be mined.
The dust limit is included in Bitcoin Core to limit bad behavior on the network, such as spamming the network with lots of low value transactions or deanonymizing users in a “dusting attack”. This limit was needed in the low fee environment of the first few years of Bitcoin, but in a high fee environment it isn’t as necessary and might be a thorn in the side for trustless micropayments in the Lightning network.
These are not intractable problems. Lightning developers are aware of them and are actively working on solutions, but they highlight how high fees on the first layer can negatively impact the second layer’s ability to support micropayments economically and trustlessly. It’s not always the case that high fees on the base layer makes Lightning more attractive. At a certain point high fees can make certain payments on both layers unattractive.
High fees themselves aren’t a threat to Bitcoin or Lightning’s existence but they do push certain economic activity away because it is no longer rational to use Bitcoin and even Lightning for small payments.
A regime of very high fees can push people into custodial solutions or trap them into custodial solutions. With high enough fees the value of the holdings of many could be made uneconomical to transact at the base layer without a third party.
Custodial solutions or Bitcoin “Banks” are not inherently a problem and represent something that’s clearly desired by the market. But they represent an increasing threat to Bitcoin’s assurances like privacy, censorship resistance, and inflation resistance the larger they get. Custodial solutions are a choke point for governments and reduce those assurances even if the Bitcoin banks are well intentioned. They have no choice but to comply if they want to continue doing business in the jurisdictions they operate in.
If fees get high enough on the base layer, more and more users will find custodial solutions more attractive because they may be able to offer reduced transaction fees. Their ability to operate at a considerable economic scale allows them to bundle the financial weight of their users for a reduced fee relative to what an individual would be able to garner on their own at the base layer.
The current ideological supporters of Bitcoin vociferously advocated for keeping the cost of running a full node low, which represents the cost of assaying the validity of a user’s coins, at the expense of higher potential transaction costs.
Keeping the cost low to run a full node aids in the decentralization of the network by keeping the barrier to operating a full node low and maintains the amount of autonomy an individual user has traditionally had in Bitcoin for a low price. However, if transaction fees get past a certain point many potential users with smaller economic weight will be pushed away from this autonomy to custodial solutions for economically rational reasons.
Although small on their own, collectively these small individual holdings can add up considerably, giving more economic weight to custodial solutions. The centralization of custody creates central points of failure, or choke points available to governments to shave off some of the attributes of Bitcoin for many users.
Both high costs to trust-minimized Bitcoin use and high transaction costs are threats to Bitcoin’s decentralization. Both must be appropriately low enough for a healthy network to flourish with the attributes that make the network valuable. The absolute minimization of the cost of one can make the other costly enough to threaten the decentralization of the network on its own.
How Edge Calculates Fees
The general fee level of the network is informally determined by the supply and demand of block space. In simpler terms, fees are determined by a fee market. As fees change, so do the recommended fees set by our app. We do not set the level of network fees, our app only responds to the current fee level and adjusts our recommendations accordingly. We help determine what a specific transaction should pay based on the data load of the transaction, the user’s preferences, and the current state of the fee market. And if a user wants to disregard our recommendations, they can set their own custom fee.
We start the estimation process by querying two fee estimating APIs: earn.com & mempool.space. We then take into account the specific transaction in question based on the payment amount, data load, and user preferences. Higher value spends have more wiggle room to pay more while we try to be as economical as possible with smaller value spends.
Although the value of the payment is important we must take into account the data load of a transaction. Bitcoin transactions involve the transmission and eventual storage of data. The heavier the data load the more the transaction will cost. The best real world analogy would be the difference in processing a payment of 10,000 pennies or ten $100 bills. The payment made in bills is a higher value payment but the 10,000 pennies will require more work and resources to process even though it’s a lower value payment. The person or group who has to process the payment in pennies would probably charge more because the amount of work and time needed to process is more onerous than the larger payment done in bills.
So if we come back to Bitcoin, we realize a miner cares more about the fee per byte than the overall value of the fee. A transaction could be paying a higher fee than another similar value transaction but if the data load is large on the high fee transaction that transaction might be paying less fees per byte than the transaction that has a smaller fee. As a consequence, a miner will choose the transaction with a smaller value fee because the miner really cares about its superior fee per byte. The miner cares about this because they only have so much space for transactions in each block. A transaction with a higher fee might pay more individually than another but because of its heavy data load it crowds out other transactions that could have possibly been included. Because of this we must focus on the ratio of fees per byte for every transaction.
We also bracket and estimate fees based on a High, Standard, or Low fee. By default we show users the Standard fee estimate, but users can choose the high option, the low option, or create a custom fee if they desire to.
The high fee estimate is looking to get the transaction into the next block and create a very high probability that a transaction will be confirmed by the network in the next 30 minutes (3 blocks). Because the fee market is always shifting we cannot guarantee its entry in the next 3 blocks but try to create a very high probability it does.
The standard fee estimate aims at a confirmation between two parameters: a 5 block target (50 min) and a 30 block target (5 hours). We cannot guarantee with 100% certainty the transaction will be confirmed within these targets but the transaction will more than likely fall between these targets.
The low fee estimate shoots for a 200 block target (33 hours). This doesn’t mean the transaction can’t or won’t confirm before 200 blocks pass but we try to make it so the user has pretty high assurances it will confirm in that amount of time. However users should also keep in mind that transactions with low fees have the greatest probability of being dropped by the network. This is a low probability but it is higher than the standard or high fee.
Sometimes users send a transaction with a standard or low fee, but then decide after they send the transaction that they want their transaction to confirm sooner. There is a way for a user to increase the likelihood of a quicker confirmation time and it’s by creating what’s known as a “Child Pays For Parent” (CPFP) transaction.
Child Pays For Parent
A CPFP is a transaction that helps give a higher priority to a previous unconfirmed transaction. A CPFP transaction creates a higher fee transaction that incentivizes miners to process the previous lower fee transaction. The higher fee transaction (the child) incentivizes miners to confirm the first low fee transaction (the parent) because the second, high fee transaction, relies on the first transaction being confirmed. To get the high fee (Child), miners must confirm the transaction with the low fee (Parent). Hence, Child Pays for Parent.
However, keep in mind, you will have to overpay relative to what you would have paid had you paid a higher fee initially. This is a result of increasing the data load for a miner. You’ll have to pay extra for the increased data load. If you only had one transaction that paid a high fee you would pay less in fees than sending a low fee transaction (parent), then deciding to speed up its confirmation with another transaction (child). You have to pay for the data load of two transactions instead of one. But it is good to have this option available if you need a faster confirmation than you originally thought.
The description of CPFP may sound complex but it’s very easy to do in Edge: click this to learn how to conduct a CPFP transaction in Edge.
Bitcoin is an elegant balancing of trade-offs and incentives. The extremes of no fees or astronomical fees, and no individual autonomy and required autonomy, are unsustainable. Miners need to be paid for their work but many users and use cases need manageable fees. Individuals should have the option of autonomy, but a user shouldn’t have to take total responsibility to use the network.
Whatever the fee environment, Edge is committed to providing the tools necessary for users to get the best experience possible for the best price.