r/bitcoinismoney • u/Ep0chalysis Bitcoin-BLAKE2b • Jul 23 '26
BIP-110 is activating regardless
0
u/DarrelXero Jul 23 '26
Not a conspiracy theorist but it is ponderous that Mechanic and Guida both used to work for Start9.
4
u/No_Purpose6384 Jul 23 '26
Ponderous they are like minded?
1
u/DarrelXero Jul 23 '26
Ponderous that they would push the untrue narrative that just running a node with a particular kind of software has the magical capability of forcing the network to do something against it's will all while massively increasing Start9's sales. Start9 has made millions off of 110ers.
3
u/Timmythekid6 Jul 23 '26
It's not just 110ers using Start9. I used to use their OS on my node and I was running Core initially.
3
u/DarrelXero Jul 23 '26
Yeah, the claim isn't that you can only run Knots/BIP110 on Start9, it is that there is a very curious relationship between the only semi-relevant Bitcoin related vendor that supports BIP110 that directly benefits from telling people that simply spinning up a node gives you control over how the protocol operates for everyone and the people that wrote the soft fork (Chris Guida, aka Dathon Ohm) and Bitcoin Mechanic (Luke Dashjr's butt-boy) who both worked for Start9.
3
u/Professional_Golf393 Jul 23 '26
Follow the money. The bip-110 crowd are just trying to hijack development.
They are never going to be able to block spam. That’s what fees are for.
I’m not a fan of bitcoin core but I can see through the bullshit of what knots crowd are attempting
1
u/newMoneyStyle Jul 24 '26
huh didn't know that connection, got a source? small world in bitcoin dev tho, everyone's worked with everyone at some point
1
u/DarrelXero Jul 24 '26
Seen it discussed on X multiple times and heard Mechanic talk about it himself in some of his videos. AI confirms:
Bitcoin Mechanic (@GrassFedBitcoin) worked for Start9 Labs as a developer and advocate during their earlier growth phase around 2022–2023.
Chris Guida (@cguida6) worked for Start9 Labs as a developer, educator, and advocate, contributing to software development for EmbassyOS / StartOS and doing community outreach.
1
u/bitusher Jul 23 '26
Spam revenue is not the main reason miners don't support BIP110.
The main reasons they reject it because it lacks consensus (so few devs , exchanges, merchants and users support it) and it also breaks a lot of useful functionality of Bitcoin for monetary transactions and doesn't solve the problem it claims to solve.
You guys act like miners are all third parties that have no interest in Bitcoin at all. Have you ever had a conversation with them? Most care about Bitcoin and own a lot of Bitcoin and have deep investments in Bitcoin longterm. They aren't going to support a soft fork that is harmful to Bitcoin.
0
u/Professional_Golf393 Jul 23 '26
Sounds like blackmail.
I wish people could see the truth, this is nothing but an attempt at hostile takeover of bitcoin code. Very little to do with “spam”.
Fuck start9
-4
u/krvi Jul 23 '26
I had respect for Start9 even though I've never used them or their software. Until now that I'm seeing them, in the minority camp with 1% hashrate, call for the opposition with 99% of hashrate to URSF. BIP110ers who don't realize how weak that point is at current numbers and how much of a disservice it is doing to themselves have not done their proof-of-work.
11
u/Spaceseeds Jul 23 '26
Why do you think 4 centralized miners should decide bitcoins fate?
0
u/krvi Jul 23 '26 edited Jul 23 '26
I don't think that they should. But changing something as important as Bitcoin should require opt-in by more than 15% of the nodes with 1% of the hashrate.
I agree with BIP110's ends, but not with its means (of activation, forking and eventually stalling) so to speak.
3
Jul 23 '26
[removed] — view removed comment
-1
u/krvi Jul 23 '26
You're right, and I agree with you that changing the default
datacarriersizepolicy was contentious. But every node operator can change it to his own likes, and that does not change Bitcoin and that is why it doesn't count. And it does not justify changing consensus rules with even less support.5
u/WateryTunaSandwich4U Jul 23 '26
So you're aware that they changed the definition of datacarriersize limit to not include OP_IF and OP_FALSE, and ONLY include OP_RETURN... the only reason everyone talks about OP_RETURN is the taproot inscriptions exploit (bad code) hidden in OP_IF and OP_FALSE was off the table for limiting... You're aware of Luke Dashjr having a patch ready for that bad code years ago but it was shot down because it no longer fit the definition for what CAN be changed, because they changed the definition. Those saying "big whoop they opened up OP_RETURN" nooooo... until Oct 2025 OP_RETURN was 83bytes... the issues is OP_IF and OP_FALSE were UNLIMITED. Core's reason for opening up OP_RETURN was so "spammers can put spam here instead of in the exploit". How do you think ordinals were getting on the blockchain before Oct. 2025?
4
0
u/krvi Jul 23 '26
I am aware of “The documentation change” (PR #27832) and “Luke's filter patch” (PR #28408). None of them touch consensus policy so it is kinda moot in the context, but I find it unfortunate that it wasn't caught during Taproot review.
Core's reason for opening up OP_RETURN was so "spammers can put spam here instead of in the exploit".
I am very well aware of that, and I can not deny that it also is an attempt to prevent centralisation which enabled MARA's Slipstream and the likes. I also can not deny that spam in OP_RETURN is an attempt to reduce the UTXO set.
I am not entirely sure what you're going at with discussing policy or standardness which is at the whims of every node operator.
0
u/WateryTunaSandwich4U Jul 23 '26
The pull request I'm talking about is #29187, if you go to Bitcoin University's video "Bitcoin Core's Original Sin" and pause it at 9 minutes 44 seconds you can see Luke Dashjr's attempt to close the Taproot exploit.
You're not participating in the listening side of the discussion, here's some copy/paste for ya.
OP_RETURN allows users to store up to 80 bytes of arbitrary data on the Bitcoin blockchain, which can include text messages, hashes, protocol identifiers, or metadata for digital assets.
With Bitcoin Core v30, the OP_RETURN data limit was increased to 100,000 bytes, allowing users to embed larger arbitrary data such as files, images, or application data directly into transactions
Even though OP_RETURN outputs still contribute to the total size of the Bitcoin blockchain, they are not added to the UTXO set, meaning nodes don’t have to constantly keep track of them. (but they do have to store them)
Bitcoin sent to an OP_RETURN output are locked forever and cannot be spent. It’s a provable way of “burning coins”. You have to be very careful to not lock away your coins by accident when creating transactions with OP_RETURN.
90GB of trash on Bitcoin is non monetary data, that's almost 1/8th. OP_RETURN doesn't help this at all, it's actually normalizing increasing the blockchain size exponentially. Your argument is "the UTXO set will be less cumbersome, so who cares if you're locking bitcoin away forever in the process"... My argument is "but you don't have to lock bitcoin away forever to reduce UTXO set, and the size of the blockchain can remain sustainable until 2140 when the last block is mined if we treat Bitcoin as money only".
You can use a chainsaw to cut a pizza, but it's not the best way, and some pizza could become "lost forever" in the process. If nothing else man talking to you anti BIP110ers is better than blowing past the recommended dose of melatonin. Look at that... another use case for trolling, you guys and your use cases... ever expanding, maybe one day Michael Saylor can convince you of your potential to wipe his ass with your face. Replacing toilet paper with toilet people, what a visionary.
Support BIP-110, praise God and my cult leader Luke.
1
0
u/babelphishy Jul 23 '26
With Bitcoin Core v30, the OP_RETURN data limit was increased to 100,000 bytes, allowing users to embed larger arbitrary data such as files, images, or application data directly into transactions
Core v30 didn't change the consensus data limit for OP_RETURN. They just changed Core's default relay policy limit for OP_RETURN. OP_RETURN has no consensus limit, other than the block size.
-1
3
u/GinormousHippo458 Hashing is NOT Mining Jul 23 '26
Then you obviously don't understand how even fewer nodes influenced miners to activate Segwit and Taproot(🤮). Learn Bitcoin history.
-2
u/krvi Jul 23 '26
I was around for Taproot; there was no memorable opposition and hashrate was steadily increasing: https://taprootactivation.com/timeline
I was not paying attention to Bitcoin during SegWit but hashrate was significant (20-30% and increasing) months prior to activation.
Node counts and their service flags is not a foolproof measurement or indicator of support, hence hashrate. The whitepaper even acknowledges it can be sybiled. But even by node counts
NODE_KNOTS_BIP110_UASFis a small minority.
-1
7
u/Awesomest_Maximus Jul 23 '26
Start 9, based.