I don’t see a reason why regtest should allow non-standard txs, as it makes testing mainnet behaviour such as #15846 unnecessarily hard and unintuitive.
Of course, testnet policy remains unchanged to allow propagation of non-standard txs.
I don’t see a reason why regtest should allow non-standard txs, as it makes testing mainnet behaviour such as #15846 unnecessarily hard and unintuitive.
Of course, testnet policy remains unchanged to allow propagation of non-standard txs.
Concept ACK.
FYI I found the title of the PR and the PR description a bit confusing, because it wasn’t clear to me if this was going to make it so that we would be able to configure a regtest node to accept non-standard transactions, or if regtest would be treated the same as mainnet and it would not be allowed at all.
Adjusted title as requested by @sdaftuar
Also, please review commit-by-commit. The first commit is a cleanup of (8d1de43f0c Remove internal miner), the others are explained in the commit subject line.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
84+relevant in production. The changes are mentioned for completeness.
85+
86+RPC
87+---
88+
89+- Example item
66@@ -67,14 +67,15 @@ def set_test_params(self):
67 self.num_nodes = 2
68 self.extra_args = [
69 [
70+ "-acceptnonstdtxn=1",
CScript([b'a' * 35])
In this case the property really is IsMainnet
, which does not have a bit allocated in the struct.
Personally, I don’t see why an enumeration can not have an additional type ChainType::CUSTOM_HYBRID
if needed. But if I am also happy to use string matching on the chain name (could lead to weird run-time behavior) or add a bit to indicate if the params are the mainnet params.
90+
91+Tests
92+-----
93+
94+- The regression test chain, that can be enabled by the `-regtest` command line
95+ flag, now requires transactions to not violoate standard policy by default.
28@@ -29,7 +29,10 @@
29 class BIP68Test(BitcoinTestFramework):
30 def set_test_params(self):
31 self.num_nodes = 2
32- self.extra_args = [[], ["-acceptnonstdtxn=0"]]
33+ self.extra_args = [
34+ ["-acceptnonstdtxn=1"],
35+ ["-acceptnonstdtxn=0"],
181@@ -182,7 +182,11 @@ def set_test_params(self):
182 self.setup_clean_chain = True
183 self.num_nodes = 3
184 # This test tests SegWit both pre and post-activation, so use the normal BIP9 activation.
185- self.extra_args = [["-whitelist=127.0.0.1", "-vbparams=segwit:0:999999999999"], ["-whitelist=127.0.0.1", "-acceptnonstdtxn=0", "-vbparams=segwit:0:999999999999"], ["-whitelist=127.0.0.1", "-vbparams=segwit:0:0"]]
186+ self.extra_args = [
187+ ["-whitelist=127.0.0.1", "-acceptnonstdtxn=1", "-vbparams=segwit:0:999999999999"],
188+ ["-whitelist=127.0.0.1", "-acceptnonstdtxn=0", "-vbparams=segwit:0:999999999999"],
"-acceptnonstdtxn=0"
from here since it’s default config
tested ACK faac8a22faa62dcde3ded60063eff8beb042bafb
A few small suggestions inline
1168@@ -1169,8 +1169,9 @@ bool AppInitParameterInteraction()
1169 }
1170
1171 fRequireStandard = !gArgs.GetBoolArg("-acceptnonstdtxn", !chainparams.RequireStandard());
1172- if (chainparams.RequireStandard() && !fRequireStandard)
1173+ if (chainparams.NetworkID() == ChainType::MAIN && !fRequireStandard) {
chainparams.RequireStandard()
? AFAICT it does the same thing.
RequireStandard()
and a DefaultRequireStandard
chainparams flag then?
enum class ChainType
refactoring commits (thanks for the review @sipa and @laanwj) and fixed up the release notes in the last commit (thanks for the review @practicalswift, @Sjors and @jnewbery)
Oops. Sorry, I rebased this PR on a later master which is how I got the cd33801.. hash.
utACK faa36e1303773bec382600cb70ccd65eb5bbd33b
It is equal to consensus.fPowNoRetargeting
73 "-limitancestorcount=50",
74 "-limitancestorsize=101",
75 "-limitdescendantcount=200",
76 "-limitdescendantsize=101",
77 ],
78+ [
102@@ -103,6 +103,23 @@ Low-level Changes section below.
103 Low-level changes
104 =================
105
106+This section describes RPC changes mainly useful for testing, mostly not
102@@ -101,7 +103,7 @@ class CChainParams
103 std::vector<SeedSpec6> vFixedSeeds;
104 bool fDefaultConsistencyChecks;
105 bool fRequireStandard;
106- bool fMineBlocksOnDemand;
107+ bool m_user_can_change_chain_params;
+1 on luke’s comment – you can’t change chain params, they’re a unique_ptr<const ..>
so the compiler would complain if you even tried…
Seems like it would be better named as m_allow_non_std_tx
or something, making the later test if (!chainParams.AllowNonStandardTx() && !fRequireStandard)
. (At least, I don’t think it ever makes sense to make -acceptnonstd=0
an invalid option)
you can’t change chain params, they’re a unique_ptr<const ..> so the compiler would complain if you even tried…
That sounds like an implementation detail to me. Effectively you can change the chain param: The const fRequireStandard
in the chain params global serves as default and the global fRequireStandard
is the effective value. I think having two globals with the same name (in different namespaces) is confusing and should go, but I am not doing this here.
My opinion is that user should be able to change chain params whenever they are running a test chain (e.g. testnet, regtest or testchains #8994 by @jtimon). And they should be forbidden to change them when they are running on mainnet.
The name of the variable is also an implementation detail :)
The way I look at it is ChainParams for mainnet/testnet/regtest is effectively a compile-time constant that includes consensus parameters, various policy defaults, and some constraints on user’s ability to change policy (this one, allow_fallback_fee). You can’t change any of those things (without recompiling). That you can choose something different to a default doesn’t mean you’re changing the default though, which is what you’d be doing if you were actually changing the chain params. Just like you’re not changing DEFAULT_BLOCK_MAX_WEIGHT
when you set -blockmaxweight
, eg.
Even in a testchains world, I think many of the chain params for testnet (or public signets) probably should remain hard to change – changing the address prefixes/hrp or default port or network magic or consensus parameters when you don’t know what you’re doing seems like a great way to shoot yourself in the foot, for instance. (If you do know what you’re doing, obviously you can change the code to do what you want and recompile)
m_user_can_change_chain_params
member is wrong. I could call it m_user_can_override_chain_params
(as opposed to overwrite/change) to make clear that chainparams are the default values, that can potentially be overridden?
m_fallback_fee_enabled
into it ought to work, but I think just having separate bools enabling the individual features is clearer.
m_fallback_fee_enabled
from the chain params later on. I can rename m_user_can_change_chain_params
to m_is_test_chain
, which should address both concerns raised in the comments here.
77@@ -78,7 +78,7 @@ class FullBlockTest(BitcoinTestFramework):
78 def set_test_params(self):
79 self.num_nodes = 1
80 self.setup_clean_chain = True
81- self.extra_args = [[]]
82+ self.extra_args = [['-acceptnonstdtxn=1']] # This is a consensus block test, we don't care about tx policy
70@@ -71,8 +71,8 @@ class CChainParams
71 uint64_t AssumedBlockchainSize() const { return m_assumed_blockchain_size; }
72 /** Minimum free space (in GB) needed for data directory when pruned; Does not include prune target*/
73 uint64_t AssumedChainStateSize() const { return m_assumed_chain_state_size; }
74- /** Make miner stop after a block is found. In RPC, don't return until nGenProcLimit blocks are generated */
75- bool MineBlocksOnDemand() const { return fMineBlocksOnDemand; }
76+ /** Whether it is possible to mine blocks on demand (no retargeting) */
77+ bool MineBlocksOnDemand() const { return consensus.fPowNoRetargeting; }
1149@@ -1150,8 +1150,9 @@ bool AppInitParameterInteraction()
1150 }
1151
1152 fRequireStandard = !gArgs.GetBoolArg("-acceptnonstdtxn", !chainparams.RequireStandard());
1153- if (chainparams.RequireStandard() && !fRequireStandard)
1154+ if (!chainparams.IsTestChain() && !fRequireStandard) {
I am happy to extend the docstring of IsTestChain
if it is not descriptive enough, but I’d like to keep it unless others agree that it should go.
I think it is useful to have a single boolean param to indicate whether the chain’s purpose is test-only.