4027 sats \ 0 replies \ @supertestnet 6 Apr freebie
This criticism of Robin's bridge model seems to incorrectly state that verifiers can burn user funds in step 8. That is not my understanding of Robin's model, I believe that if the prover does not process a withdrawal, the verifiers can burn some funds that the prover himself put up as a kind of stake to dissuade dishonest behavior, but user funds do not get burned, they simply move to a new m-of-m multisig controlled by the remaining verifiers.
One of them becomes the new prover and must process the withdrawals now otherwise they lose their own stake and the cycle repeats until one of two things happens: either some verifier processed the withdrawals properly when it was their turn, or all user funds become the sole property of the last verifier, locked to a 1-of-1 where he or she is the only remaining keyholder.
At that point, this final verifier can simply send the users their money without hindrance. But if he or she is dishonest, users are out of luck, the last verifier can run off with all user funds if no previous verifier could or would perform the withdrawals honestly. (This is largely why you must always trust at least one verifier to be honest, in Robin's model.)
Also worth pointing point: my unisob bridge model is unaffected by this criticism. The prover sources the funds to perform a withdrawal when the user first deposits money to the bridge, and every depositor gets to withdraw up to the amount in their own individual contract with the prover. If the prover is unable to source sufficient funds, the would-be depositor simply aborts and never makes their deposit.
reply
1017 sats \ 2 replies \ @twhittle 6 Apr
Hey Super! Thanks for putting together this writeup. It definitely helps clarify the nuances of setting up a BitVM bridge. And I appreciate that you are one of the very few people who actually put together a bridge implementation.
In the article, we said "burned" for a couple reasons.
First, it just helped simplify it for the reader. The main point of the piece was that a safe bridge (as your design is) requires a 1:1 collateralization ratio. If the bridge operators all fail to pay out, then the users effectively lose access to their funds/require enormous trust assumptions to get them back.
Second, I think the options for places the funds go if the final operator cannot pay out effectively reduce to three options: the final verifier, anyone-can-spend, burn address. 1.) The final verifier - requires a 1/1 trust assumption to get funds back to users. not great.
2.) anyone-can-spend - miners get the lion's share of the bridge
3.) burn address - cryptographic security that bridge funds are inaccessible by anyone
In each of these cases, we range from highly unlikely to impossible redemption of funds.
With that said, the higher level point is that we were frustrated with the narrative that BitVM bridges fix the issues we have wrt trusting bridges. Companies like Citrea, BOB, etc. are good actors, but the landscape is littered with many others who are not. A bridge of your design is 100% safe, but it also doesn't scale economically. There are other designs that do not require these collateral requirements and scale better but also put users' funds at risk.
The worst case is a company building a BitVM bridge and not understanding the economic reality and design tradeoffs of the system. It's very easy for me to imagine a scenario where an L2 bridge decides a 10% collateralization is acceptable, grows large in terms of TVL, and all users funds get burnt/lost following a mass withdrawal. This is terrible for our space, and something I strongly prefer we avoid. My hope is that by putting this information out there, we can go in eyes wide open to the economic realities of bridges built on BitVM.
reply
1116 sats \ 1 reply \ @supertestnet 6 Apr freebie
I have not yet implemented unisob, it's only a proposal. I've been working on hedgehog instead, which is unrelated to bitvm
I'm glad this is not the "only" reason. Robin's model, at least bitvm 1, does not seem to propose any scenario where user funds get burned. I haven't investigated bitvm 2 yet so I can't comment on that. Be wary of "simplifying" something by changing it into something totally different, which is what I think you've done here by mistake.
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.
Then (again, I don't think this is reality, only a fantasy I've concocted due to misunderstanding you) you evaluated these variant proposals of your own making and discovered that they are dangerous. And you wrote a paper as if the least dangerous version (in your view, or rather the fantasy version of your view that I've invented due to lack of understanding) is the one where user funds get burned, and decided to warn everyone that this might happen.
I hope the above fantasy is not accurate and I do not think it is accurate. Please clarify where I went wrong. Because if it is accurate, I hope readers find it distressing that you did not examine Robin's proposal as it stands, but modified it to the point where all user funds might get burned, and then warned people that your modified proposal is dangerous, while continuing to call it Robin's proposal -- even though that doesn't happen in Robin's proposal.
The reason this paragraph is wrong is because the "final operator" -- if all other operators failed -- always has complete control over every satoshi that was on the sidechain. It does not "reduce to three options." In Robin's proposal the final operator holds these satoshis in a 1 of 1. (At least under bitvm 1, I cannot assert anything safely about bitvm 2 without examining it.) Therefore, necessarily, he can pay the money out to every user. No one can stop him from doing so. Also, no one can stop him from running away with the money.
If all prior operators were dishonest, user funds end up with the final operator, and if he disperses them to users, the bitvm protocol is done -- the trust assumption was "at least one is honest," and it was him (or her), because he (or she) kept his (or her) promise to pay out to all withdrawers where no other operator did. If he (or she) does not do this payout, whatever he (or she) does after that is a violation of the bitvm protocol. He (or she) might keep the funds, send them to his (or her) friends, burn them, or send them to an anyone_can_spend address. These last two seem like particularly insensible options for the final operator to do.
Robin's model only claims to improve the trust assumptions from m-of-n to 1-of-N (where m is greater than 1). He has occasionally seemed to me as if he wants to claim it does more than that, but I think I sufficiently badgered him about it and, at least in my presence, he has maintained humility about what his protocols accomplish, and has been careful not to claim bitvm "fixes" the trust assumptions of liquid-like blockchains -- it only "reduces" those trust assumptions, not to 0, but to 1-of-N.
I agree except I think somewhere along the line you made a mistake and became convinced that burning user funds "counts" as part of Robin's bitvm proposal, when in fact it's not, he proposes (in version 1, not sure about v2) giving them to the last verifier and relying on that person to be honest if no one else was.
I don't think users would like my bridge design because (1) it has the same "inbound liquidity" requirements as lightning (2) additionally, it requires users to "roll over" their funds into new bitvm contracts on a regular basis (3) proving fraud, if necessary, would probably be expensive for many users.
I agree that these outstanding issues make my model economically unscalable. I prefer making something that is safe first and then work on making it scale second. I suspect there are ways to fix the above issues, but until then, my model can probably only work for a small number of people, and I think that's fine for now. At least it doesn't introduce new trust assumptions. Every user trusts themselves. I'm proud of that.
reply
0 sats \ 0 replies \ @twhittle 6 Apr
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:
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.).
reply
100 sats \ 0 replies \ @lloyddunne 5 Apr
the magic unicorn, that is covenants, seems to be the answer to everything
if it is repeated a thousand times it becomes the truth
reply
0 sats \ 0 replies \ @robin_linus 9 Apr
As others have said before, the model described in that article is simply not what we're working on. Even the authors themselves had to admit publicly that they know that their claims are misleading.
In my personal opinion, this seems to be some kind of promo move for the token scam that the authors are launching this month.
reply
0 sats \ 0 replies \ @nicosey 5 Apr
back to multisigs?
reply
0 sats \ 0 replies \ @Coinsreporter 5 Apr
Every bridge has to fall some of the other day. That's sad but true.
reply
0 sats \ 0 replies \ @grayruby 5 Apr
Very interesting.
reply
0 sats \ 0 replies \ @nym 5 Apr
Not suprised. Bridges are always the vulnerable part.
reply