RFC: Accept non-std transactions in Testnet4 by default again #32133
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code Coverage & BenchmarksFor details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32133. ReviewsSee the guideline for information on the review process. ConflictsNo conflicts as of last run. |
I don't think this is enough. There are many non-std transactions that will still be rejected, even if this is turned on. One example is #29843.
I don't think this is enough either. There are many transaction topologies that will be rejected as a single package in the mempool, when the mempool accepts the package in smaller bites, with each bite confirming first on the chain. One example is TRUC. |
Another example is 64-byte transactions which was surprising behavior to me when working the BIP to disallow them: Line 798 in e486597 |
In that case, the same setup that worked for testnet (getting a direct connection to a miner that is willing to support your consensus-valid but non-standard transactions) also works for mainnet, and they haven't shot themselves in the foot.
If you want to do your testing in situations where you can and will lose real money, then testing on mainnet is fine. That's not something I'd recommend though.
If someone would like to write up some (robust) support code for proposing custom blocks for a signet miner to validate and sign, I'd be happy to look into running that on my signet miner. |
I didn't mean that they setup this connection to a miner on purpose, I meant that they just happened to be connect to a miner by chance (which I think is much more likely to happend on testnet than on mainnet).
|
Even in that case, they've manually modified their own node to accept non standard transactions so they should have some chance of being aware that something weird is going on. Also, if it is the case that randomly connecting to nodes finds you a testnet miner that accepts non standard transactions, then relaying/mining those transactions is already easy and changing the option to be the default isn't going to be make anything easier.
Only after you've signed the transaction in your test environment with a real mainnet key that's protecting real mainnet funds. |
|
Tend toward -0. As mentioned above in my first comment, it is not sufficient to achieve the goal you are trying to achieve, so it mostly brings the downsides mentioned above with questionable benefits. Going forward, one could say the only way for developers to inject non-standard transactions into testnet_N is to ask a miner or rent some hashrate to do it. However, injecting test-only non-standard transactions into a test network comes with its own downsides, like requiring more exceptions for future soft forks in consensus code. Also, the demand for it right now seems limited, given that no one is working on creating a set of "interesting" transactions, and a method to inject them easily. Finally, I also wonder if it is really the best way to achieve the testing goal. Maybe just better maintenance of https://github.com/bitcoin-core/qa-assets/blob/main/unit_test_data/script_assets_test.json (or similar) and advertising it to be used by other node software seems possibly more worthwhile. |
I think it's reasonable for a bitcoin company to have a few sats in a mainnet hot wallet to use for testing, they don't need to touch their cold storage for this. Anyway, closing for now, my opinion on this hasn't changed much but I think it's better to focus on something else. |
Feel free to ignore the code, just looking for conceptual discussion for now.
It used to be the case that we would accept non-std transactions by default in Testnet3 but this was changed in #28354 because RSK had shot themselves in the foot because of this (see #26348). In discussions on Testnet4 this came up again as a potential feature but the idea to revert this was rejected then because the 20-min exception rule could be used as a way to get non-std transactions in the chain instead. We now know that the attention the 20-min got from the discussions in that PR and elsewhere has led to an exploitation of the rule that has basically made it unusable. While the frequent re-orgs are interesting to some as a robustness test, the ability to get non-std transactions in the chain does not seem to be there anymore. Recently darosior has suggested on the ML to remove the 20-min exception rule because of this development. If we go through with this, the question is why we are not also moving back on this setting, too, so that people can use non-std transactions on Testnet4. The only alternative left would be that they have to go to a different network or get their transaction to a testnet4 miner out of band.
The frequent argument I hear/read is that Testnet should behave like Mainnet but the reality is that we don't want it to behave like mainnet in all the ways because that would mean we can't really do all the testing we want. For example, we have introduced the timewarp attack protection as well on Testnet4. We also have kept the
-acceptnonstdtxnsetting around which but it is available on Mainnet. If we really wanted Testnet to always behave like mainnet we should have removed the setting too. Next time RSK could just have a connection to a miner who has set it to true and then they don't detect the error and shoot themselves in the foot yet again.And we do have
testmempoolaccept. This is the part that I really don't understand. By taking the stance of "Testnet should behave like Mainnet" people will rely on it even more but I don't think it's true that testing on testnet gives people 100% security their stuff will work on mainnet and people should not solely rely on that. The stance should be: If you want to make sure your tx propagates on mainnet then usetestmempoolaccepton a mainnet node. There is no alternative to that, don't rely only on testnet behavior when it's very important for you.