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

Remove maxfeerate safeguard from sendrawtransaction API #84

Open
wants to merge 1 commit into
base: mempool
Choose a base branch
from

Conversation

mononaut
Copy link
Contributor

This PR sets the maxfeerate parameter in the sendrawtransaction RPC call to zero to allow transactions with any fee rate to be broadcast via the /broadcast and POST /tx REST APIs

(see https://bitcoincore.org/en/doc/26.0.0/rpc/rawtransactions/sendrawtransaction/)

@mononaut mononaut requested a review from wiz April 19, 2024 17:31
Copy link
Member

@junderw junderw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should make it an argument to disable. A simple bool flag like "allowhighfee".

Then on the front end, add a check box that is off by default and when they check it, make it REALLY CLEAR THAT THIS IS A BAD IDEA UNLESS THEY KNOW WHAT THEY'RE DOING.

For every user this helps, there will be 5 users that accidentally send huge fees because they don't know what they're doing.

@junderw
Copy link
Member

junderw commented Apr 20, 2024

At the same time, fees are getting up to like 10% of the default limit now, so a spike might tip them over the hard coded default...

Maybe we should be calculating the fee estimates on electrs side so we can have access to them and pass in the limit as a multiple of the low priority rate (less volatile). Maybe 500x.

@mononaut
Copy link
Contributor Author

We should just let users provide the maxfeerate themselves in the API request (and enforce the existing default otherwise), like the new testmempoolaccept endpoint.

This PR was a last minute thing for some customers anticipating problems during the halving madness.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants