The whole Citrea issue doesn't change anything from the technical reasons for and against this change. And I also think there is no Citrea issue at all, because Citrea only was brought up in a public mailinglist discussion, that's why Todd mentioned it in the PR discussion.
Personally seeing the resistance against a complete limit removal, I'm currently leaning towards a modest increase of the limit like propsed by @Ionko and @jaybny, up to 0,5-1 kB or so. This would be enough for sidechain/rollup proofs like Citrea's and other financial applications, but not enough for images with the exception of very small ones. Images would then probably still use the Taproot method, but they would use that anyway because it's cheaper and the Ordinals protocol is already established. And the "social consensus" still would be at least hint that at least from the perspective of Core OP_RETURN is not meant to be used for higher amounts of arbitrary data.
The only way this could lead to a hard fork is if the developers of alternative clients like Knots feel encouraged if there are now many full node operators switching to their clients, and try to establish an own protocol change mechanism. I think however the devs of these alt clients are still responsible enough to not try this.
Personally seeing the resistance against a complete limit removal, I'm currently leaning towards a modest increase of the limit like propsed by @Ionko and @jaybny, up to 0,5-1 kB or so. This would be enough for sidechain/rollup proofs like Citrea's and other financial applications, but not enough for images with the exception of very small ones. Images would then probably still use the Taproot method, but they would use that anyway because it's cheaper and the Ordinals protocol is already established. And the "social consensus" still would be at least hint that at least from the perspective of Core OP_RETURN is not meant to be used for higher amounts of arbitrary data.
I think Knots shows a more open, responsible, honest approach by giving the right and freedom to the community to decide what types of transactions can be on the BTC blockchain.
Fake address JPEGs FTW! interesting - can this lead to a hardfork?
No. This discussion is not about a protocol change. It's about standardness rules, basically default values, for the mempools. Every Bitcoin implementation can set these values as they like. One of the arguments for the change is also that it reduces maintenance cost.The only way this could lead to a hard fork is if the developers of alternative clients like Knots feel encouraged if there are now many full node operators switching to their clients, and try to establish an own protocol change mechanism. I think however the devs of these alt clients are still responsible enough to not try this.