You don't have custodial risk with Phoenix. It's entirely possible to use Lightning self custodially without needing to worry about channel management, I've done it for years.

Citrea, which has been live on mainnet since January, uses basically the entire BitVM stack to create ~ trustless proof of a valid withdrawal. https://eprint.iacr.org/2025/776 But then it also lets N of N signers just sign off an exit unconditionally?. Section 8 of their Clementine bridge protocol paper: "Optimistic Payout. The protocol we described above guarantees that any peg out is completed even if all Signers are offline and all but one are malicious. However, if all Signers are honest and online, they have some time (in Clementine, it is ≃ 1 hour) to sign an issue a user’s peg out by posting an OptimisticPayout transaction. This transaction resembles the Payout transaction, with only two differences: (i) it spends the output of the MoveToVault transaction, so that the funds given to the user do not come from the Operator, and (ii) there is no OP RETURN output. If no OptimisticPayout transaction appears on-chain within some time, the peg out request is picked up by the Operator and the Clementine continue as described in Section 5. To enable the optimistic payout, Signers must not erase their keys, making the protocol secure against a non-adaptive adversary." I've spent the last half hour trying to find any discussion of this. It looks like a very bizarre decision as it seems to throw away most advantages over multisig federation control. Notice how the signing keys have to remain essentially hot.

Archiving joinmarket-clientserver ; see "final" (almost certainly) release: https://github.com/JoinMarket-Org/joinmarket-clientserver/releases/tag/v0.9.12 . A couple of years back I pulled away from doing anything more on the project, hoping that it would kind of "organically" continue somehow or other, but activity was a lot less than expected (though it was actually maintained, we weren't producing releases etc. ) .. but i was also kind of vaguely "expecting" that some people might fork and/or rewrite, as rewriting could make a lot of sense; more recently, m0wer has actually done that; see https://github.com/joinmarket-ng/joinmarket-ng ; as per notes, I can't literally "recommend", not without an absolute ton of work, and even then, it's only my opinion which isn't much. But what review I *have* done has been positive. The most interesting part is finding anti-DOS and anti-fingerprinting solutions that are practical; it's very difficult, but interesting work, so if anyone is interested, I'd recommend heading over to that repo.

Genuinely curious; would you say the same about an increase in supply from 21 million to some extended schedule of emissions to secure mining? I'm guessing you would. I do find it interesting that bitcoin could ultimately be 'hoist by its own petard' in this sense. Satoshi's 'set in stone' idea was that fully permissionless *evolution of state* of a fixed protocol is possible, using large scale proof of work. But that 'fixedness' is ofc just human consensus, and if the proof of work moves to a less ... stone-y system, the security is lost.

