Proposal: take fee into account for anchor winner selection
- Dominant language
- C++
- Stars
- 397
- Forks
- 129
- PR merge metrics
- No merged PRs in 30d
Description
#### What would you like to be added:
Now, every valid anchor transaction in a "round" has an equal chance of being rewarded with the anchor reward. My proposal is to make the chance of getting the reward proportional to the fee paid for the anchor transaction.
E.g. for a (valid) anchor transaction X:
Now the chance of getting the reward is 1/(total # valid anchor transactions in this round)
Proposal chance: (fee paid for transaction X)/(total of fees paid in valid anchor transactions in this round)
#### Why is this needed:
Number of anchor transactions have increased recently. Some anchorers seem to make multiple anchor transactions to increase their chance of getting the reward (going over 40 transactions per round already).
This has adverse affects in my opinion:
- All those anchor transactions need to be stored by nodes (not sure if they are stored in the blockchain?)
- The (extra) anchor transactions take BTC block space without providing extra utility
- BTC is being burned by extra anchor transactions (3300 sats per transaction), and although opinions might differ BTC burning is generally not as much applauded as DFI burning
By making the reward chance dependent on fee paid, this would eliminate the incentive for anchorers to broadcast multiple transactions in a round. Furthermore, if anchorers would still apply the same budget, this would move sats from being burned to transaction fees, benefiting BTC "security budget".
Curious to hear feedback. Unfortunately my programming skills don't go further than some scripting in Python so afraid I won't be able to help in coding this proposal.
Contributor guide
Research direction
The issue names no files, tests, or entry points. Start by locating the C++ code that validates anchor transactions and selects the anchor winner, then define how fee-weighted probabilities handle zero or differing fees. Done means valid anchors are selected proportionally to their paid fees and regression tests cover the selection behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- blockchain
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100