Best break down of BIP110

[gmaxwell]

https://jlopp.github.io/knotzi-death-march/

It needs an illustration, something sloptastic like a lot of the 110 promotion.

[ABCbits]

This Topic is making me want to race to include a dickbutt jpeg in the first block post BIP110 fork just for the sake of it.

Don't waste your satoshi. Certain people or group regularly create Rune or Runestone TX like this one https://mempool.space/tx/0e34b9bf7ae43d1c308c6a93e38c0b7efaf850378404b792fd9950f678717049?showDetails=true. IIRC the pushed arbitary data pushed is never above 83 bytes, so it's still considered as valid TX by BIP 110.

Without replay protection, anyone could propagate those TX to BIP 110 chain. With replay protection, such people or group could also re-sign and broadcast their TX on BIP 110 chain.

[PepeLapiu]

Just imagine if core had been caring about the UTXO set in 2023 when Luke proposed his ordinal filter.
Just imagine if core has not suddenly cared about the UTXO set in 2025 when they used it as an excuse to remove a malware filter.
Just imagine if the core top maintainer had not repeatedly insulted the people core builds software for.
Just imagine if core had any humility and decided to revert their core 30 change and finally at least pretend they want to fight malware.

Without replay protection, anyone could propagate those TX to BIP 110 chain. With replay protection, such people or group could also re-sign and broadcast their TX on BIP 110 chain.

So we are back to pretending that the S in RDTS stands for hard fork?
BIP110 will allow up to 83 B op_return. On your imaginary fork and on our imaginary fork.

[ABCbits]

Without replay protection, anyone could propagate those TX to BIP 110 chain. With replay protection, such people or group could also re-sign and broadcast their TX on BIP 110 chain.

So we are back to pretending that the S in RDTS stands for hard fork?

I obviously refer to this part, that may cause existence of 2 different chain.

Mandatory signaling period: Similar to BIP8, this deployment enforces mandatory signaling during the retarget period immediately before mandatory lock-in (blocks 961632 to 963647; lock-in happens no later than block 963648). During this window, blocks that do not signal bit 4 are rejected as invalid. Mandatory signaling ends once the deployment reaches the LOCKED_IN state.

BIP110 will allow up to 83 B op_return.

Yes, as described on the BIP itself.

New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.

And from what i've seen so far, most Runes/Runestone TX push data no more than 83 bytes.

[ertil]

So we are back to pretending that the S in RDTS stands for hard fork?

If you have a soft-fork with less than 50% hashrate support, then it forms a minority soft-fork, if it is enforced. And then, it will be left more and more behind the stronger chain, which is why many previous soft-forks required something like 95% hashrate support, just to be on the safe side.

Or do you think, that Satoshi was wrong, when he wrote chapter 11 of the whitepaper called "Calculations"?

When it comes to the soft-fork vs hard-fork, it can tell you only, if a new version is compatible with the old one, or not. Soft-forks can catch up with the stronger chain, but it gets exponentially harder over time, just like Satoshi described. Hard-forks will never replace the stronger chain, no matter what. This is the difference. But that difference doesn't change anything, what Satoshi described in the whitepaper: if you produce an alternative minority chain, and you have q=0.1, which means 10% of the hashrate, then after z=5 blocks, your chance to replace the stronger chain is equal to P=0.0009137, which means less than 0.1%. Do you believe, that Satoshi calculated it wrong somehow?

On your imaginary fork and on our imaginary fork.

Rejecting non-BIP-110 blocks is written in the code. This is the main reason, why the chain will fork. If not that, then reaching not enough hashrate would cause the BIP to expire, just like it should, and just like it was implemented in previous BIPs. The only reason why previous Knots clients landed on the same chain, is because miners also eventually supported it. But if not that, then for example Core could have no Taproot, and Knots could activate it, through Bitcoin Taproot client, written by Luke. So, if you don't like Taproot, then go ask Luke, why he implemented a mandatory activation in his client for that.

[DaveF]

Makes you wonder if there are going to be 3 chains because of this.
The main chain, followed by almost everyone running just about running BTC.
And
The knots chain, which will split in early August
And
Some sort of 3rd chain from people who coded something that will start rejecting blocks after the September activation of 110.

I don't think there will be anyone on the 3rd chain since it probably will not have split so far from the other 2 that it will have no miners.
But, even now I saw someone saying that they the knots client can become the dominant chain with 15% hashrate because miners will see it's better and switch in a few weeks after the fork.

-Dave

[ertil]

Some sort of 3rd chain from people who coded something that will start rejecting blocks after the September activation of 110.

No, except from Paul Sztorc chain, I think there is nothing planned. But this thing is different, because his idea is just a hard-fork, to bring sidechains to Bitcoin.

And URSF from Super Testnet is not getting that much support, to form a third chain: https://github.com/supertestnet/ursf-110

the knots client can become the dominant chain with 15% hashrate because miners will see it's better and switch in a few weeks after the fork

A few weeks, with 15% hashrate, is not enough to trigger difficulty adjustment even once (2 weeks * 20/3 = over 13 weeks; and then it will be just 25% of the previous value, so the next adjustment will also take more than 2 weeks). Beyond 100 confirmations, miners will start moving their coins, and then, people will end up on different chains, even if there would be no replay protection, just because coinbase transactions will be different, and they will split the coins.

Also, mining pools know, which pool does what, because of spy mining. If you think that Foundry doesn't know, if Antpool supports something or not, then you are wrong. All mining pools will quickly know, that the support for BIP-110 is at best 1% or 2%, so they won't assume, that any other pool is going to activate it: by looking at block headers, sent by another pool, they will know exactly, who is going to signal what.

In the prisoner's dilemma, you don't know, what another prisoner is going to do. Which is not the case with mining. Even if you have just CPUs, and nothing else, then you can always request a block template from any pool, and see, what is there. Some developers did that: https://b10c.me/observations/12-template-similarity/

If developers can request block header from any pool, and see, what is going on, just because they are curious, then you think pool operators don't look at their competitors?

[gmaxwell]

Beyond what's 'written in code' the 110 proponents have been going around trying to push people around saying that they HAVE to adopt their change because otherwise there is a risk of huge reoriginations-- basically due to inept construction their proposal has some risk of harming the network and instead of viewing it as a flaw they ought to fix, they're turning it into a threat.  Knotzis are really going for the hearts and minds, it seems: Essentially telling people that if they don't change bitcoin to satisfy them they'll try to torch it.

But the thing is that even if they do manage to intimidate someone here and there-- adopting the knotzi slopspec isn't their only recourse: if someone does create a 110 signaling block at the mandatory height, people will immediately circulate the console/rpc command to invalidateblock it.  Punch that in and the risk that you'll see a reorg from their attack will drop from tiny to zero.  And punching in an invalidateblock is a lot easier than switching to their mystery meat implementation, doesn't trash bitcoin's functionality, and stands up to their coercion.

[PepeLapiu]

(endless ad hominem slop removed)

Greg Maxwell is supposed to be a technical guy.
When you people say that the anti-malware side is not technical, you point to people like Greg Maxwell as the authority who knows better.

But I suggest you all go back and read Greg's posts on the subject. About the only technical objection Greg has against BIP110 is that if you do some convoluted anti-hijack multisig with op_if in Taproot with a depth of 7 leaves, and you delete your keys, BIP110 will steal your coin.

Greg Maxwell is telling you that you need to delete your keys in order to lose your coin. But that has been the trust for every sat in the system since 2009.

Greg Maxwell can't do technical analysis seriously because it all makes him look like a liar. So he has to resort to perpetual ad hominem attacks like in his last post.