RPC: sendrawtransaction: Allow the user to ignore/override specific rejections #7533
Conversation
luke-jr
force-pushed
the
sendraw_force
branch
from
71813d2
to
1cc1ce4
Compare
Github-Pull: bitcoin#7533 Rebased-From: 78bcf17
…rrideMempoolLimit and fRejectAbsurdFee) with flexible std::set of rejections to ignore Github-Pull: bitcoin#7533 Rebased-From: 9f03c06
…of rejections to ignore (in a backward compatible manner) Github-Pull: bitcoin#7533 Rebased-From: 1cc1ce4
Implements bitcoin#7442 by adding an option `-stdin` which reads additional arguments from stdin, one per line. For example ```bash echo -e "mysecretcode\n120" | src/bitcoin-cli -stdin walletpassphrase echo -e "walletpassphrase\nmysecretcode\n120" | src/bitcoin-cli -stdin ``` Github-Pull: bitcoin#7533 Rebased-From: 92bcca3
|
concept ACK |
|
@luke-jr why not turn the second argument an JSON object to be more scalable. For instance, I was planning to add option unlockUnspents. |
src/main.h
Outdated
| @@ -281,7 +281,22 @@ void PruneAndFlush(); | |||
|
|
|||
| /** (try to) add transaction to memory pool **/ | |||
| bool AcceptToMemoryPool(CTxMemPool& pool, CValidationState &state, const CTransaction &tx, bool fLimitFree, | |||
There was a problem hiding this comment.
Wouldn't it make sense to finally get rid of fLimitFree, which is only hardcoded to false for the wallet and sendrawtransaction?
There was a problem hiding this comment.
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 |
luke-jr
force-pushed
the
sendraw_force
branch
from
83b1290
to
079e96c
Compare
|
@jameshilliard Knots has had this for a while. Miners should probably be using it anyway. @MarcoFalke Rebased. |
luke-jr
force-pushed
the
sendraw_force
branch
from
079e96c
to
4b32b8b
Compare
|
Concept ACK |
luke-jr
force-pushed
the
sendraw_force
branch
from
4b32b8b
to
9eee2df
Compare
|
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. |
luke-jr
force-pushed
the
sendraw_force
branch
2 times, most recently
from
0132ffc
to
99d66e2
Compare
|
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. |
…rrideMempoolLimit) with flexible set of rejections to ignore
…in ignore_rejects
…of rejections to ignore (in a backward compatible manner)
|
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. |
|
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 |
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.