BrightSats

Come on man. There was a POLICY limit that was, nevertheless, followed strictly for years. There's a difference between changing a default in the reference implementation and a few individuals changing the setting themselves. It's a signal. You know the survivorship bias meme? The one with the plane? There's a similar phenomenon in cybersecurity and networking in general. The defaults of the network shape the messages that flow through it. But the thing is, you don't see the attacks or the network traffic that didn't get sent because the default was in place. It's the same concept as a fence around a facility. Sure, you can hop the fence. Or go to a section that isn't fenced, if you want force the analogy a little further. But it's effort. Effort and friction reduce security incidents. My position is that Core only thought about one perspective with the OP_RETURN limit and didn't recognize that the limit had other functions. Similarly, they didn't recognize that relay policy isn't actually a setting you can just engineer into perfection since we're dealing with humans. You can disagree with 110 supporters over the governance side all you want. You don't need to twist narratives to make your point.

BIP110 supporters are saying that Core blew open OP_RETURN. They didn't. They just removed a sign. Bitcoin's real OP_RETURN limit isn't 83 bytes or even 100KB. Those are policy. You can think of them as speed-limit signs each node chooses to post. The real limit is ~1MB. That's the law of nature, or consensus rules. Think of it as the speed of light, 299,792,458 m/s. A fixed constant. No dev, no miner, no config flag moves it. OP_RETURN data is non-witness data, 4 weight units per byte. Fill a whole block with it: 4,000,000 ÷ 4 = ~1,000,000 bytes. That's the real limit. It was the limit before v30 too. This means the 83-byte cap was never Bitcoin's limit. It was a sign posted in front of a road that was always ~1MB wide. And miners were already driving past it, accepting big non-standard transactions directly, bypassing the mempool entirely. All v30 did was take the sign down. Default datacarrier size went from 83 to 100,000 bytes. Should they have taken the sign down? That's debatable, but it also isn't relevant (outside of angering some people). However, there were zero consensus changes. Not a soft-fork. Not a hard-fork. The set of valid blocks is identical before and after. So when someone says "Core changed Bitcoin," ask them: which consensus rule changed?

Samson, last fall you told two podcasts (clips attached) that Core had - "a lot of structural problems with the organization itself" - developers with "ulterior motives" doing "conflicted" things - a "laundry list": "backstabbing, internal politics, brigading, canceling people." You also said: "you'll get it eventually. I think it'll come to light." You knew about the issues, but waited for someone else to do the work. I did the work documenting this. Three articles (so far). IRS filings, SEC exhibits, PRs, IRC logs, archives, right of reply. The very structural and governance-related problems, documented line by line. My articles assert none of the motives you asserted. You went further on those podcasts than my articles ever go. And now that this all has come to light, meticulously sourced and documented, your response is: "some individuals doing questionable things," a little "cliques and groupthink", and a retweet of Adam calling the process "uniquely robust to special interest lobbies." This is the exact opposite of your own diagnosis on those podcasts. It's very strange to describe and predict that serious and very problematic dirty laundry will air, then call it a non-issue and join Adam's handwaving and misdirection when someone airs it.

Well hello there, it’s been a hot minute! 🧡 In case you didn’t know, my book download is available for free in five languages! English, Spanish, BR Portuguese, Kiswahili and Italian. Link below (since I think the algo still doesn’t like those 🙃)