p2p: enable -rejecttokens by default

[Retropex]

While OP_RETURN can have some legitimate use cases, I don’t believe runes do.

[chrisguida]

ACK

[BitcoinMechanic]

ACK

edit: after some more thinking, it's probably a bit much to target stuff that stays within the default 42 bytes. I can see either argument.

[wizkid057]

NACK

While I personally use this option, and agree that these tokens are worthless... I do not believe filtering it should default to enabled.

This conflicts with the decade+ standing default of datacarriersize=42, which the token protocol in question fits within. We can't both give a tolerated arbitrary data carrying option (necessary to prevent some more harmful data carrying) and then make defaults that suddenly don't treat that as arbitrary data.

The option should exist, but if we're to stick with the original premise of tolerating 42 bytes of data carrying as a compromise to dissuade other forms of more harmful data carrying, then we need to remain committed to that as a default and committed to treating that data as arbitrary non-Bitcoin data by default.

Otherwise future attacks on the network could be significantly more harmful. Imagine a situation where this particular token protocol didn't have this carve out available... that would have been significantly more harmful.

In short, node operators should and do have broad authority to determine what their node mines or relays. They should have options available to them to make use of that authority, including options that don't make sense as enabled-by-default options.

[luke-jr]

Not sure. At a minimum, this would need to change it back in the corepolicy defaults.

[chrisguida]

@wizkid057:

The only reason the Runes protocol was created in the first place is because it fit within standardness rules. The best solution to spam is to filter everything that proves harmful. I don't think OP_RETURN was envisioned as a sanctioned place for parasitic metaprotocols, and if it was, then I think that should not be its purpose. The point of OP_RETURN is to be able to stick a hash of some other data into a block.

Runes are harmful because they cause high-fee spam which crowds out legitimate use cases. The only real way to fight these metaprotocols is to directly filter them. Our unwillingness to directly filter these obviously abusive transactions has done nothing to deter spammers, and has instead emboldened them. Runes transactions should be filtered (along with BRC20) since these shitcoin metaprotocols have caused objective harm to bitcoin.

[Ataraxia009]

Mixed stance here.

I dont think we should by default filter transactions playing by the current mempool policy standard rules, like OP_RETURN below a certain size.

WE can maybe do this later if it starts becoming a major issue?

People really against any of this stuff can just set -data-carrier=0 and for now i think thats fine