This is overall not bad, imo. My main criticisms to would be: 1) it propagates without nuances the "experts vs demagogues" false framing, which is mostly made up (the "Knots side" includes experienced developers like Luke or SuperTestnet, who are way more technical than some influencers on the "Core side" like Shinobi or Lopp, who are more skilled at popularization and mass communication, letting alone that Dunning-Kruger doesn't just apply to computer science illiteracy, but also to economic, social and legal illiteracy, which also abunds on both sides), 2) it completely misrepresents Citrea's involvement, depicting a bunch of literal shitcoin scammers as "legit", and claiming they "need" that specific encoding method (which they actually adapted just out of laziness and lack of care), and they are "hoping to move to less harmful methods", which they publicly stated they aren't even considering at the moment, 3) it omits a lot of nasty triggers by some influential people on the "Core side", which are imo at the root of the current division and drama: the "it isn't spam if it's valid or pays fees" nonsense, the "mempool policy are censorship" nonsense, the "spam filtering in Core never existed" nonsense, the vitriolic and obsessive witch hunt against important and good projects for Bitcoin like OCEAN and Start9, the gross mismanagement of the github repo, the fixation on mempool changes as a way to show dominance and regulate personal beefs, etc. For the rest, pretty good. I agree with the overall takeaways: - search for the truth instead of parroting the slogans of your tribe - mine on OCEAN and DATUM (and maybe tomorrow SV2) - run your node with your own mempool policies (I'm filtering "inscriptions" since 2022) - keep looking for possible long-term mitigations to spam (witness discount removal soft forks, fast-to-update user-side spam-filtering policies outside of Core, etc.)

You do hodl your own keys with Ark, and those keys can exit unilaterally after one block (comparable to onchain levels of sovereignty, pluse state-chain security before that moment, which is less than a DryjaPoon channel but more than you can say onchain). In very high fee scenarios, unilateral exit is economically feasible for most amounts in Ark, but only for very high amounts in DryjaPoon channels. Running your node is a bit orthogonal. It's just that an Ark client node on top of a L1 node is a trivial thing, unlike a node to manage DryjaPoon channels. Protecting your own privacy is something you can do well with SOME current DryjaPoon channel setups (with unannounced channels, blinded paths and Tor, for example), and that is still slightly worse for Arkade afaik right now. But it can get very good (see the original Ark paper with also tumbling and chaumian stuff included). I agree with you that "90%, is very possible with LN". Today the LN is a universal, global, invoicing/hopping/swapping standard across many local security models with different security/usability tradeoffs: L1 (moon), ecash (minibits, fedi, mutiny, etc.), liquid (aqua, bull, breez, etc.), spark (WoS, Blitz, etc.), dryjapoon (phoenix, etc.). I think this complex variety will eventually collapse into a simpler number of primitives (namely: ecash for super small amounts, a mix of arks and spilman channels for average amounts, onchain for super big amounts). Using your own brain is very likely orthogonal. 😉

Hodl your own Keys. Run your own Node. Protect your own Privacy. Use your own Brain. In all these cases, trusted third parties are a security hole. (and btw Sats Are The Standard)

I hope to have clarified why. After our agreement about ordinals being retarded (and not a fundamental threat to Bitcoin), I couldn't really ignore the escalation, initially just because I got myself involved into OCEAN. Even if the entire deal of the pool is about miner-side template creation (which means they will be able to include everything they want), for a few day it worked using Luke's own default node, which is Knots, which was filtering out inscriptions (and incidentally also the >40b opreturn that the Samourai devs needlessly used to label pre-coinjoin txs in their terribly broken scheme). The option to switch to Core was added, as planned, a few days after that, but in that brief time the whole operation was targeted with nonsense "censorship" accusations (and even worse, for a coinjoin advocate, power-user and patron like me: accusations of sabotaging privacy practices). To this day, I still read stuff like Gmax publicly defaming the company, and I can't ignore it, since he's attacking me as well, in a way I consider absolutely unfair and unfounded. Then I've seen the github abuses after the first PR by Peter (the one eventually closed down), which I couldn't ignore because it brought me back to some serious red flag about Core development organizations and processes (namely the infamous "blocklist" episode, but also other less public discussion I was involved in, regarding developers rejected from residency program due to their perceived politics, or a couple of "DEI hire" operations ended up with maintainers explicitly praising Buterin in public). I just couldn't ignore the gaslighting attempts of people trying to re-frame some history which I was directly involved in, or suddenly labeling as "crazy", "dangerous" and "against Bitcoin's ethos" the very same sentences about onchain spam that they would have written themselves just a few years before. These two situations, combined, made it very hard for me to ignore the story as you did, and radicalized me enough to make a "Knozi" out of me, even if I fundamentally agree with Todd (who's a personal friend of mine just as much as Luke is) about mempool policies, and if I disagreed with most of them about the "existential" magnitude of the spam issue. When the CSAM FUD started, I voiced my disagreement privately and publicly, without any ambiguity. When the contentious "UASF" proposal surfaced, I did so even more. But I still remain very concerned of all the rest. I don't think Bitcoin is going to die. I think the role of Core as the reference implementation we know may. Which is not optimal for several reasons.

