Oddbean

1. Core's plan was always to roll out 80 byte OP_RETURN incrementally by starting with 40 to see if it broke anything and then ramping shortly up to the intended 80. 2. #Bitcoin Core, having finished that project, has had 80 byte OP_RETURN for nearly a decade now. 85%+ miners have been set to 80 bytes for the same amount of time. Read the commit log. Read the bitcoin-dev mailing list. 3. You admitted on Shitter/X that you went along with the Core team because you had your own fork where you can make any changes you'd like. 4. Now that Jack has invested in you to decentralize mining, you've cast a shadow over the launch by revolting against the implicit op_return contract in #Bitcoin Core which has been standardized by the network over the last decade. 5. Whirlpool transactions are trivial to detect and you could whitelist them no problem. This is about you kneecapping #Bitcoin fungibility while gaslighting the space about decentralization. 6. What's more centralized? The development process in bitcoin:master with a decade+ track record, ~1000 developers, and 20,000+ code reviews, or Knots, where one dude makes god commits daily, breaking critical aspects of #Bitcoin? 7. Until Ocean.xyz launches #StratumV2, you're just another gatekeeper. Ordinals ia going to run out of customers like every other shitcoin. We don't need to compromise Core just because you didn't get your way 10 years ago. 8. GFY.

I agree with Laser. Censoring whirlpool transactions is pants over head retarded. I hate ordinals but let the shitcoin casino players run out of payday loan money. Luke I bet knows all this and is prob so into himself he is high on his own farts. nostr:note19jaycas8dn972e0ujqgq2mpyp6u96awpyum33rrpza3lqmn3ufnqxkft7t

Field length in network protocols matters; you can extend a field, but reducing it at a later stage after network participants (like whirlpool) have begun to rely on the field length is considered a backwards breaking change.

Luke has answered this elsewhere. It's unfortunate his positions on specific topics aren't indexed somewhere that he can just reference by code. His position is that from inception the field was standardized at 40 bytes, intentionally to limit spam. So reliance on and design around an expanded field size is a mistake on their end, for non-conforming to the "spec". Things like this in protocols tend to be worked out by representative bodies and industry boards such as w3c, iso, among others over time. These standards also tend to compete for adoption. Bitcoin being money, a new project and a philosophical or religious paradigm shift for participants, with enourmous social consequences, it will take a while to smooth out the standard.

That's a falsehood Seagull, and you can find it out yourself by looking at the bitcoin-dev mailing list and the bitcoin git repo. 80 bytes was the intended OP_RETURN this whole time, it's just that Core decided to incrementally roll it our for safety reasons. After 9 months at 40 bytes, with nothing breaking, they concluded at 80 bytes, which it's been that way for a decade now. Luke is lying.

Just to be clear I am not a fan of ordinals. Let the free market decide as described by Austrian economics. Layer twos are (presently) the only way to onboard 8 billion people to use Bitcoin. We might as well figure out the best way to build layer twos on Bitcoin.

By the way, apparently the 42 limit standard is his version, not cores. The standard he's talking about is his series of patches he has been advocating for merging to core for several years. Not so much lying, as being zealous. This distinction might be damage control though.

There isn't a Luke standard and a Laser standard and then finally a #Bitcoin standard. There is only 1 #Bitcoin network and the standard is based on the implicit/explicit contracts of that network, not Luke's fork. "Luke often is correct, but sometimes only with a non-standard definition." -Adam Back https://nitter.net/adam3us/status/1733098596122198306 "80 bytes is standard policy on the network" -Adam Back https://nitter.net/adam3us/status/1733409334577541162?s=20 "Samourai has no obligation of any kind to 'fix', they're using network standard..." -Adam Back https://nitter.net/adam3us/status/1733409758508367972

You have the right to join a pool or run a node that does what you want it to. He claims in the current core implementation, limiting the byte size can be bypassed, and is, by ordinals. Knots has a fix for this apparently, that follows the strict byte limit. This limit can be adjusted back to 80 if you want, by the way. Along with several other fixes in Knots, changes and weaknesess he sees in core, he is self advocating for these changes to be merged to core. if there is a lie, the lie is that reducing the byte size in a core implementation can be bypassed somehow. Haven't seen the fix code. But nothing so far counters that specific claim.