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

nostr:npub1qny3tkh0acurzla8x3zy4nhrjz5zd8l9sy9jys09umwng00manysew95gx nostr:npub1s05p3ha7en49dv8429tkk07nnfa9pcwczkf5x5qrdraqshxdje9sq6eyhe nostr:npub1rtlqca8r6auyaw5n5h3l5422dm4sry5dzfee4696fqe8s6qgudks7djtfs nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk nostr:npub1ej493cmun8y9h3082spg5uvt63jgtewneve526g7e2urca2afrxqm3ndrm nostr:npub1qg8j6gdwpxlntlxlkew7eu283wzx7hmj32esch42hntdpqdgrslqv024kw