Quote from: tvbcof on May 11, 2025, 08:35:06 PM

What is this standard, where is it defined, and how is it enforced?

"Standardness" are rules you can use to when configuring your node to control some aspects of the transactions or blocks you relay. They're not part of the consensus, so if you configure these settings differently other nodes won't reject your node. So they are not "enforced" in the network. And if a miner mines a block with transactions which do not comply with your standardness settings, your node would process these blocks anyway.

Their main purpose is to give the nodes capabilities to act agains DOS attacks. For example if someone is spamming thousands of transactions to the network with complicated scripts with a lots of calculations to do for nodes, this could make your node go offline (depending on your hardware). You can thus set these transactions as "non standard" and refuse to relay them. Bitcoin Core does have several of these "restrictions" enabled by default. But you can also chose to disable them if you want.

The values afaik are defined in the "policy" file or groups of files of the source code, so before you compile Core you can change them, or use a patch.

The OP_RETURN limit was not set because of a danger of DOS. It was instead set to "nudge" protocols like tokens (e.g. Counterparty or Omni, which were already around in 2014-15) to use the least amount of on-chain data possible. It can't be prevented however that this data is stored in fake public keys which look like a regular transfer of Bitcoins but actually can never be spent. [1] Protocols like Bitcoin Stamps / Stampchain do exactly this. And then the Ordinals wave in 2023 happened, where people learned to stuff data into the witness. In theory you could filter this with standardness rules like Knots does, but the protocol developers may come up with a little change and your filter becomes useless. At least such filters create a lot of maintenance cost for the Bitcoin client development team.

The maximum transaction size is another one of these standardness limits and is independent from the OP_RETURN limit. It's currently 400,000 weight units or normally 100 kBytes (See what gmaxwell wrote). A little less than these 100 kB would be the maximum amount of data the nodes would consider standard for an OP_RETURN output if the OP_RETURN byte limit was removed.

But as you may have read elsewhere and @gmaxwell just posted, in the Ordinals wave some miners didn't care at all about the standardness rules, and mined for example a block with a single transaction with 3,9 MB or so in February (?) 2023.

Quote from: tvbcof on May 11, 2025, 08:35:06 PM

Could I pay a mining pool to mine me a block with 3+ MB of contiguous data of my choice and expect it to reside on unprunned blockchains indefinitely?

You can do that already now.

Quote from: tvbcof on May 11, 2025, 08:35:06 PM

That is to say, are there hard enforcements on the (seemingly rather generous) transaction size standardness rules, or would someone who had the resources be able to ignore them successfully?

No, as explained above. Of course the more nodes have enabled a "standardness" restriction, the more difficult it gets for a transaction which doesn't cater to these rules to get mined -- in theory. But financial incentives makes it quite easy to get non-standard transactions mined if you pay a higher fee.

Unfortunately this also creates an incentive for centralization, because it provides big mining pools an additional source of income, hurting the economics of smaller pools and solo miners who are already at a disadvantage. If the big miners have an additional source of income, this indirectly boosts the difficulty (because they can invest in more hardware) and thus makes it more expensive to mine for all miners, but small miners won't have this source of income.

One can say in a simplified manner that the more restrictive the standardness settings are (in comparison to the "hard" consensus limits like the block size), the stronger this centralization effect is. Lifting the limits would thus be an anti-centralization measure. It would hurt the big miners most who charge high fees for non-standard transactions (and that's why it's not surprising that a mining pool representative was against it in the mailing list discussion).

Edit: [1] there is actually a way to require that the keys must create a spendable output, but this still allows to stuff data into these fake public keys, albeit a little bit less. But afaik it would lead to more resource usage for the nodes to control this, so I guess the developer consider it's not worth it.