Replace boolean allowhighfees with an Array of rejections to ignore (in a backward compatible manner)
This is useful for node operators who wish to manually accept transactions that don't meet their typical policies, yet don't necessarily want to override all the policies.
It's a bit ugly internally - suggestions on improving that are welcome.
concept ACK
280 | @@ -281,7 +281,22 @@ void PruneAndFlush();
281 |
282 | /** (try to) add transaction to memory pool **/
283 | bool AcceptToMemoryPool(CTxMemPool& pool, CValidationState &state, const CTransaction &tx, bool fLimitFree,
Wouldn't it make sense to finally get rid of fLimitFree, which is only hardcoded to false for the wallet and sendrawtransaction?
It does already support ignoring "rate limited free transaction" failures, but fLimitFree not only bypasses such failures, it also exempts the transaction from the rate limiting count entirely.
Is this something that we might be able to get in 0.13? Without something like this the alternative for pool operators is usually to patch out the problematic is-standard check blocking the send which is usually not desired.
Sorry, no, this missed the feature freeze for 0.13 by a long haul.
Needs rebase on top of master instead of 0.13
@jameshilliard Knots has had this for a while. Miners should probably be using it anyway. @MarcoFalke Rebased.
Concept ACK Needs rebase.
I'm not convinced about the need to ignore based on the exact reason (as that is likely something that's hard to maintain, as reasons change over time). How about just a boolean to bypass standardness/fee/mempool policy rules (but keep consensus and script execution flags for upgradability)?
Agree with @sipa. This is not going to be maintainable for API clients. Are you planning on rebasing this luke?
Typically people only want to bypass a specific policy, and not others. For example, a miner might want to bypass the fee checks or bypass the ancestor limit on replacements, but not other policies.
Will have a rebase done soon.
I don't think it's all that important to have the ability to have granular overrides, if that's important to some miners it can be implemented externally, most of the time a miner will just want to force add the transaction and will have already checked that it violates policy rules(often by looking at the failure reason when they try and send it normally).
@jameshilliard It can't be added externally... Looking at the first failure reason won't tell you if it violates other policies as well.
Anyhow, rebase is ready for review, and refactored somewhat so hopefully it's also easier to review.
BIP22-like
I think the ability to override specific rejection reasons is overkill, and risks creating an interface that is unmaintainable.
A boolean to say "ignore all policy, accept if consensus-valid" would be fine, though.
Agree with @sipa, making this too granular makes this unmaintainable as rejection reasons might come and go, or implemented differently, as policy changes. After all, policy is not standardized. (on the other hand ,the interface would be expected to change based on policy changes...)
I've just been mulling over this. How about giving node operators a hook, and allowing them to implement this sort of functionality themselves if they need it. I note that no node operators aside luke have requested this functionality here. I don't know how practical my suggestion is.
this seems kool lets merge it
Needs love (as in, needs rebase and addressing concerns). A simpler alternative is probably the best way to move this forward. Some examples of use cases would be nice too; "node operators who wish to manually accept transactions that don't meet their typical policies" is a bit vague.
Closing and adding "up for grabs", this is the oldest PR and has been inactive for quite long, too
Did something like this in #20753