> 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/
Yea depends a lot on how refresh happens and how much you transact. If you transact daily and refreshes are only once a month you’re effective always in the statechain world (at least until payment channels on top of Ark!). This is kinda my base case. If you’re more of a receive-only/savings wallet then it’s less trusted. Good luck explaining that to a user 😅.
> 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.
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.
If you have any HTLCs pending you have to resolve them in LN, but I’m kinda assuming all the Ark things will mostly be used with HTLCs so you’d end up with the same in Ark.
>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 nostr:note1dw0vprhsxspk6sc0j2xzl0adcjk9dsj2xaz07uxx6jmnu9efwhvszqsflu
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 nostr:nprofile1qyx8wumn8ghj7cnjvghxjmcpz4mhxue69uhk2er9dchxummnw3ezumrpdejqqg8g6e7yxkj2tycyu9q59q8f2th7z7lyy48u5fu3d0mrl8mnu49t5s02kql2 here: nevent1qqst8sey22gvdacef3hj8naamfvdymy8kck0mz0407skgtx97myz80cw9u8aj. 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 tried to earnestly understand and explore nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk and nostr:npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s’s arguments.
With Luke I just have to say “agree to disagree” when he argues that CSAM is _only_ illegal/immoral when it’s in an OP_RETURN up ‘till 100kb post-September 2025— everything else is “non-CSAM” in his view even if they’re the exact same bytes.
Super Testnet meanwhile seems to have gotten stuck on this question: nostr:nevent1qqszr45wevkva76m7ypmaklmj7wq35h8g3g0a0zcpdmf6zemzlj63pgpp4mhxue69uhkummn9ekx7mqzyr5dvlzrtf99jvzwzs2zsr549mlp00jz2n72y7gkha3lnae72j46gqcyqqqqqqg8vjxqn 2. It was never about Citrea specifically; Citrea just showed that there is demand for >80 bytes of data, and if such use cases can’t use OP_RETURN they’ll just use fake pubkeys which NO ONE should want. 3. Not a technical argument. But I’d say if anyone uses nasty triggers it’s Luke et al claiming (and this is a real quote) “Bitcoin Core is trying to force everyone who uses Bitcoin to distribute child porn”— not to mention the shit you’re throwing at the wall here yourself.
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.
This is overall not bad, imo.
My main criticisms to nostr:nprofile1qqszq6eh3h2gyyjc0647hhrykqzsnvd0gyhcgkd5s60lp6wp0usqpmcpzamhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuegpzamhxue69uhkummnw3ezuervwdhh27np9ekx7mq3x3s2u 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.)
Panel? We need an entire conference on this! :D
The Forum date is kinda dictated by the end of Lugano's high season. But you could come to visit in any other moment and we could build events around it. Lugano will start its very first Bitdev right after the Forum, perfect venue for Consensus discussion!
Residency doesn't mean the whole team moving to live to another place forever. Could be something as trivial as a few months of cooperation with local institutions with a few in-person meeting. But that can only be negotiated based on the amount and the kind of project, unfortunately I can't give clear boundaries in advance. You can still win and refuse, Perelman-style. :)
$850k for for-profit and non-profit Bitcoin-related projects!
Apply before October 10th!
Bellissima intervista su "20 miuti" di Tio (dovremmo rinominarlo "21 minuti"!!!):
nostr:nprofile1qyxhwumn8ghj7mn0wvhxcmmvqyvhwumn8ghj7un9d3shjtnpvahhy6tnwsh8xurpvdjsqg975y6lq8hxrq4cvx9v42j7al2jw8ez6hyt9qn5z0lgjjnjqpguxcalxwsl we may know who it is now: https://x.com/snapolino/status/1959192943442702372
Uhm...sure...how?
Subtle reference to this
https://x.com/MichaelDunwort1/status/1950077998419567048?s=19
Plz Bitcoiners do your thing and help us getting Lugano's Major's back in putting the Satoshi statue in an even more outrageously visible place of the city (yes, yes, I know, trivially sybil-prone method, our Lugano community could easily create 5000 burner mails, but don't make us do like Core shills spinning up 500 fake nodes every day, just use your own to sign, c'mon)!
https://www.change.org/Restore_Satoshi_Statue_Artwork_Lugano
I'm on nostr:nprofile1qqs8t4ehcdrjgugzn3zgw6enp53gg2y2gfmekkg69m2d4gwxcpl04ac04xqkm white noise with my npub. Based. Write me there. I'll probably not read messages everyday until somebody integrates it into a Beeper fork (I may issue a bounty about that someday), since I'm too brain-damaged to use several messaging apps on GrapheneOS (also one of the reasons I don't check NorstrDMs and Keet messages everyday). But I'll read!
Since I won, nostr:nprofile1qqsve2jcud7fnjzmchn4gq52wx9agey9uhfukv69dy0v4wpuw4w53nqpzemhxue69uhkzarvv9ejumn0wd68ytnvv9hxgqg4waehxw309ajkgetw9ehx7um5wghxcctwvscxst82 will be forbidden from proposing tail emssion madness again. :)
But since I didn't win by much, he will keep proposing demurrage. :(