RPC: sendrawtransaction: Allow the user to ignore/override specific rejections

[luke-jr]

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.

[jameshilliard]

concept ACK

[promag]

@luke-jr why not turn the second argument an JSON object to be more scalable. For instance, I was planning to add option unlockUnspents.

[MarcoFalke]

Wouldn't it make sense to finally get rid of fLimitFree, which is only hardcoded to false for the wallet and sendrawtransaction?

[luke-jr]

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.

[jameshilliard]

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.

[laanwj]

Sorry, no, this missed the feature freeze for 0.13 by a long haul.

[MarcoFalke]

Needs rebase on top of master instead of 0.13

[luke-jr]

@jameshilliard Knots has had this for a while. Miners should probably be using it anyway.

@MarcoFalke Rebased.

[paveljanik]

Concept ACK
Needs rebase.

[luke-jr]

Rebased.

Could be combined with #9422 to restore policy-bypassing transactions after a restart, but I consider that beyond the scope of this PR, and something to address after both get merged.

[sipa]

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)?

[TheBlueMatt]

Agree with @sipa. This is not going to be maintainable for API clients. Are you planning on rebasing this luke?

[luke-jr]

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.

[jameshilliard]

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).

[luke-jr]

@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.

[sipa]

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.

[laanwj]

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...)