Help me understand. 1. Some have said that keeping OP_RETURN size small is important for node operator liability, because large OP_RETURN size could lead to relaying/storing full files of any kind (including the most awful stuff). 2. Yet, the OP_RETURN size limit is not a consensus rule, i.e. nothing prevents a miner from including a transaction with a huge OP_RETURN in a block, already now. 3. What Core is doing, and Knots is against, is changing the relay policy, that decides which unconfirmed transactions the node shares with other nodes (~broadcasting), before they are included in a block. Right now the default policy is to not relay a transaction with an OP_RETURN exceeding 80 bytes. 4. I tend to agree that largeish arbitrary files pose a risk to Bitcoin. I understand that it's already possible to store it in small chunks over multiple transactions or otherwise, but that would require special software to interpret. 5. Therefore, I believe the fundamental problem is not really being addressed. The fundamental problem is that there is not a true OP_RETURN size limit to begin with. 6. If we accept the premise that large OP_RETURN size is a risk to Bitcoin, we should make the OP_RETURN size limit a *consensus rule* going forward. That is, a transaction with a large OP_RETURN would be invalid, and no miner could include it in a new block (unlike now). 7. I believe this is called a SOFT FORK. Not a comfortable word, but I think that would be the consistent position here. Change my mind #asknostr @04c915da…3dfbecc9 @83e818df…5ccd964b @1afe0c74…6808e36d @50d94fc2…df281d63 @fdd5e8f6…a73464a7 @ccaa58e3…755d48cc @020f2d21…81a81c3e