I'm not accusing you of what I'm about to say, and I suspect I have misread you, but right now it looks to me (probably unfairly) as if this happened: you read Robin's proposals (bitvm 1 and 2), found that it is possible that the final verifier ends up with all user funds in a 1-of-1, decided that is too dangerous, and therefore modified the proposal to create two variants: instead of sending all user funds to the final verifier in the event that all prior verifiers were dishonest, you can instead design a protocol that burns all user funds, or sends them to an anyone-can-spend address.
We took care in the article not to mention Robin at all. We looked through all the documentation/code we could find on BitVM pegs/bridges (which is sparse), and found that for some bridge proposals it seemed that the ultimate outcome of a bridge operator failing to front the withdrawals was them losing access to the bridge funds (https://www.blog.citrea.xyz/unveiling-clementine/). There was no mention of the funds going to a final validator, only that any bridge operator who failed to make a payment would lose access to bridge funds forever (emphasis not my own). There was no implementation of the challenge/response process, and the BitVM repo has been nuked, so it's hard to find accurate information on this. Admittedly, I believe we may have misinterpreted this description and what the ultimate fate of the bridge funds would be. I'm continuing to educate myself on this possible misstep today.
If you could also point me to any discussion around how the last validator is determined (if there has been any), I would appreciate it. My assumption will continue to be that if a bridge operator fails to make a payment for a bridge at large scale, all validators will also be unable to do this and we reduce to a 1/1 with the final validator.
That being said, I still take major issue with the claim that:
Robin's model only claims to improve the trust assumptions from m-of-n to 1-of-N (where m is greater than 1)
It feels either like a complete oversight or disingenuous to claim that "trusting" the validators requires them to: a.) become a bridge operator, and b.) source liquidity to front all withdrawals.
That is a far cry from what we mean by "honest" in every other situation in blockchains. A Bitcoin node being honest means rejecting blocks that break consensus. A multisig bridge being honest is signing valid withdrawals and rejecting invalid ones. A BitVM validator being honest means in the event of operator failure potentially sourcing millions or billions of dollars in liquidity? There is a a stark disonnect in what validation/honesty means on BitVM vs every other system.
There is nothing inherently wrong with the BitVM design, it works great at the small scale. But I still believe the economic description of how the system works has been at best ignored and at worst obfuscated. It should be made abundantly transparent that "safety" for a BitVM bridge means a bridge operator keeping a 1:1 capital ratio with the locked bridge funds.
I see L2s claiming to be "safer" by using BitVM, but also clearly aiming to attract a large amount of capital users. I believe these two goals are inherently at odds for capital efficiency reasons, and I believe this fact needs to be acknowledged by the broader Bitcoin community (builders, VCs, etc.).