Coinjoin Fee Estimation #12046
Kruwed
started this conversation in
General & Publications
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Fee Estimation Problem
The coinjoin coordinator chooses the mining fee rate for all participants in the transaction. This fee estimation task is a difficult burden – The only thing more difficult than predicting the price of Bitcoin in the future is predicting the price of Bitcoin’s fees in the future.
Coinjoin fees should be high enough to satisfy users who set the “Coinjoin Time Preference” setting to “Hours”. The maximum timeframe for coinjoin confirmation should not exceed 24 hours in order to ensure users have predictable access to their funds.
Coinjoin fees should be low enough that we do not target next block confirmation. Coinjoining is already time consuming and most outputs are self spends, so overspending for immediate confirmation is not a huge benefit. Additionally, having coinjoin transactions wait in the mempool and confirm in groups provides better privacy since participants will be more likely to remix with new unique users as opposed to coinjoining with the same users in consecutive rounds.
Replaced coinjoins are very bad:
-Replacements can be catastrophic: When unconfirmed child outputs are consolidated with confirmed private coins and the coinjoin is replaced, the already confirmed private coins must be remixed again, costing even more fees. Users are not currently notified (with a label) that they must remix these coins to regain privacy.
-The coordinator fee is not collected if the transaction is replaced.
CPFP considerations:
-Even though it is impossible to predict the future, missing a correct fee estimation while getting it close is better since it makes it easier for CPFP spends to make up the marginal fee difference.
-Miners only calculate the highest paying branch of CPFP bids, not all combined CPFP bids. This can cause the lower bidding users spending outputs from the coinjoin to waste their fees.
-Having few coinjoins stuck is better than lots of coinjoins stuck because it is much more practical for a user to CPFP a single coinjoin than multiple coinjoins at once.
Existing fee management features:
-Users can opt out of high fees using the “Coinjoin Time Preference” setting. Users cannot opt into higher fee service beyond selecting “hours”, so we should always attempt to confirm a transaction within hours.
-Input/Output value selection by clients improves at high fee rates for better consolidation/block space efficiency.
Meta considerations:
-Our users are not cost sensitive, coinjoins and coordinator fees are an expensive luxury already.
-Payments in coinjoin are less practical if users have to wait for an unpredictable amount of time.
-Integrations partners inherit our fee decisions.
-Fees can go up at an unpredictable speed, but fees only go down at a predictable speed (with some randomness).
-Transaction broadcast happens ~20 minutes after the fee for the round is initially chosen.
-Clients contribute a small amount of leftover sats that can't be decomposed to the initial mining fee chosen by the coordinator.
Two Rule Estimator Proposal:
Fee estimation relies on looking at recently confirmed bids and currently pending bids. An effective fee estimator can be made with two rules, with additional weights/variables added for optional fine tuning.
Rule 1: Look at the previous 3 blocks mined. Do not bid any lower than the minimum inclusion rate of the 2nd highest paying block out of the 3. This rule prevents underpaying when blocks are mined faster than normal.
Rule 2: Look at the next 3 blocks in the mempool. Do not bid any lower than the highest fee rate of block depth 3. This rule prevents underpaying when blocks are mined slower than normal.
In this example where blocks were mined at ~double the normal speed, the fee estimator would pick 82 sats/vbyte due to rule 1, which looks at recent block history. Rule 2 would only require 70 sats/vbyte in this case, but it is trumped by rule 1.
In this example where blocks were mined at ~half the normal speed, the fee estimator would pick 85 sats/vbyte due to rule 2, which looks at the current mempool. Rule 1 would only require 75 sats/vbyte in this case, but it is trumped by rule 2.
Adjust for block time:
Optionally, fees can be adjusted in anticipation of faster or slower block times at the beginning or end of a difficulty adjustment cycle.
-During the first blocks of a new difficulty adjustment cycle, +fee if the difficulty increased from the last cycle.
-During the first blocks of a difficulty adjustment cycle, -fee if the difficulty decreased from the last cycle.
-During the last blocks of a difficulty adjustment cycle, -fee if the current cycle produced faster blocks.
-During the last blocks of a difficulty adjustment cycle, +fee if the current cycle produced slower blocks.
Add Introspective Analysis:
Even more optionally, complex adjustments can be added.
-If a fee estimate is close to making an standard sized input or output uneconomical to register, target that fee rate exactly.
-Feerates for normal payments are economically insensitive, there is an overt market for demand. If fees increase quickly due to normal payments being broadcast, it is less important to try to outbid them
-Feerates for inscriptions are economically sensitive, there is hidden market for demand. If fees increase quickly due to inscriptions being broadcast, it is more important to outbid these because they will continuously broadcast new transactions if fee rates drop low enough.
Beta Was this translation helpful? Give feedback.
All reactions