pull down to refresh

BIP-110 is not good.

Assertion.

Filtering data on the consensus level is a terrible idea, that will backfire immensely

Claim...


explanation? proof? demonstration?

transactions from obvious criminal activity

You're saying that BIP-110 is bad because the community which gets together around preventing a specific spam exploit is likely to get together around ... some list of specific form of "criminal activity".

that is, at least, easy enough to understand. I just don't think that it holds water.

right now, there are businesses who make their revenue exploiting unintended side effects of changes from long past, and (previous to v30) sidestepping the application filters to get that exploit into the permanent ledger.

BIP-110 sounds good on paper — a temporary soft fork to reclaim block space from Ordinals and inscriptions — but it fundamentally misunderstands the problem it's trying to solve. The proposal introduces seven consensus-level restrictions targeting data embedding vectors, yet Peter Todd demonstrated its fatal flaw by encoding the entire text of BIP-110 itself into a single compliant transaction. If the rules can't even stop someone from embedding the proposal's own text, they won't stop determined data embedders — they'll just make the process slightly more expensive and fragmented. That's not a solution; it's an inconvenience.

The deeper issue is what BIP-110 represents for Bitcoin's future. Bitcoin's consensus rules have historically been objective and content-neutral — a valid transaction is valid regardless of what its data "means." The moment we start restricting transactions based on subjective judgments about "legitimate" versus "illegitimate" use of block space, we set a precedent that could be turned against any disfavored use case tomorrow. And with only ~2.4% of nodes running the activation client and zero miner signaling, a forced UASF activation risks a chain split that would burn the community's coordination capital — making it harder to rally support for consensus changes we actually need.

If blockchain bloat is the concern, there are better paths forward. BIP-54 (Great Consensus Cleanup) addresses overlapping security concerns like worst-case block validation time through targeted bug fixes without making content-based judgments, and it has far broader developer support. Bitcoin's censorship resistance isn't just a feature — it's the foundation. We should be solving the spam problem with better economics and smarter protocol design, not by giving anyone the power to decide which transactions deserve to exist.

How about that?

reply
0 sats \ 0 replies \ @Murch 23h

I don’t see what BIP 54: Consensus Cleanup has to do with blockchain bloat at all, but otherwise agree with the gist of your comment.

reply
0 sats \ 0 replies \ @itsrealfake OP 19h -10 sats
The proposal introduces seven consensus-level restrictions targeting data embedding vectors, yet Peter Todd demonstrated its fatal flaw by encoding the entire text of BIP-110 itself into a single compliant transaction.

embedding text is not a problem. embedding reams of paper, representing continuous data, that gets easily reassembled into images is SPAM.

The deeper issue is what BIP-110 represents for Bitcoin's future.

yeah, if Bitcoin's future is the antagonistic hyper-independent, I'm here for that. it's bitcoin's past, too.

The moment we start restricting transactions based on subjective judgments

every single mechanism for identifying changes in the protocol (as specified by the BIP) are objective

"legitimate" versus "illegitimate" use of block space

nope... it's financial data vs. non-financial data. this is a P2P cash network. there's no reason to continue accidentally enabled support for cat.gif.

we set a precedent that could be turned against any disfavored use case tomorrow.

what exact precedent are you describing? the precedent for not accepting network abuse by a minority of "art dealers" to take massive advantage of the stupid?

a forced UASF activation risks a chain split that would burn the community's coordination capital

if you run a node, then you know how to coordinate to address this

We should be solving the spam problem with better economics and smarter protocol design, not by giving anyone the power to decide which transactions deserve to exist.

a) better economics for who? certainly not the NFT hustlers who are enabled by v30. probably not the massive mining pools who are supplementing their shitty power costs by mining these fucked transactions (pre-v30) via out-of-band solutions.

b) Protocol design happens by BIP. This is a smart, limited solution to a fucking awful problem: remove accidental support, for 1 year in, in order to eliminate the profitability of the corporate entities engaged in this practice.