more than happy to get into the technicalities, sharing here from a conversation i had on X (slightly modified to make sense) ⬇️
a hf is always a chainsplit, but not every chainsplit is a hf. the reason that Luke says it is "technically" a hf that is "buried" so "should be fine" is that the zkps would be introduced retroactively.
if the zkps were introduced in real time, core nodes would be served blocks they can't understand and fork. when introduced retroactively, everyone has the same blockchain, but knots nodes would replace certain data that doesn't affect the utxo set -> this is what Luke describes as technically a hf that he considers safe to do.
however, if knots became the reference client and the majority of peers would be serving blocks that replaced datacarriers with zkps, it *would* cause a chainsplit for syncing nodes, as a core node peered with only knots nodes couldnt understand what it was getting -> equivalent to receiving the zkp blocks in real time and rejecting them. As long as its the minority, it would simply ban those nodes and look for new peers that it is able to talk to.
fyi, luke does not use the word "chainsplit" in the messages, but he is defacto proposing the mechanisms that would technically cause a hf because it *is* a consensus change, but it wouldn't cause an immediate chainsplit – not because of any agreement, but because of the retroactive introduction of the zkps that do not touch the utxo set, as long as nodes not running the alternative client can get their blocks from somewhere else.
I think it's absolutely fair to argue about whether to even call that a hf if it is only a hf in certain scenarios, which we did not do in the article as we merely focused on what Luke said, and to Luke, it is a hf *because* it is a consensus change.
I agree that we should have put that in perspective and are working on a follow up article on that, but I don't agree that that makes our article “fake news”.
Second, a chain split here becomes even more likely due to Luke’s argumentation that his proposal should be backed by the law – even though the following scenario would require a separate upgrade that goes beyond removing data.
the important part here is normalizing the trusted committee and the risks that it bears in light of this idea being lobbied to be adopted in connection with legal implications, setting the precedent for Governments to make all kinds of other demands to the committee – e.g., please modify the client so users can remove transactions that violated sanctions, remove txs that do not comply with KYC, etc – which then causes a chainsplit as you are modifying the utxo set.
anyone who doesn't comply would then violate the law as we've seen in the prosecution of Roman Storm, who was not bound by law to implement KYC/AML but allegedly had the means to do so, so he was charged with conspiracy to violate sanctions and launder money. for context, note that for Storm this argument is much much weaker, as it only pertained to implementing KYC on a frontend.
you are then in the dilemma of what a miner would do: would they mine on the original chain that can violate sanctions, or on the chain that doesn't?
by lobbying for the adoption of this idea you are quite literally asking for a hard fork to happen that splits the network into a "legal" chain and an "illegal" chain – which is Luke's entire prerogative for removing CSAM.
this would apply the same justifications as it does to CSAM: if this doesn't happen, "bitcoin dies," as relaying the transaction of a terrorist is arguably just as bad as relaying CSAM if we logically follow Luke's argumentation. this is the "slippery slope".
an important point here is that the Government could already ask miners to censor transactions – but retroactively removing txs would be much more attractive to them, because censoring on miner level does not invalidate txs, but retroactively altering the utxo set does.
This is important because AML/CFT detection rarely happens in real time, so these txs are hard to prevent.
I agree that this too should have been better explained in our article and will be included in the follow up, but again it dont think it qualifies our reporting as “fake news”, especially as a publication that covers in depth how things like the application of the BSA is being considered by the US Government on a regular basis.
As frank corva can tell you and has stated publicly in response to our reporting (and we have reported extensively on), looking for ways to stop illicit activity on bitcoin is currently one of the main issues discussed in politics.
To briefly address what Udi says as this wasn't written in response to him: with Luke's proposal node operators would still "download spam" but could remove it from their copy of the chain, the delayed syncing is possible but inconvenient, calling the messages "not a plan" is semantics, the technical distinction of hf vs. split is correct in certain scenarios, the zkps would require trust that the zkps are valid bc there's no other reliable way to detect CSAM, I'm not aware of a "technical" hf that wouldn't violate consensus, maybe don't try to use things that udi writes as a gotcha.
As a side note to the commenter above you, assuming that someone is stupid because you don’t understand the information they are presenting doesn’t exactly make you look intelligent.