feat: add STX:BTC price ratio from on-chain data#6950
feat: add STX:BTC price ratio from on-chain data#6950brice-stacks wants to merge 27 commits intostacks-network:developfrom
Conversation
Uses the miner spending (in BTC) and miner earning (in STX) to compute a reasonable price ratio. Then, to smooth this price, to prevent miner actions from causing disruptions, we compute a weighted geometric mean over the last 5 cycles. This computation is currently available via `stacks-inspect` with the `get-stx-btc-ratio` command, and via RPC at the `/v3/stx_btc_ratio/` endpoint.
We'll need this for the STX/BTC pricing ratio calculation.
The median can't easily be computed, so retrieve it from the Bitcoin node with a new RPC interface.
This is an "expected" or estimated fee, not the actual fee. For our STX:BTC pricing, we only care about this expected fee.
In order to ensure nodes are all collecting the same data, gate the inclusion of the missed commit "burn" and the "expected" BTC fees for all commits. This can be enabled once we are sure that the changes to record these values in the DB have been guaranteed by a hard fork (likely 3.5).
|
I think this is enough for this PR. The next patch will handle computing this incrementally and caching the results. |
Later, when we cache these ratios, this auth can be removed.
|
@rob-stacks I know you're in the middle of reviewing this beast, so I will wait until you're done your first pass before I resolve the merge conflict, just to be sure I don't make things any more difficult for you. 🙏 |
| &self.client_id, | ||
| None, | ||
| "getblockstats", | ||
| vec![blockhash.into(), json!(["feerate_percentiles"])], |
There was a problem hiding this comment.
This endpoint makes me a little anxious.
Essentially, if we want to use the median fee rate to track STX/BTC ratio in consensus, we'd be incorporating the median fee rate returned here into the burnchain consensus. That means it is very important that this always return the same result for a given block. I'm not completely confident that bitcoind will do that. I think its the case today that these percentiles are deterministically calculated. But tweaks in how bitcoind computes the fee rate in particular would impact this (and there's plenty of freedom for design decisions on bitcoind's part there).
There was a problem hiding this comment.
Latest changes reverted back to calculating a mean simply from the info available directly in the block.
aaronb-stacks
left a comment
aaronb-stacks
left a comment
There was a problem hiding this comment.
The code looks good to me, but I have a couple comments on the approach here.
- I worry about the timing of calculations -- maybe we can make sure that there's no late appearing block if we don't include the prepare phase in the calculations (but even that, I think we'd need to have some kind of stall behavior to give the stacks-node enough time to process the last block of the reward phase), or worst case scenario, push the calculation a whole cycle backwards (so that when computing the ratio in order to calculate the reward set for cycle
n, we do the weighted average summations onn-2, n-3...-- or we pick some arbitrary other window (e.g., we start the window at 100 burn blocks ago). - The BTC feerate endpoint doesn't seem like it guarantees stability/consistency, which I think is a problem for us. It would be a pain, but it might make sense to calculate this ourselves while we're doing burn block processing. That way at least we can guarantee that the calculation is consistent.
| // the end of the target cycle. If there are no sortitions after the start of the next | ||
| // cycle, then we'll just use the latest sortition we have, which will undercount fees for | ||
| // the last tenure but is still correct for all previous tenures. |
There was a problem hiding this comment.
I'm inclined to say that for simplicity, we should just never count that last tenure. My worry is that trying to get that last tenure introduces the possibility that a node may not have processed the last tenure yet and so they run this calculation and get a different result than everyone else.
There was a problem hiding this comment.
My other related thought here is that it might be better to just do STX/BTC ratio calculation on the reward phases of the reward cycles (i.e., explicitly do not include the prepare phase in the calculation). This would ensure that when we're performing the reward set calculation, the reward phase has been totally completed.
There was a problem hiding this comment.
Okay -- followup thought: we could just start counting STX rewards backwards from the PoX anchor block. The PoX anchor block is already "blocking" on calculating the reward-set, so we can always assume that the PoX anchor block has been processed once we're performing the STX fee/coinbase accumulation.
So the range for the STX calculations is basically:
Fees paid in PoX anchor block -> Fees paid in earliest in-fork stacks block of cycle n-5.
And the range for the BTC calculations should "match":
BTC spend in the consensus hash corresponding to PoX anchor block (i.e., block.header.consensus_hash) -> BTC spend in the first burn block of cycle n-5.
There was a problem hiding this comment.
I agree, this makes sense. Let's do this change in #6965. I'm merging the latest changes from this one in to that one.
|
These rest of the changes are too tightly integrated with the changes in #6965. I'll close this one and continue there. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #6950 +/- ##
===========================================
+ Coverage 84.94% 85.00% +0.05%
===========================================
Files 412 413 +1
Lines 219958 220887 +929
Branches 338 338
===========================================
+ Hits 186849 187755 +906
- Misses 33109 33132 +23
... and 32 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
2 participants
Description
Implements a new on-chain pricing signal — the STX/BTC mining ratio — derived from what miners actually spend in BTC versus what they earn in STX. This ratio is intended to be consensus-critical in a future hard fork.
GET /v3/stx_btc_ratio/{cycle_num}returns per-cycle and 5-cycle smoothed μSTX/sat ratios.stacks-inspect get-stx-btc-ratiocommand for querying the STX/BTC mining ratio for a given reward cycle directly from a local chainstate.The new DB fields for tracking the BTC costs will be filled in immediately, but will not be used in the calculation until a later epoch, when we can guarantee that all nodes will have the data. This is necessary to ensure consistency if we make this computation consensus-critical in a future hard fork.
Note that the Bitcoin RPC code is moved from stacks-node into stackslib for reuse.
Checklist
docs/property-testing.md)rpc/openapi.yamlfor RPC endpoints,event-dispatcher.mdfor new events)clarity-benchmarkingrepo