It is fundamentally improve to prevent those who want to store data on chain from doing so. There’s nothing to investigate there, there’s only worse ways of doing it and better ways of doing it.
> On top of this, I do not think it is unreasonable to point out that there are people involved in making this decision who will benefit from being able to store large amounts of data in op_return.
I don’t believe this is true. The Citrea instance isn’t material to them. They’re gonna do it either way, either in a really shitty way that bloats the UTXO set or in a better way. The only impact is on Bitcoin, not them.
> rushing this will increase the chance of forks
Huh? This is mempool policy, not consensus logic. People can run other code if they want to but there’s no chance of a fork for mempool policy.
If you mean that people will fork Core, I mean, okay? The issue is ~all the engineers working on Bitcoin Core and mempool policy agree with this change (which should tell you something, they don’t often all agree!), so maintaining a fork without any of the people competent at doing so is not gonna end well.
Or you end up like Knots, a one-man project shipping a ton of barely-tested patches that zero people aside from Luke have reviewed. That’s not a serious project.
matt / Matt Corallo
npub185…swrdp
2025-05-06 11:40:15
in reply to nevent1q…jj35
Author Public Key
npub185h9z5yxn8uc7retm0n6gkm88358lejzparxms5kmy9epr236k2qcswrdpPublished at
2025-05-06 11:40:15Event JSON
{
"id": "f55cdd0fece3595d654a0ecf80bf160d385fa4280f8aabf845488668e1621511",
"pubkey": "3d2e51508699f98f0f2bdbe7a45b673c687fe6420f466dc296d90b908d51d594",
"created_at": 1746531615,
"kind": 1,
"tags": [
[
"e",
"5f4bbdb72ac1fdf9731b58dfce37572bde10e14290ec1e8e46cc5a07099a9dec",
"",
"root"
],
[
"e",
"a73732af53a0a9772df153dd1cb9e25e5981832bf09ca39dbb104e5510178e77",
"",
"reply"
],
[
"p",
"dba46e07d8952745758252ec884328873bf388cfd45822ff2c6a6397c3a50519"
],
[
"p",
"05972259ec683e9843ce12fae6cedda06e65062cfb014799e2abd52b2932bae6"
]
],
"content": "It is fundamentally improve to prevent those who want to store data on chain from doing so. There’s nothing to investigate there, there’s only worse ways of doing it and better ways of doing it.\n\n\u003e On top of this, I do not think it is unreasonable to point out that there are people involved in making this decision who will benefit from being able to store large amounts of data in op_return.\n\nI don’t believe this is true. The Citrea instance isn’t material to them. They’re gonna do it either way, either in a really shitty way that bloats the UTXO set or in a better way. The only impact is on Bitcoin, not them.\n\n\u003e rushing this will increase the chance of forks\n\nHuh? This is mempool policy, not consensus logic. People can run other code if they want to but there’s no chance of a fork for mempool policy.\n\nIf you mean that people will fork Core, I mean, okay? The issue is ~all the engineers working on Bitcoin Core and mempool policy agree with this change (which should tell you something, they don’t often all agree!), so maintaining a fork without any of the people competent at doing so is not gonna end well.\n\nOr you end up like Knots, a one-man project shipping a ton of barely-tested patches that zero people aside from Luke have reviewed. That’s not a serious project.",
"sig": "f5dad7c09f6ece13a290954221de8a8ccb4d53db08eed9ab7086ee1885e788ecaae8a788b656871f03c7c5072add3316473ed936ac3093d23e314af18fa2df33"
}