pull down to refresh
because a permissive policy can "impose" their will on other nodes that have more restrictive policies ...
The caveat is: if there are miners willing to mine it. Some of the pool operators are closely following default policy, and others are much more permissive. I still think that this pluralism is the feature of Bitcoin.
But what this means practically: if only 10% of the hashpower will mine your default-non-standard tx, it'll on average take 10x longer for your transaction to be included. I remember someone experimenting a year or 2 ago (iirc in BitVM context, not 100% sure though) and waiting 2+ weeks for a larger non-standard tx to be mined. So you'll have to be patient, pay premium, actively rebroadcast, do some preferential peering, and so on.
... we succumb to the idea that it could work the other way too: a restrictive policy could be imposed on nodes with less restrictive policies.
I did this math multiple times but I suck at it, so do correct me if I fuck up here. If you want to fully restrict a peer from propagating across 125 connection slots through a policy, with 99% certainty, you need of the network enforcing your policy. For 80% certainty, you need 99.821%... for a 50/50 shot, 99.447%...
Which is why it doesn't work the other way around.
Exactly what @optimism says here: policy is capable of discouraging new behavior from taking a first foothold, or as long as almost the entire hashrate does not accept the new behavior. Low-feerate transactions had been propagating on the network for years before the sub-sat-summer, but when one miner started including the low-feerate transactions the behavior was adopted quickly by a larger part of the network.
I don’t have the exact numbers on hand, but I agree with Optimism that a surprisingly low adoption among the node population is sufficient for transactions to propagate somewhat reliably, even more so if they are preferentially peering. Laurent had some interesting simulation results regarding transaction propagation here: https://x.com/LaurentMT/status/1973416866212180089.
I suck at the math worse than you but came to the same conclusion.
What I find fascinating is how many people believe wholeheartedly in the efficacy of rule enforcement by policy -- despite it's rather weak abilities.
I really enjoyed Waiting for Confirmation. it's an excellent piece of work!
It's interesting how so many people (myself at times included) get caught in thinking that policy can do more things than it actually can.
Part of the problem may be that since policy can be used for DoS protection (https://bitcoinops.org/en/newsletters/2023/06/14/#waiting-for-confirmation-5-policy-for-protection-of-node-resources), there is an assumed extension that policy can be used to "enforce" preferences on the network.
In my comment quadratic hashing type transactions (#1493225) I was attempting to refer to those maximally computationally intensive transactions referred to in Waiting for Confirmation. I have a memory of Steve Lee at a bitdevs several years ago discussing with some passion the need for such transactions to not be mined. My impression was that policy defaults were also mentioned as a way to assist with this.
If it is the case that policy can discourage such quadratic hashing transactions, it's not hard to see how the BIP 110 filterers think that they can discourage transactions with policy choices.
I remember a very helpful comment you made on here some years ago in response to a question I had about whether one could "enforce" a soft fork with policy. I believe your answer was that it would not work because all it takes is one miner to mine a block violating the fork and the thing falls apart. (your answer was much more eloquent and probably included other helpful details).
So, the question I think Perley needs resolved is this: can policy choices of any given node or nodes impose their will on other nodes?
I appreciated @optimism's response that
Perhaps this is the point that confuses people like Perley and myself (if Perley is confused, and it's not just my own misinterpretation of what he said): we think that because a permissive policy can "impose" their will on other nodes that have more restrictive policies (impose isn't the right word, because they are just following the block validation rules all nodes agreed to), we succumb to the idea that it could work the other way too: a restrictive policy could be imposed on nodes with less restrictive policies.