RFC: Accept non-std transactions in Testnet4 by default again #32133

pull fjahr wants to merge 1 commits into bitcoin:master from fjahr:2025-03-nonstd-testnet changing 2 files +2 −3
  1. fjahr commented at 3:46 pm on March 24, 2025: contributor

    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 -acceptnonstdtxn setting 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 use testmempoolaccept on a mainnet node. There is no alternative to that, don’t rely only on testnet behavior when it’s very important for you.

  2. test: Accept non-std transaction in Testnet4 by default 5ea2b5efe7
  3. DrahtBot commented at 3:46 pm on March 24, 2025: contributor

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Code Coverage & Benchmarks

    For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32133.

    Reviews

    See the guideline for information on the review process. A summary of reviews will appear here.

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #32359 (Remove arbitrary limits on OP_Return (datacarrier) outputs by petertodd)

    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.

  4. maflcko commented at 4:02 pm on March 24, 2025: member

    the question is why we are not also moving back on this setting, too, so that people can use non-std transactions on Testnet4.

    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.

    If you want to make sure your tx propagates on mainnet then use testmempoolaccept on a mainnet node.

    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.

  5. maflcko added the label Brainstorming on Mar 24, 2025
  6. maflcko added the label Tests on Mar 24, 2025
  7. Christewart commented at 6:54 pm on March 28, 2025: contributor

    the question is why we are not also moving back on this setting, too, so that people can use non-std transactions on Testnet4.

    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.

    Another example is 64-byte transactions which was surprising behavior to me when working the BIP to disallow them:

    https://github.com/bitcoin/bitcoin/blob/e486597f9a57903600656fb5106858941885852f/src/validation.cpp#L798

    https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73#p-4382-native-segwit-v0-and-v1-programs-8

  8. DrahtBot added the label CI failed on Apr 29, 2025
  9. ajtowns commented at 9:01 am on April 29, 2025: contributor

    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.

    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.

    The stance should be: If you want to make sure your tx propagates on mainnet then use testmempoolaccept on a mainnet node.

    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.

    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.

    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.

  10. fjahr commented at 2:40 pm on April 29, 2025: contributor

    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.

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

    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.

    testmempoolaccept tells you if your transaction would be accepted without actually broadcasting it, no? How are you risking real money when you use it on a mainnet node?

  11. ajtowns commented at 10:35 am on April 30, 2025: contributor

    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.

    testmempoolaccept tells you if your transaction would be accepted without actually broadcasting it, no? How are you risking real money when you use it on a mainnet node?

    Only after you’ve signed the transaction in your test environment with a real mainnet key that’s protecting real mainnet funds.

  12. maflcko commented at 10:51 am on April 30, 2025: member

    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.

  13. DrahtBot removed the label CI failed on May 2, 2025

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2025-05-09 15:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me