To and and other people that are advocating for coin freezing as a possibility: the responses in this thread I think provide a really useful window on the user level perspective. It seems like more than half of the responses to this Arbitrum tweet are saying "shucks, I guess we only have bitcoin to rely on not to freeze funds", e.g. a typical response is "Cash under your mattress and bitcoin are the only truly decentralized things" or the most apposite: "Well, bitcoin has no "security council" .. and I'm happy for it". But if you keep reading the replies you'll eventually find one that says "even in bitcoin they talk about freezing funds for whatever reason. Only left is monero then?" https://x.com/arbitrum/status/2046435443680346189?t=NN-wAuSW8rv69Yziba2R4w&s=19 I know that a decentralized system can't depend on goodwill, and everyone is always free to propose whatever the hell they want, but what things like bip361 are proposing is "let's completely destroy bitcoin" - because you're proposing replacing it with something that has a "security council". Users of bitcoin absolutely don't want that thing as the thread above illustrates, it's *the only thing that makes bitcoin valuable*. I honestly think even the discussion so far, because it has included a lot of influential devs (and not just a lot of suits who we are used to ignoring) has already damaged bitcoin's value (sorry don't mean to sound histrionic, lol, but I really do; it's a new threat vector that some of bitcoin's devs are proposing to destroy it!).

I think Kimi is better than Claude for complex mathematical reasoning. It's probably more or less the same basic model but they seem to have tuned it to really investigate and reflect more carefully.

Access to communication channels could be crucial to saving your life.

Yes. But Israel and the UAE have not totally shut down the internet.

Meh, that's mostly a mischaracterization I think. Bulletproofs as originally conceived was a valuable addition to the mix; it didn't have succinct verification so it couldn't *directly* compete with Groth16 and other pairing based schemes but it did have: no trusted setup and no assumptions outside of ECDLP. The other option was STARKs but the proof sizes were large. The verification scaling being bad was addressed in HALO and HALO2 with some rather clever tweaks, keeping the no-trusted-setup property while getting succinct verification. So nowadays it's a general class of algorithms see "folding schemes", "inner product arguments" and those can be flavours of zkSNARK; bulletproofs literally purely as originally written, yes, is rarely used, although perhaps occasionally still finds a use - an example is Curve Trees, which you mention. But it's also a paradigm which continues to be used in more sophisticated forms. Perhaps a confusion here is you were thinking about 'bulletproofs for confidential transactions via range proofs' (still used in Monero) as opposed to 'bulletproofs as a general ZKP system' (which was in the original paper).

Section 8.1 of BitVM2 says that challenges are open; that since this offers a griefing vectors, challengers should post collateral; and that since that disincentivizes, they add on a crowdfunding element with sighash flags. I suspect (but definitely don't know) that what this means in practice is, challenging could be made to work if the costs aren't exorbitant, but the costs are pretty exorbitant in the basic BitVM(2) design - section 8.5 talks about 4MB txs. Possibly if something like Glock+Argo mac or BABE or similar actually ends up working, the whole thing becomes more practical. But with very chunky assert transactions it's pretty problematic. But very vague uncertain comments, here.

It's a pretty good heuristic for judging which side is evil in a conflict. Which side prioritizes preventing communication rather than enabling it? This is why I consider my own government system evil (the UK). There are a lot of things you can argue about, but this started actualizing in the 2000s: criminalizing or semi-criminalizing speech (see e.g. "non crime hate incidents"). That was the point at which I decided the UK's governing system had become evil (and after that, rapidly despaired of any reversal, because the population did not in general reject it as such).

(trying a second time.. sorry if this answer repeats) It's 1 of n operators for *liveness* of exit. But the 1 of n honesty is only on the signing committee at setup, for covenant emulation. There's no 1 of n honesty assumption in the fraud proof part, in bitvm2 (otherwise you could ditch all the machinery and just ask for an n of n multisig! - which is exactly what clementine is allowing as an optimistic route). That's my point (I also wrote a delving post yesterday, Ekrembal wrote a response, I think it's kinda interesting. I don't see how his argument holds up.

It's 1 of N on signers at setup in bitvm2-core. But that's completely different from 1 of N continuously on live signers

I think I can explain it: every offchain protocol can be done, no matter how complex it is, if you have N of N agreement. For the case of a bidi payment channel, you have exactly that : 2 of 2. updates (or "contract novation" to get all fancy) happen by agreement, and there's a trick to invalidate old contracts. A full L2 for 1M users could also do this, modulo computation and bandwidth. The reason nobody takes it seriously is because of the liveness requirement of N of N being unrealistic. We want for the bigger L2 systems to allow a decent level of passivity; with 2 of 2 you do have a liveness problem for sure but at least it's not "1 person out of 1000 wants to do a payment, an can't until literally all other 999 are online" :)

Yeah. Obviously it's very different from the LN model (in which this problem kinda doesn't exist; a bilateral contract, make agreements, prove equivocation; no global state issue) but as I've continued to read up on this (and also, just .. remember some of the details of BitVM2), the point has resurfaced: the way that BitVM-ish models address this is, crazy as it sounds, via PoW in the chain. They actually SNARK-prove that they are talking about "now" and not some in-the-past state, by asserting a valid bitcoin block header with a PoW that's demonstrably higher than anything a challenger or "sentinel" posts. In this way the prove their claim is "after" a particular event. So they fold in this technical difficulty into the overall main trick, i.e. how to prove state validity on L1 using a snark verifier. (When I first saw this a while ago in the BitVM papers I thought, this is batshit crazy, they're literally SNARK proving Bitcoin's history, kinda. But this chain of thought makes me realize, crazy or not, they *have* to do this or something like it).

Wow that's the closest to a blanket ban I've seen anywhere I think. "Written permission" "Freeze on suspicion" sounds appalling but unfortunately not uncommon, itself. The brainwallet is the most interesting, I've never seen that referred to in regulation before. But I guess there is precedence of LE demanding passwords that they "know you know".

What happened exactly?

Your identifying the ZK exit proposals is useful. I'd point it back to our earlier discussion, somewhere, where I was saying something along the lines of "there is a catastrophic faliure mode that is unavoidable". In the scenario where a CRQC is developed, quickly, before escape routes are created, secretly and creates the ability to spend any key immediately, bitcoin is fucked - full stop, no argument. In the most likely scenario where all that is reversed - escape routes are created in advance, the development is at least semi-public and very slow, that analysis doesn't apply. The point of discussion is (imo) only the intermediate case - we have a slowly developing escape route, and we have a semi-public, slowly developing concrete CRQC threat. there might be some intermediate point of time where the argument "some coins can be protected by an ECC freeze" I think is defensible, but I'd still say it's very close to a complete failure vector. Because once the precedent is established, it will definitely be used to push other similar cases - the mining security requires inflation argument, before long the North Korea threat, and the will someone think of the children threat leading to a complete loss of the permissionlessness principle. So I'd say that that's a "75-90% loss of bitcoin being bitcoin" scenario that I think could only be defended if there was a 75-90%++ chance that the whole project is, right now, failing in any case. It would be a near-catastrophic failure, in itself, if we ever had to enact it. But it gets hard to argue details precisely because it's specifically the messy case, where we can't know the details, where the argument holds merit.