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

Sendrawtransaction doesn't have a way to override certain types of transaction rejections #7241

Closed
jameshilliard opened this issue Dec 21, 2015 · 9 comments
Labels

Comments

@jameshilliard
Copy link
Contributor

I was attempting to add a pool payout directly to my mining pool's mempool using sendrawtransaction, however I had generated the payout with a wallet with a different dust threshold due to the pool running a significantly higher minrelaytxfee(to filter spam) than the cold wallet I use to generate batched payouts from.

I got this error when I tried to send the transaction using the rpc interface and haven't found a way to override it other than adjusting minrelaytxfee on the pool's node(which isn't really a solution since CNB/GBT performance degrades significantly when the mempool gets too big). I saw there was an override but it only appeared to do anything for high fees checks.

error: {"code":-26,"message":"64: dust"}

I think there should be a flag to only run the base validity checks on the transaction when sent through sendrawtransaction and skip the is-standard checks so that nonstandard transactions can be added to the mempool manually, maybe a way to adjust the dust thresholds independently from minrelaytxfee would also be good to have.

@maflcko
Copy link
Member

maflcko commented Dec 21, 2015

Related: #6824

@laanwj
Copy link
Member

laanwj commented Dec 22, 2015

The basic idea here is not to send transactions that we'd not accept ourselves. Given no other information that's a realistic assumption in a P2P network.

I wouldn't be against a way to force a transaction into the mempool (given that it validates consensus rules), but it should be made clear that this is only useful if you're a miner.

@laanwj laanwj added the Mempool label Dec 22, 2015
@jameshilliard
Copy link
Contributor Author

@laanwj Yeah, the intention here is that this would mainly for use by pools, the only other use case I can see this being good for would be for situations were a node's local policy is more restrictive due to some other config option than the the rest of the network, which seems to be the case here since the dust limit is tied to minrelaytxfee(I can see the logic in this but I think we should have a way to manually override it). I think the best way to do this would be to also have a flag to set the submitted transaction to maximum priority when being submitted through sendrawtransaction.

@pstratem
Copy link
Contributor

@jameshilliard this can be accomplished by calling proritizetransaction before sendrawtransaction

@jameshilliard
Copy link
Contributor Author

I tried that and it didn't help.

@pstratem
Copy link
Contributor

@jameshilliard What was the rejection message?

Possibly the transaction had no fees at all so hit the "free" transaction code before being checked against the fee deltas map.

@jameshilliard
Copy link
Contributor Author

It was the dust error in the OP. Transaction did have a fee so don't think it was that.

@pstratem
Copy link
Contributor

@jameshilliard oh right... yeah the deltamap doesn't override the dust limit

@maflcko
Copy link
Member

maflcko commented May 9, 2020

The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Closing due to lack of interest. Pull requests with improvements are always welcome.

@maflcko maflcko closed this as completed May 9, 2020
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants