ExploreTrendingAnalytics
Nostr Archives
ExploreTrendingAnalytics
HHide&Seek22d ago
I am opposed to core v30 for the exact same reasons I am opposed to BIP110: sloppy engineering forced through the community with poor arguments. Btw, core v30 didn't enable posting contiguous harmful content on chain: it was enabled in 2013 by OP_RETURN, that was limitless at the consensus level from the start. And to be clear, the threat was well known all along. There are press articles from 2018/2019 that were FUDing about it during that bear. Anyone who's familiar with bitcoin, like Luke also is, has knew about this for years if not a decade — so why is it suddenly an emergency after all that time? Core 30 sucks and it shouldn't have happen - but it is simply not true that it made that attack viable, and anyone who thinks so is deeply miseducated about how bitcoin works. All of this is just ego war and people wanting to feel great about themselves. If the priority was to protect bitcoin against this attack, then capping OP_RETURN size would have been enough, and much much more likely to pass. But ofc they had to overdo and turn this into a personal vendetta, and now the chances of fixing the actual important thing by the end or the year are 0.
💬 1 replies

Thread context

Root: a0d09a42ddf0…

Replying to: c2ff40aba83a…

Replies (1)

Tauri22d ago
Good, so we can establish a baseline around v30. I’m aware contiguous data isn’t new. The difference is that it wasn’t a systemic problem until the 2023 inscriptions exploit. Before that, large-scale data stuffing required convoluted workarounds and remained marginal. There wasn’t a real economic split between monetary and non-monetary use at scale. What changed wasn’t the code alone, but the incentives. Once a market formed around inscriptions and it became culturally normalized, the behavior scaled aggressively. The data reflects that shift. At that point, it stopped being edge-case experimentation and became an industrial use of blockspace for non-monetary payloads. Uncapping OP_RETURN without first addressing the underlying inscriptions vector only amplified the issue. It expanded one data pathway while leaving the more structurally problematic one untouched. Are you familiar with the mechanics of the inscriptions exploit? Or how it was handled in 2023? Understanding that context clarifies much of what followed with Core v30 and why BIP100 focuses not only on OP_RETURN but also on alternative data embedding methods. What looks like an overkill is actually trying to patch a leaking bucket with many holes. https://blockspaceweekly.substack.com/p/issue-3-three-yea…
000
0 sats