This is a nontrivial problem to solve. There appears to be no elegant proposals, only "all or nothing" discussions in lieu of the apparent hack that exists today.
The argument for "ACK" seems to center around disincentivizing using the p2p network and mempool to convey proposed transactions into the block template.
The argument for NACK is that we want to preserve the blockchain for financial transactions, and that the current mempool rule works well enough today. That argument would lead me to conclude a hard fork is more desirable to diaallow any post-OP_RETURN data in the blockchain at all.
There is a separate argument from the Knots camp saying the mempool should have MORE filters on by default. The argument against this is "big money" can easily bypass this by purchasing template space directly from the pools.
What is the underlying concern? It boils down to fights over limited resources.
Maybe OP_RETURN data could require an exponentially increasing cost-per-vbyte similarly to how TCP retries use an exponential backoff in congested channels? This, combined with tightning up transaction-input rules to reduce non-financial abuse?
Brunswick
npub1c8…q6lkc
2025-05-02 00:55:57
in reply to nevent1q…g8tg
Author Public Key
npub1c856kwjk524kef97hazw5e9jlkjq4333r6yxh2rtgefpd894ddpsmq6lkcPublished at
2025-05-02 00:55:57Event JSON
{
"id": "902f0ddb575e91831b6636e61e49284f77a0ed4af4b4ca9cabe4b23847bda3b8",
"pubkey": "c1e9ab3a56a2ab6ca4bebf44ea64b2fda40ac6311e886ba86b4652169cb56b43",
"created_at": 1746147357,
"kind": 1,
"tags": [
[
"e",
"8495fbc236bf28331e3af8f5ad134a46bf818a81a13a05fe363b9a9b4864f999",
"",
"root"
],
[
"p",
"82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2"
]
],
"content": "This is a nontrivial problem to solve. There appears to be no elegant proposals, only \"all or nothing\" discussions in lieu of the apparent hack that exists today.\n\nThe argument for \"ACK\" seems to center around disincentivizing using the p2p network and mempool to convey proposed transactions into the block template.\n\nThe argument for NACK is that we want to preserve the blockchain for financial transactions, and that the current mempool rule works well enough today. That argument would lead me to conclude a hard fork is more desirable to diaallow any post-OP_RETURN data in the blockchain at all.\n\nThere is a separate argument from the Knots camp saying the mempool should have MORE filters on by default. The argument against this is \"big money\" can easily bypass this by purchasing template space directly from the pools. \n\nWhat is the underlying concern? It boils down to fights over limited resources.\n\nMaybe OP_RETURN data could require an exponentially increasing cost-per-vbyte similarly to how TCP retries use an exponential backoff in congested channels? This, combined with tightning up transaction-input rules to reduce non-financial abuse?",
"sig": "8f8a94b2cfc8381a84cfdffa4f54982e194a7ca14d9b11bcff3123de846b25b1d0d0f5eecececbace27b8bbf58095e9a8092fb82a77b0efafa46f4ef8355aadb"
}