Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[burnchain] cap the upside of discount-mining #3095

Open
jcnelson opened this issue Apr 18, 2022 · 1 comment
Open

[burnchain] cap the upside of discount-mining #3095

jcnelson opened this issue Apr 18, 2022 · 1 comment
Assignees
Labels
consensus-critical icebox Issues that are not being worked on

Comments

@jcnelson
Copy link
Member

Discount mining is when a miner stacks their STX and leverages the fact that when their reward slots come up for PoX payout, they can pay as much BTC into them as they want (knowing they'll get it back) while also boosting their sortiton win probability. This permits unbound upside to discount-mining -- the only cost to doing so is the BTC transaction fee.

For 2.1, we can cap the upside by (a) measuring the distribution of BTC burns in the prepare phase, and (b) using some threshold function of that distribution to require that all miners burn BTC if they spend above the threshold on mining. This caps the upside of discount-mining, because then the discount miner must pay a proportionate amount of BTC to considerably boost their win probability.

A simple way to do this could be to take T = min(mean(winner_burns), median(winner_burns)) as the threshold, where winner_burns is the list of BTC burns for each winning sortition in the prepare phase, and require that if a miner spends B > k * T BTC on a block-commit (for some protocol-defined k), then B - k * T BTC must be burnt via the OP_RETURN output. We'd choose k so that it's highly unlikely that honest miners would be forced to burn BTC. We can infer it from historical prepare phases -- i.e. pick k so that k * T is higher than any block-commit ever seen for any prepare phase.

@jcnelson
Copy link
Member Author

A simple way to do this could be to take T = min(mean(winner_burns), median(winner_burns)) as the threshold,

This can't work. A discount-miner would simply run many miners paying at T, thereby bypassing the threshold. Our best bet so far seems to be something around sortition weight windowing, where it doesn't matter how many UTXO chains the discount miner controls.

@jcnelson jcnelson added icebox Issues that are not being worked on and removed back-burner labels Mar 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
consensus-critical icebox Issues that are not being worked on
Projects
Status: Status: 🆕 New
Development

No branches or pull requests

2 participants