Thanks all, I'm off.

Malicious, and hypocritical. Evades the "censorship" of a permissionless p2p network and then subjects all submissions to terms and conditions that are unrealistic for nodes to implement.

I support BIP110, I didn't support block size increases. You can hate Luke/love Roger all you want, it makes no difference.

As a dev? Technically DATUM and Knots but that'd give you the wrong impression, I'm a noob.

Neither, though you can assume the former. It's stuff that'd make me say "I don't want to run a node anymore" or even "I expect other people will trash their node over this".

It's a tradeoff, I'm not trying to bash BTCD, and yes you're right, different versions of the same implementation can cause splits too.

No, Bitcoin Core isn't literally a media player (yet?)

I hesitate to appear frivolous, but I really don't care if a split happens. Disruption is sometimes something that has to be tolerated. Stability at all costs is its own tradeoff.

Not especially. It's relevant (there's a reason op_return data is contiguous - because it's intentionally file storage) but not the be-all-and-end-all (hence BIP110 targeting OP_IF in taproot which is being used for non-contiguous file storage).

The contiguity speaks to the undeniable fact of it being very obviously for a specific purpose rather than a hack job in taproot spends that betray the fact that it was not intended use.

No thanks, too close to gambling which clouds judgement. I have no idea what happens next month and neither does anyone else.

One fought against decentralization, the other fights to support it.

So I guess they are alike in that they have both fought in their lives, and that fight involved Bitcoin.

There have been many attempts to agree on official comms regarding BIP110 scenarios that were sadly fruitless.

In the end, what happens next month depends on who you talk to, as well as how miners can prepare for it.

Jason said what he believes to be likely and stated that they're his views in so doing. I didn't have access to what he wrote prior and didn't have the option of approving/disapproving it.

I want to do that too. But it doesn't do anything about the concerns about unacceptable media storage.

That's not necessarily true...Bitcoin is obviously a prime target for intentional sabotage given its disruptive qualities.

I don't. Usually the people I block are spreading obvious misinfo or being vulgar.

I'd disagree with your perspective - it has been presented as critical but not urgent.

It was presented on the mailing list back in November. There wasn't anything meaningful by way of push back. Dathon wrote and interated on the client for a while, rebuilding BIP9 which needed to be done anyway. People pushed back on the language in the BIP using the world "legal" too many times in its rationale (I was one of the ones complaining). That was removed. People complained of it being confiscatory - so the UTXO height checker was added. (There are edge cases with pre-committed TXs I'll not bother getting in to here, yes it's possible someone can be in a crazy scenario where they end up generating a UTXO post-activation that becomes temporarily unspendable but the practical answer it that BIP110 is not confiscatory.)

Two consensus issues were found by Lorinc and another dev whose name I forget (sorry). Both of which were fixed.

We're now about 8 months or so down the line. There is clearly a lot of adoption and no one involved in advocating it (at least to my knowledge) is motivated by anything other than a desire to make Bitcoin better. If there really is something wrong with it (it's 37 lines of new code?) then there is a massive appetite for discovering and making public such a development.

All that is to say I don't consider it "rushed".

It's criticality comes simply from those who have drawn a line wrt arbitrary data, saying that if some revolting media makes it in via the apparently sanctioned methods of adding files to Bitcoin that they'd quit not wishing to host such media on their devices.

I agree with this. What's worse is that you can still be a "Bitcoin" and just make someone else deal with running the node on your behalf. That kind of centralizing pressure is unacceptable to me, and anything imminent that improves centralization or prevents something that would undermine it I will always treat as critical.

Yes, minority UASFs are clearly possible in Bitcoin and thus an attack vector.

If they are actually malicious (obviously BIP110 is not) then we are obligated to URSF against them and ensure there is no risk to miners pretending a threat of that nature is something they can simply ignore as anti-BIP110 people often present as sufficient.

Carnivore

Not much. I'm just relearning what I learnt in 2017 that many people seem to have forgotten (or never understood in the first place).

Not really. I'm fine with it as it is. 83 byte OP_RETURN could have been permanent with the taproot guard rails temporary but it would just have complicated it further.

If BIP110 is not adopted by the industry who resoundingly ignore it then I'd happily say good bye to them rather than capitulate and try something else from within.