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.

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.

(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.

Yeah, i think that's a fair question. It wouldn't be my choice, though I don't see it as like, objectively wrong. Rust gives more guarantees, for example. My guess is that it was easier to start from the existing codebase and refactor (indeed a lot of the existing codebase is still in there). But you'd have to ask m0wer.