pull down to refresh

From the Bitcoin Core v0.10.0 release notes, February 8th 2015:
Luke Dashjr has been saying that -datacarriersize was meant to apply to all forms of arbitrary data in transactions, and that failing to do so was a bug.
Luke is wrong.
As you can see, when the -datacarrier options were added to Bitcoin Core v0.10.0, about 11 years ago, we knew it only applied to transactions containing an OP_Return output, and the size limit was about that OP_Return output. Nothing else.
Think about it: the whole point of OP_Return was to encourage people already making UTXO-using data-carrying transactions to do so in a different, less harmful way. We couldn't stop that and we knew it. There's no way we intended this to be a filter for all data.
Furthermore, in the exact same release, we also allowed arbitrary scripts to be used with P2SH:
We knew people could and would use this to put data in transactions. And we made no effort to stop that, because trying to do so is an endless cat and mouse game. Indeed, I personally created a demo program that published arbitrary text to the chain right after v0.10.0 was released:
Finally, notice how this was years prior to Taproot. The idea that Taproot "enabled spam" is just nonsense. "Spam" has been with us since the beginning of Bitcoin.
281 sats \ 1 reply \ @Scoresby 27 Aug
Thanks for posting this. I appreciate the clarity. I previously had not heard the argument that Taproot enabled spam in this context. I always thought people made such an argument because Taproot removed the script size limit, which meant that the ordinal people could include their ordinal data in the script.
Personally, I don't believe there is such as thing as a spam transaction that gets included in the Bitcoin blockchain.
reply
Taproot didn't change anything meaningful from the point of view of someone who wants to publish data. The limits on P2SH are already plenty big. You just need to add more inputs if you exceed those per-txin limits, which doesn't significantly increase the cost.
reply
50 sats \ 0 replies \ @siggy47 22h
While you're talking about this, did you see Giacomo's comments on X today? Can you address them? Here's an earlier post:
reply
Story checks out, I don’t believe Luke has ever been right in his life!
reply
Thank you for your time and effort, Peter.
reply
617 sats \ 2 replies \ @anon 27 Aug
Love me some first class bullshit
reply
240 sats \ 1 reply \ @optimism 23h
Which part is BS?
reply
1101 sats \ 0 replies \ @anon 22h
Which part wasn’t?
reply
0 sats \ 0 replies \ @anon 9h
reply
99 sats \ 0 replies \ @anon 9h
No, you're wrong. 10 year old semantics is not where the discussion lies. Quote from parman on Nostr: "I think we shouldn't get sucked into the distracting technical debate about OP_RETURN -- there is a principle that's at stake:
Do not make meaningful changes that nearly all users are against, for debatable marginal benefit, EVEN IF it's "better" technically.
That's not your place, nor your role, open source developer..."
GFY
reply
Cry harder scammer, @petertodd. We resist your psyop. More information at https://wtfhappenedinfeb2023.com/
TL;DR datacarriersize has always been about any non-Bitcoin data as the name suggest. OP_RETURN is the security hole introduced (and exploited) by spamming attackers long after Bitcoin inception and CIA "invited" the maintainer Gavin Andersen. TapRoot is the much younger change than OP_RETURN and Bitcoin Core maintainers failed/refused to extend datacarriersize limit to TapRoot. Fortunately, the patch (bugfix) has been implemented in Bitcoin Knots.
reply
But why the fuck would you run knots?
reply
I run Bitcoin Knots: "https://bitcoinknots.org/".
reply
Of course you are free to run it, Infact any software you like.
But knots is not Bitcoin. It’s a Bitcoin LARP client developed by a fool.
reply
It's always good to maintain transparency like this and bring the point of view of those who are leading the project.
reply
Come on, now. What else should the podcasters LARP about?
reply
semantics
reply