Here (
X,
N), Luke expresses his thoughts that miners will obviously want this Softfork, otherwise their business will be destroyed, because this change is an existential emergency for bitcoin. This softfork could have been activated by miners in any signaling period where 55% or more of the blocks made signaled for it, for the last half year. Even if miners had activated it at a 55% threshhold, the fork still would have fallen far short of the last 2 soft forks where the threshold was 90%+ (that's actual miner consensus for adopting a change to bitcoin). So in the best case, this fork would be contentious, if it had any support. After more than a half year of the
BIP110 optional signaling period began, the pro-BIP110 hashrate never broke 1%. They put the bar way low, and miner support was abysmal. But it has node support, you say. We're now in the UASF phase. But here are
Luke's own node stats, which shows Knots not more than 25% of the node network. That
is significant (although not all Knots nodes enforce bip110), but consider what it takes for a UASF to actually succeed:
1) majority of "economic" nodes accepting the new softfork's coins as the real bitcoin in exchange for goods and services
2) hashrate willing to produce blocks compliant with the UASF
Why do you need miner support? The Bitcoin blockchain, by definition, and as implemented in Bitcoin Core and all other implementations including Knots, is the longest, most worked chain, according to its embedded proof of work.
This post (
X,
N) shows that Bitcoin Mechanic acknowledges that BIP110 has neither widespread economic node support nor miner support.
But, according to luke, it's not possible for BIP110 to cause a chain split:
> BIP110 cannot cause a chain split.
- Luke-Jr (Source: (
X,
N)
But if there is a chain-split, Core did it, and that's an unlikely a worst-case scenario:
> In the very worst-case scenario, there'd be two chains/coins for some period of time until CSAM is uploaded to the vulnerable chain and it dies, leaving only the immune chain surviving.
But even the BIP110 chain is not immune from CSAM; in fact, there is most likely CSAM already in the chain, in the form of ordinals. That's right -- even after this dumb fork, to the extent that the BIP110 chain survives, there will still be CSAM in the BIP110 chain. This is sad but probably true. That ship has sailed, but there's no way to stop it in any event -- there are a million and one embedding schemes for people to embed arbitrary data -- even BIP110 compliant, see
KnotsLies.com. It is now time to lean on Bitcoin's censorship resistance and decentralization -- two of it's core strengths.
Miners supporting a soft fork is important because the Bitcoin protocol is programmed to follow the longest, most worked chain.
Luke knows this fork has no miner support, but that doesn't bother him -- he always intended to fork whether bip110 had miner support or not (
X,
N).
Miners follow incentives. Lowering capex requirements by boosting income is a no-brainer to boost profitability.
Blocking large amounts of data everywhere that bip110 does blocks most possible future
monetary use cases of Bitcoin: Things like BitVM, Witness Encryption like
PIPESv2,
Shielded CSV, large Post-Quantum signatures, and other potentially game-changing proposals.
On top of that, miners are against BIP110 for an even more basic fact: they are incentivized by fees to mine larger transactions. Somebody figured out a way to abuse bitcoin as a data store for their ill-conceived NFT protocol. Miners literally made hundreds of millions of extra dollars worth of BTC doing that since the beginning of the inscriptions craze. But isn't the ordinals hype over? No,
12.5% to 30% of transactions are inscriptions daily, still.
Because it has nearly no mining support, the BIP110 chain might even change its proof of work algorithm away from SHA-256d to something less attackable. Smart, because until that happens, the BIP110 chain is going to be trivially vulnerable to a 51% attack. If the miners refuse to activate BIP110, he'll just hard-fork (Source:
X,
N,
X,
N). At least his hard-fork token will be easy to name: Bdash.
As is typical, Luke is simply **delusional** and continuously gaslights everyone around him, first hinting that they could change the proof of work and later denying that it will be necessary.
How far will you follow Luke-Jr over the edge?
Luke and Mechanic actually already tried to UASF bitcoin before; this isn't their first rodeo.
Why would any miner trust Luke Jr? He thinks it's best to centralize Bitcoin by subjugating miners' decision making abilities to developers when it comes to protocol upgrades. This is why they
released their own taproot activation client with LOT=true to activate Taproot via UASF. Yes, that's right -- Bitcoin Mechanic and LukeDashJr wanted to FORCE taproot on miners. Miners were in favor of taproot, so Luke and Mechanic's previous contentious UASF proposal never made it to activation either, but they were going to try, had the miners not capitulated on Taproot activation during Speedy Trial. That's right, the people now saying Taproot was a mistake were going to force it on miners if they had rejected it! That's how short-sighted they are. Should we really be handing over the reference implementation to such people?
If bip110 is successful, it's not just that devs will control bitcoin, but Luke Jr, specifically, would control merges to the bitcoin reference client. The developer whose security practices were so hair-brained that he got his bitcoin life savings jacked. That's a very sad story, and I'm not making fun of it but he's so delusional he blames it on "Core" as if he wasn't one of them. He'd probably distribute the Bitcoin client from his
server that he knows for a fact was hacked, and that still carries a warning that states he's not actually sure if the server is free of malware and backdoors. You can forgive the community if they don't want to hand control of the bitcoin codebase to such a person. It would be a serious threat to bitcoin's decentralization and security, if his UASF had any chance of succeeding.