BitMEX Research: Time locks are crucial to Bitcoin's long-term security
TechFlow Selected TechFlow Selected
BitMEX Research: Time locks are crucial to Bitcoin's long-term security
Considering the decision to add a lock-up period to a transaction is akin to a tragedy of the commons.
Navigating Web3 tides with focused insightsAuthor: BitMEX Research
Translation: 1912212.eth, Foresight News
In several months, possibly April 2024, Bitcoin’s block subsidy will halve to just 3.125 BTC. Until now, Bitcoin has relied on the block subsidy to secure the network. However, in our view, in the coming years Satoshi’s vision that “the incentive can transition entirely to transaction fees and be fully free of inflation” will begin to be tested. There has been ongoing discussion about whether Bitcoin can achieve this while maintaining security.
For example, if fees are high enough to ensure network security, would that eliminate certain popular use cases? Another consideration is what role alternative use cases like Ordinals might play in generating sustainable miner revenue? In this report, we focus on what we believe is a key component in transitioning incentives to fees—the often-overlooked time-locking functionality in Bitcoin.
Bitcoin Time-Locking Features
Bitcoin has four types of built-in time-locking features. These mechanisms ensure that Bitcoin transactions can only be included in the blockchain after a specific time or block height. The table below outlines the various types of time locks.
The following example transaction structure shows how multiple types of time locks can be used within the same transaction and illustrates where time locks appear in a transaction.
The illustration shows where various locktime options can be placed within a transaction.
Source: BitMEX Research
In addition to the above, it should be noted that outputs from coinbase transactions have a relative timelock of 100 blocks, which can be considered another type of time lock.
Fee Competition and Miner Incentives
When block rewards decline and incentives shift toward fees, what provides security is not merely the fees associated with incoming transactions. The security of confirmed transactions also depends on fees related to other transactions. If you receive a large Bitcoin payment—say $10 million—in an untrusted environment, the fee associated with that single transaction may not provide much security after just one confirmation. The sender could create a conflicting transaction with a much higher fee—say $500,000—and attempt a double spend. Some miners might then be tempted to reorganize the chain backward by one block to capture the higher fee.
Of course, miners generally do not want to perform such reorganizations. Miners prefer to mine at the tip because other miners build on the longest proof-of-work (PoW) chain. If a miner attempts a backward reorganization, their block is more likely to become orphaned, resulting in no reward. On the other hand, if the incentive for reorganizing backward is sufficiently large—due to a significant difference in revenue between mining at the tip versus reorganizing—some malicious miners might exploit this opportunity.
Bitcoin has several features that mitigate this problem. The first is the block reward. Since a large portion of miner incentives is fixed, the motivation to reorganize backward solely for additional fees is small. As block rewards decrease, another mechanism should prevent such attacks: the so-called deep mempool. This is the idea that Bitcoin blocks will remain consistently full, and there will always be a permanent backlog of transactions in the mempool, along with associated fees, which incentivize miners to extend the chain forward. With a deep mempool, there is always some revenue available from mining at the tip. This concept was highly controversial during the block size debate, with proponents of larger blocks opposing full blocks and a deep mempool. Regardless of one’s view on the deep mempool, locktimes are important here. The deep mempool security model works better when senders set locktimes to the current block height.
Simplified, consider a malicious miner contemplating a one-block reorganization when block rewards are low. Without locktimes, the miner could examine all transaction fees in the previous block and the mempool, then select the highest-fee transactions from both sets to construct a new block. If the total fee income from this approach far exceeds what could be earned mining a new block at the tip, the miner might attempt a reorganization. Conversely, if everyone uses locktimes set to the current block height, then any new high-fee transactions in the mempool cannot be included by a miner attempting a backward reorganization. Such a miner could include only some—but not all—of the highest-fee transactions. Any newly broadcast high-fee transaction with an enabled locktime thus encourages miners to build at the tip. As a result, the incentive to reorganize backward is reduced. In our view, this feature is crucial for Bitcoin’s long-term security.
Bitcoin Core Default Settings
Since late 2014, transactions generated by Bitcoin Core wallets have defaulted to setting the locktime field to the current block height to prevent fee sniping. As stated in a comment in the Bitcoin Core codebase here:
For large miners, the value of transactions in the best block and mempool may exceed the cost of deliberately attempting to mine two blocks to invalidate the current best block. By setting nLockTime so that a transaction can only be included in the next block, we prevent this behavior, as the limited block size and height restrictions reduce the options available to fee-sniping miners attempting such an attack. Simply put, from a wallet perspective, we always want the blockchain to move forward. By setting nLockTime this way, we are essentially signaling that we only want this transaction to appear in the next block; we do not wish to potentially encourage reorganizations by allowing the transaction to appear at a lower height on a fork of the best chain.
To our knowledge, few other wallets enable locktimes by default, and most adoption comes from users of Bitcoin Core. It is worth noting that the Electrum Bitcoin wallet also sets locktime to the latest block height.
We plan to provide more data and statistics on the usage of various time locks in the coming weeks. However, some charts related to time lock adoption can currently be found on this website.
The data shows that adoption of absolute block-height-based time locks increased in early 2015, reaching around 20%. We attribute this rise to Bitcoin Core wallets adopting absolute time locks as the default strategy in late 2014. Since then, adoption has fluctuated around 20%, but declined to about 10% in 2023. We believe this drop is due to the adoption of Ordinals and BRC-20 tokens. This new use of the blockchain has deterred some other users, and to our knowledge, transactions related to Ordinals typically do not enable locktimes by default.
Adoption of date-based absolute locktimes is very low, limited to niche use cases. Prior to Ordinals, usage peaked at about 0.1% of all Bitcoin transactions, dropping to around 0.05% after the rise of Ordinals.
Conclusion
The decision to include locktimes in transactions resembles a "tragedy of the commons." Individual users may simply want their transactions confirmed regardless, and may not care about the broader security benefits that locktimes provide to the Bitcoin network. On the other hand, the scale of this apparent coordination problem is small, since the cost of adding locktimes to transactions is minimal. Almost no users make this decision on a per-transaction basis, and most users aren’t even aware of what locktimes are. In most cases, it depends on the default settings of the wallet they use.
We believe that widespread adoption of locktimes is crucial for Bitcoin’s long-term security and encourage wallet developers to implement them. The current ~20% adoption rate seems quite low. Bitcoin advocates may now have another slogan to promote:
-
Control your own private keys. Not your keys, not your coins! Sell BlackRock ETFs and buy real Bitcoin!
-
Run your own node to fully validate incoming transactions.
-
Set locktimes on your transactions and/or use wallets that add locktimes by default.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@BitMEX
