avatar
Coinjoined_Chris
126 Twitter followers
Follow
CTO @seedor_io on a mission to fix the money and help secure your wealth | #bitcoin came for the tech - stayed for the memes | Also building @sats_keeper‼️
Posts
avatar
Coinjoined_Chris
03-17
What you're seeing are two completely different layers being conflated. The BIP110 crowd is pushing for a consensus change, the most sensitive part of the system, based on frustration with certain uses of blockspace. And the irony is: it would barely inconvenience spammers while reducing Bitcoin's expressiveness and breaking legitimate use cases. Core, on the other hand, operates at the policy layer. Relay policy isn't about deciding what Bitcoin is. It's about protecting your node from abuse -primarily DDoS and resource exhaustion- and keeping the network functioning efficiently. There is nothing you can stuff in OP_RETURN that drains resources from your node. When mempool conditions change, policy adapts. That's not whack-a-mole, that's exactly what policy is supposed to do: be flexible at the edges so consensus can remain stable at the core. Because consensus is different. Consensus is the foundation. It should change rarely, cautiously, and only with overwhelming justification. Rushing a consensus change to 'deal with spam' flips that principle on its head. So no. Core isn't reacting impulsively. They're doing the opposite: keeping consensus stable, while allowing policy to handle short-term dynamics. And that distinction is precisely what's being missed
BTC
0.4%
avatar
Coinjoined_Chris
02-25
You'rre right that CVEs aren't normative. They identify a claimed vulnerability. They don't magically settle whether something _actually is one_ That's exactly my point. When the same person who: - reinterprets a long-standing policy, - broadens its scope beyond its original definition, - classifies behavior as a vulnerability, - assigns a CVE, - and ships the mitigation …that does not transform a policy disagreement into an objective security flaw. It just means one implementation chose to treat it as such. And knots fixed it so you may commence and run it. And on datacarriersize apparently changing: the historical distinction absolutely matters. It applies to a specific relay policy OP_RETURN followed by a PUSH. Retroactively expanding the interpretation and then saying "see, it applied more broadly" is circular reasoning. You can't redefine the scope and then claim the redefinition proves the original intent. If one developer widens the meaning of a flag and calls anything outside that widened meaning a vulnerability, that does not make it true. It makes it their implementation choice. In a distributed system every implementation can mitigate however they want. Calling something a vulnerability doesn't elevate a policy preference into a universal security defect. Consensus rules are normative. ✅ Policy rules are local. ✅ CVE labels are descriptive. ✅ Blurring those lines is a problem here.
OP
0.27%
avatar
Coinjoined_Chris
02-13
This attack vector already existed since 2009. The fee economics haven't changed. If someone believes spammers were previously incapable of sending raw transactions, emailing miners, or direct submitting large OP_RETURN payloads directly, they're seriously underestimating how resourceful (and motivated) these degens are. The barrier was never technical sophistication. If there were meaningful demand, a simple GUI for crafting and submitting OP_RETURN transactions would have appeared within hours. The limiting factor isn't capability - it's cost and bitcoin imparts that just fine Jpegs on bitcoin are down because they're a shit store of value - not because of finger wagging or relay policy limitations. If anything, people suffering from spam derangement syndrome probably prolonged their relevance by gifting them free attention long after the market verdict was clear.
VEC
0%
loading indicator
Loading..