pull down to refresh
1116 sats \ 1 reply \ @supertestnet 6 Apr freebie \ parent \ on: BitVM Bridges Considered Unsafe bitcoin
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.
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.).
reply