Reduce BTC Stake Unbonding Delay from 1008 to 301 Bitcoin Blocks
Summary
“Unbonding delay” is the time between a BTC staker posting the unbonding transaction on Bitcoin and the staker being able to withdraw their BTC. This delay ensures that the BTC stake remains slashable until the Babylon Genesis chain gets checkpointed on Bitcoin, thereby preventing an attacker from evading slashing after finalizing conflicting blocks.
This proposal recommends decreasing the unbonding delay to 301 Bitcoin blocks (50h 10m on average). This improves user experience for Bitcoin stakers without sacrificing security. To maintain security with a high margin, we also propose an increase to the minimum slashing transaction fee, which ensures that slashing transactions will be included in the Bitcoin chain within a short time.
The analysis below derives a lower bound (smaller than 301 blocks) on the unbonding delay to ensure security. Due to practical constraints (described in the analysis) and for faster delivery, we choose 301 blocks. We will introduce in our roadmap code changes and additional testing to lower this even further if possible.
Parameters to Update
This proposal changes the following parameters in the x/btcstaking module:
unbonding_time_blocksfrom 1008 to 301min_slashing_tx_fee_satfrom 100000 to 150000
Note: The updated parameters will only apply to new stake transactions.
Background
The parameter unbonding_time_blocks is the relative timelock (measured in Bitcoin blocks) which keeps the output UTXO of the unbonding transaction on Bitcoin unspendable except by the unbonding slashing transaction until the timelock ends. After the timelock ends, the staker can spend the UTXO to an address of their choice. The parameter min_slashing_tx_fee_sat specifies the minimum tx fees the staker must provide for the slashing transaction or unbonding slashing transaction.
When a staker deposits new BTC stake, the staker pre-signs the unbonding slashing transaction (and other transactions) and submits the pre-signed transactions to Babylon Genesis. The btcstaking module in Babylon Genesis verifies that these transactions contain the correct fees and timelocks.
Analysis
The goal of the analysis is to calculate the minimum unbonding delay required to ensure slashable safety of Babylon Genesis. Slashable safety means that if two conflicting chains are finalized by (a 2/3 quorum of) BTC stake and neither chain has been checkpointed on Bitcoin, then at least 1/3 of BTC stake should be slashed. If one of the chains has been checkpointed, that chain is considered canonical. A client running a BTC monitor can observe checkpoints posted on Bitcoin and ensure that the chain it finalizes doesn’t conflict with the latest checkpoint on Bitcoin. Although such a rule is not currently implemented, it can be enforced through a software upgrade.
To calculate the minimum unbonding delay, we will determine the critical path of events that imposes the tightest constraint on the unbonding delay. We will then estimate the latency of different events in the critical path. Here are the events on the critical path and a diagram depicting them:
- Unbonding transaction included in a Bitcoin block.
- A BTC staking tracker observes the unbonding transaction and reports it to Babylon using a MsgBTCUndelegatemessage. This removes the voting power corresponding to this BTC delegation. This process takes maximum time UNBONDING_TRACKER_LATENCY.
- At the end of the epoch, a checkpoint is created. This happens after at most EPOCH_DURATION time.
- The checkpoint transaction is included on Bitcoin. This takes time at most CHECKPOINTING_LATENCY.
- The checkpoint transaction becomes BTC_CONF_DEPTH deep on Bitcoin. This ensures that the attacker cannot mine a fork of Bitcoin that doesn’t contain the checkpointing transaction.
- The client’s BTC monitor sees the checkpoint as BTC_CONF_DEPTH deep after at most NETWORK_LATENCY time.
- In the worst case, the adversary who unbonded their BTC stake releases their finality signatures for two conflicting blocks just before the monitor sees the BTC checkpoint for that epoch. In this case, this BTC stake should be slashed. So, we want a BTC staking tracker to discover this safety violation and post a slashing transaction on Bitcoin before the unbonding occurs. This takes at most SLASHER_LATENCY time.
So, UNBONDING_DELAY > UNBONDING_TRACKER_LATENCY + EPOCH_DURATION + CHECKPOINTING_LATENCY + BTC_CONF_DEPTH + NETWORK_LATENCY + SLASHER_LATENCY
Estimating the Parameters
Now, let’s calculate the minimum values for each of these latency parameters.
Let BITCOIN_LATENCY(TX) be the latency between submitting a transaction TX to the Bitcoin mempool and it being included for sure in the canonical chain. BABYLON_LATENCY(TX) is defined similarly for Babylon Genesis.
- UNBONDING_TRACKER_LATENCY = (time for BTC staking tracker to observe the unbonding transaction) + BABYLON_LATENCY(BTCUndelegate) = around 12 hours (an estimate). We will assume that Babylon Genesis is live. If 1/3 Babylon stake is malicious and stall liveness permanently, then there is not much we can do. But this latency accounts for temporary loss of liveness due to a chain halt, validators crashing, or mempool spamming attacks.
- EPOCH_DURATION = Currently 360 blocks * 10 seconds/block = 1 hour.
- CHECKPOINTING_LATENCY = BITCOIN_LATENCY(Checkpoint) = 18 Bitcoin blocks. The checkpoint consists of 2 Bitcoin transactions, so the latency measures the time taken for both to get included. BITCOIN_LATENCY(Checkpoint) need not be very strict because the submitter can add fees to the tx (through RBF or CPFP) if delayed.
- BTC_CONF_DEPTH = 30 Bitcoin blocks (an attacker with 25% of Bitcoin’s hashrate cannot mine a 30-deep fork with more than 0.01% probability).
- SLASHER_LATENCY = (time for BTC staking tracker to observe the equivocation) + BITCOIN_LATENCY = 18 Bitcoin blocks (see below for complete analysis). BITCOIN_LATENCY(Slashing) should be strict and the presigned slashing transaction should include high amount of fees because there is no mechanism to increase the fee dynamically.
Convert the time parameters to number of blocks. 13 hours has at most 100 blocks with 99% probability.
With this analysis, we need minimum 30+36+100=166 blocks unbonding delay.
Practical Constraints
Although the analysis reaches a smaller lower bound than the one in this proposal, the current Babylon Genesis node enforces an invariant requiring the unbonding delay to exceed the checkpoint finalization timeout which is currently set to 300 BTC blocks. Removing that invariant would require extensive code changes and additional testing, which will delay deployment. To expedite an unbonding‐delay reduction, we therefore propose lowering the delay to 301 blocks now, with a potential further reduction being examined in the future.
Timeline
Governance proposals will be raised on both the Babylon Genesis and Babylon Testnet networks to implement the proposed changes. If approved, the changes will take effect as follows:
- Babylon Testnet: July 9, 4PM UTC
- Babylon Genesis: July 14, 9AM UTC
Appendix: Calculating Bitcoin Latency and Slashing Transaction Fees
Mempool Flooding Attack
To calculate an upper bound on BITCOIN_LATENCY, we analyze an attack in which the attacker tries to flood the Bitcoin mempool with many transactions with a slightly higher fee rate than the slashing transaction to prevent the slashing transaction from being included on chain. If the slashing transaction doesn’t get posted within BITCOIN_LATENCY, then the attacker wins because the timelock on Bitcoin expires and the attacker can unbond their stake. Lower the fees, longer the latency because miners are less incentivized to include the transaction.
The slashing transaction has a default fee presigned by the staker: SLASHING_FEE_RATE sats/vByte. In the case of slashing transactions, the total fee is currently 100,000 sats for a transaction size of 355 vB. This makes SLASHING_FEE_RATE = 280 sats/vB.
If the attacker wants to prevent the slashing transaction from being included on chain, the attacker must flood the mempool with transactions occupying the entire BLOCK_SIZE with fees at least SLASHING_FEE_RATE sats/vByte. Alternatively, the attacker must bribe the miners with BLOCK_SIZE * SLASHING_FEE_RATE per block to incentivize the miner to not include the slashing transaction. The attacker has to pay this fee for every block during the period BITCOIN_LATENCY. So, we have:
ATTACKER_COST($) = BITCOIN_LATENCY(blocks) * BLOCK_SIZE(vB/block) * SLASHING_FEE_RATE($/vB)
The attacker is only interested to pay this cost if the attacker’s profit from the attack exceeds the cost. Suppose the attacker represents a collusion of all the BTC stakers and finality providers. Suppose all the finality providers get together and equivocate. If the attacker evades slashing then the attacker’s profit is
ATTACKER_PROFIT($) = TVL($) * SLASHING_RATE
This is the worst-case profit an attacker could make. Note that ATTACKER_PROFIT does not included external profits gained by double-spending on Babylon Genesis since those profits occur irrespective of whether the slashing transaction occurs on Bitcoin.
The attacker will be deterred if ATTACKER_COST > ATTACKER_PROFIT. Therefore, we set
BITCOIN_LATENCY(blocks) * SLASHING_FEE_RATE($/vB) > TVL($) * SLASHING_RATE / BLOCK_SIZE(vB/block)
Equivalently,
BITCOIN_LATENCY(blocks) * SLASHING_TX_FEE($) > TVL($) * SLASHING_RATE * SLASHING_TX_SIZE(vB) / BLOCK_SIZE(vB/block)
Given TVL = 50,000 BTC, SLASHING_RATE = 0.001, BLOCK_SIZE = 1 vMB, to prevent the attack we need
BITCOIN_LATENCY(blocks) * SLASHING_TX_FEE(sats) > 1,774,944
With the current SLASHING_TX_FEE = 100,000 sats, TVL, and SLASHING_RATE, BITCOIN_LATENCY = 18 blocks or 3 hours is achievable, i.e., it does not make sense for an attacker to censor the slashing transaction for more than 3 hours.
To have additional security margin, this proposal sets SLASHING_TX_FEE to 150,000 sats.
For the checkpointing transaction, currently SLASHING_FEE_RATE = 2.265 sat/vB and TX_SIZE = 200 vBytes. Although this fee rate is very low, this attack is not of much concern for the checkpointing transaction since it is easy to bump up the fees using either RBF or CPFP.
Miner Bribing Attack
The mempool flooding attack is the simplest to pull off since it does not involve any collusion with Bitcoin miners. A more sophisticated attacker might offer a bribe to miners, which will be paid if and only if the miner mines a block and the block only includes transactions specified by the attacker (“buying the block space”). This bribe may cost only α * CURRENT_FEE_RATE * BLOCK_SIZE (say α = 5), much less than SLASHING_FEE_RATE * BLOCK_SIZE because the miner does not know about the slashing transaction that will appear in the future. However, the attacker can realistically only bribe a fraction of the mining power, say β = 1/2. Among k consecutive Bitcoin blocks, at least one will be from a non-bribed miner with probability 1 - β^k and such a block will include the slashing transaction in the block they miner. Therefore, with 99% probability, the slashing transaction will be included in a Bitcoin block after 7 blocks. So, BITCOIN_LATENCY = 18 blocks already takes care of this attack.