I totally disagree it was unnecessary: I am convinced that it is exactly that behavior to explain a lot of the current situation of "anti-Core sentiment", way more than the technical point itself, which I consider, like the video author, a nothingburger. The video itself is ending with a (imo correct) analysis on possible social consequences, beyond technical ones. Thus I consider it unfair to blame me of "turning a technical debate social" if I comment this point. My answer to your question, before the fork proposal, would have been definitely A: when the CSAM FUD emerged, a few months ago, the conflict was already since months at maximum possible escalation levels, with reciprocal bad faith assumption, very strong public accusations, github moderation abuses, lobbying to investors to defund Luke's mining project, bans from physical meetups, etc. After the fork proposal, maybe B could be true, but not sure. One one hand, the fork is intended to avoid "sanctioned/contiguous CSAM encoding onchain" (which I don't think makes any sense, without a hard fork to also remove the not sanctioned/contiguous one already present, which I would consider overkill anyway with respect to the legal risk): Luke's implicit accusation of moral complicity by developers doesn't play a central role in it. On the other hand, it seems like many fork proponents think that this aura of moral complicity may be in itself a key reason for the fork success, so maybe it's B.

I'd not restart numbering when listing different points: harder to respond. 1) It's true I am Luke's friend, and I'm biased towards him. But I'm also equally friend of, say, Peter Todd, and I'm also defending him personally. Overall, I think I have way more personal Bitcoin friends on the "Core" side. I'm not convinced it was a Core dev to rob Luke: I find it more likely it was the US Government, and that the FBI pointed towards Core devs to seed drama. 2) My involvement with OCEAN preceded the recent spam drama, and it was about DATUM and about the LN payout market (and about helping Luke, of course). I think the spam drama damaged the company (and my economic interests in it) a lot, but I fully understand it came from a place of principles, and I appreciate principles over profit, to a degree. I think OCEAN would be better off if this all debate didn't exist. 1-bis) He doesn't lie, and he doesn't claim that. He claims that data encoded before were "not sanctioned". I think this distinction is legally and morally meaningless. I think he's totally wrong. 2-bis) Because he agreed policy is the best place to spam mitigation. Consensus change is something he now wants due to the (imo absolutely misguided) CSAM scare. [unnumbered]) Luke is very technical, and Mechanic was always pretty civil on the mailing list. But I find the two claims unrelated: Greg Maxwell is also pretty technical, and he has been not civil at all.

Thanks for your answer. About 1 and 3: fair! About 2: I don't think Citrea was the sole reason to raise the limit, and I don't even think it was a relevant reason at all. See my response to here: . I think there are many, legit reasons to move from the old "policy as nudging" design to the new "policy as predicting" idea. I'm sympatetic towards LibreRelay, technically.

3) Not supposed to be a technical argument? The video I'm commenting goes way beyond purely technical issues, of course. I think the sentence “Bitcoin Core is trying to force everyone who uses Bitcoin to distribute child porn”, beside being imo false in many ways, is indeed pretty triggering, and I did frequently condemn this rhetoric trend (not only by Luke, who will mean the above quite literlly and autistically, but also by others that arrive to imply terrible things about Core developers). It's just that I don't think it can explain very well the radicalization, which by the time the whole CSAM nonsense appeared on the scene was pretty much already peaking. Not sure what "the shit I'm throwing at the wall here myself" is supposed to be. If anybody felt triggered by my comment to this video, it would be fascinating for me to imagine why. But I think I was pretty non-inflammatory.

1) I agree with you, and disagree with Luke, about those CSAM claims: I find the entire thing nonsense. And I'm not sure about your argument with SuperTestnet, I'll read it better. My claim here is not that Luke or Supertestnet are always right, it's just that the "experts vs demagogues" framing is misleading, if repeated as blanket statement without careful specifics. I just gave 2 examples of very technically experienced "Knozis" and of 2 communication-skilled "Coretards", I could give many others, including most of the current "Coretards" that wrote down the very same "Knozi" talking points just a few years ago (of course they could successfully make the case of why they changed their mind, but their past positions were not motivated by technical illiteracy or by demagogic influence). 2) I'm not claiming it was about Citrea specifically, and I don't think it was. I think it is about a clash between two legit design philosophies: the original "mempool policies as network nudging" one, and the more recent and uptrending "mempool policies as network predicting" one (I'm more convinced by the latter, so I'm "team Core" in this). I thin it is also about a trust crisis in Core's main people and processes to levels not seen since the block size wars, and a fracture between them and some relevant users. I think it is also about old personal beefs, radicalized by a specific nasty event, and about the broader "culture wars" splilling into Bitcoin a bit. I just wanted to clarify those points about Citrea.

Very good!