Quote from: mikeywith on May 16, 2025, 03:58:59 AM

That said, everyone has the right to protest by making the relay of such data less efficient. By enforcing their own relay policies, non-miner nodes can slow down the spread of unwanted transactions -- not to actually stop them, of course, but more to get that warm fuzzy feeling of "I'm doing my part for the network."

I think the question of "keeping the datacarriersize knob or not" boils down to an evaluation of different possible effects:

- Spam [1] cost: If a significant percentage of nodes use the datacarriersize knob, then spammers (particularly those with a time-sensitive plan, e.g. a NFT on a certain block height) may be incentived to bribe [2] miners directly, increasing their cost. The crucial question here would be, how high is the average cost of this effect?
- Centralization risk due to direct miner bribing: Big miners and pools can increase their income due to direct bribing. This can increase the difficulty and price solo miners and not-that-profitable miners at small pools out of the mining game (may be a small effect, but it probably exists). [Edited, see here.]
- Social consensus: It may be helping to deter spam that nodes "protest" against it, making spammers "feel bad". I believe this however to be weak against financially profitable spam schemes. An indication that this could work would be for example a spam project which has reduced their data footprint due to user claims, or used commitments, or even other blockchains.
- Block propagation. Slower if the nodes have many different policy settings (as far as I understand it).
- Development cost. Higher if the knob stays there.

Some of these effects seem to be possible to be measured, so this could be an idea to move the discussion forward in a constructive way (I'm not following the PR discussion so that may have been mentioned there, but I think it's not a bad idea to list these effects here in simple language for those joining the discussion.).

Regarding development cost, a "compromise" could look like this: Core removes the knobs, but links to a patch or a patched version which is maintained by another team (and only contains these changes). Of course this would only solve this point, and the effects on the remaining points would still have to be evaluated.

[1] Yes I have read gmaxwell's comment on it, but I'm just using the popular term for it, as the effects on the user experience is a bit similar.
[2] Idem.