>No, LN is still always cheaper (modulo on-chain HTLC resolution). In Ark even if everyone is exiting and splitting the cost (which isn’t quite how it works but let’s assume), the cost to exit is one-two transactions per wallet (average of one tree transaction plus one transaction to resolve their vTXO. You could do the resolution later so maybe it’s one but depends a lot on the specific construction). In LN it’s always only one.

I don't understand this. First, AFAIK unilateral exit in DryjaPoon always has 2 txs (otherwise you wouldn't have punishment), not one. Secondly, I'm assuming an economic push towards cooperating users just evicting non cooperative ones, so it's not even always 2 tx per "wallet", but potentially even as low as 2*logN/N txs, in optimistic cases where users just migrate to another ark where the current one is unresponsive. I know this is not how it works now, but I'm speaking about the potential evolution where high fees may push the system.

There should be a recording! Try website of Bitcoin Historico conference.

Best compliment but also eldritch horror in the same sentence. <3 @note1dw0vp...

Sorry for the delay. Nostr still sucks. :)

> Worth pointing out that Ark doesn’t materially “scale” without adding payment channels on top (ie Timeout Trees). Until that point, you’re really stuck with the statechain model, which has a highly-trusted third party, as you note.

I'd say you have the statechain model *until* you get the confirmation, then the model is closer to a DryjaPoon LSP than a statechain, until the expiration time. But yes, I agree the Ark model will be really interesting with channels on top, they are working on it since a while and it makes sense: https://blog.arklabs.xyz/bitcoin-virtual-channels/

> Huh? Ark is strictly more expensive to unilaterally exit than classic lightning.

I guess I'm playing with the word "unilateral" a bit here. I think that, realistically, the relevant thing is the exit against the coordinator, not against all the other users. The total cost of an unilateral exit in Ark is higher, but you can conceptually split it among more people in most failure modes. In a classic DryjaPoon, you share an UTxO among 2 users. That means that in best case scenarios (cooperative) the cost for opening/closing/resplicing would be X/2. In uncooperative scenarios, the cost for the exiting user is X. In an Ark with N users (ASP included), opening/closing/closing has a cost of about 10X, but that would be shared among N in cooperative cases, N-n in case n (most importantly including the ASP) are uncooperative.

> f course as mentioned above if you want scalable, trustless Ark you need payment channels anyway, so it’s strictly more complicated!

Good point.

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 @nprofile1q... here: @nevent1qqs.... 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.