pull down to refresh
21 sats \ 4 replies \ @unschooled 1 May \ parent \ on: Can Someone Please Tell Me What is Going On With Bitcoin Core AskSN
Afact the core-side of things hasn't been very well explained, which may be why Kratter is presenting this bias and may account for (not necessarily excuse) the nature of the pushback.
What you wrote in another comment,
is the first teleological (cf #968027) explanation for dropping the op_return standardness limitations I've seen so far, whereas most of Core's attempts to explain/justify themselves merely state the obvious fact that spam finds it's way into the mempools in spite of op_return having the limits in place.
One concern I have, in response to your summary of the core-side, is whether they are serious about making it easier for people run nodes. Since Todd's recent boldness, this has not been particularly obvious in the narrative Core is pushing. They want to change a part of the implementation that has been there for longer than a decade, so IMHO there's at least some level of resistance that is warranted.
If you have more evidence that this may be the case, then I'd be curious to see what that is.
In my opinion they would be best off doing... nothing. When it is not clear what to do, in Bitcoin the best thing is to do nothing. Don't change anything.
Having said that I read all the comments of that PR and that's where I saw this
is the first teleological (cf #968027) explanation for dropping the op_return standardness limitations I've seen so far
The explanation was that op_return is much better than fake keys, bare multisig, or unspendable UTXOs but I am not an expert read all the explanations for yourself.
As far as making it harder to run nodes... my understanding is that the bloating of the UTXO set with dust is the hardest thing about running nodes today. The storage of the 'data' from inscriptions isn't a big deal the 4mb block limit cannot be exceeded and that data just sits there.
It's the dust transactions and larger utxo set for low-powered nodes. If they were all op_return outputs they could be ignored/pruned/have a lesser impact.
reply
A block can have up to 4 MB of witness data, but only up to 1 MB of other transaction data. OP_RETURN outputs are other data. If you store stuff in OP_RETURNs instead of witness data, the resulting block will be smaller. And yeah, it’s harm reduction as @028559d218 said. That’s also what I was trying to convey, but their post here is much pithier.
reply
I can see that @petertodd is suggesting that utxo bloat is a direct consequence of the OP_RETURN standardness limit, which appears a rational argument at first glance. How would I be able to verify this using my own node?
reply
You can't. The UTXO set itself, what your node stores, doesn't tell you anything useful about why a transaction was created.
You have to think about this for yourself, e.g. by looking at projects using Bitcoin and understanding what they're doing and why.
reply