Unnamed Noncustodial Inchoate Sidechains On Bitvm (Unisob)

gistfile1.md

Unnamed Noncustodial Inchoate Sidechains On Bitvm (Unisob)

I have an independent bitvm sidechain model that works without a federation. Instead, there is a "bridge operator" who assists with depositing money to the sidechain as well as with the "happy path" of withdrawing from the sidechain. In my version, you can withdraw even if the bridge operator ceases operations, because there is also a "sad path" that does not require his ongoing cooperation

the main idea is that when you want to deposit money onto the sidechain you should get a "withdrawal contract" from the bridge operator

the withdrawal contract is done in bitvm and it basically says, if you (the withdrawer) can provide a proof of a valid withdrawal request from the sidechain, the prover has up to X blocks to supply proof that he sent you your money on bitcoin

if he does not supply that proof, you may slash him and take the funds that way

such a contract allows you to withdraw your funds either in the "happy path" where he just sends you whatever amount you're withdrawing, or -- in the "sad path" where he either disappears or tries to cheat -- you can take up to however much money he posted as collateral to prove he wouldn't cheat

Does that require 1:1 collateral?

if you are depositing 5 btc you must give 5 btc to the bridge operator

the 5 btc you deposit can serve as the collateral if he wishes

or he can use other funds for that

if you deposit 5 btc but hope to later withdraw 6 btc then you must pay the bridge operator to supply the extra 1 btc out of his own pocket

that way you can be sure you can withdraw up to that amount without needing to trust him

I want to do it this way because it is easier for me to code if the prover uses other funds as collateral

but even in that case they can "reuse" money from past depositors as collateral for future depositors

suppose the first depositor gives the bridge operator 5 btc using UTXO A. The bridge operator must put up 5 btc as collateral. They can either use UTXO A for that (but it's a bit confusing for me to code) or they can use a different utxo, UTXO B, for that (this is easier to code for me because it's a simple atomic swap, which I've coded like a thousand times)

now suppose a second depositor comes along. If UTXO B was used as collateral, the bridge operator fully controls UTXO A (which is 5 btc) so he is free to use that as collateral for the second depositor's deposit

How can the prover use the depositor's deposit as the prover’s collateral?

the prover can use the depositor's deposit (i.e. UTXO A) as his collateral by having the depositor deposit UTXO A directly into the bitvm address

collateral seems like a fine term to me whenever money that belonged to the prover can be slashed and taken by the verifier (who in this case I call the depositor)

there are two models that can conceivably work here

Modal A: the depositor puts UTXO A directly into the bitvm address, in which case it's not "collateral" because at no point did it belong to the prover

Model B: the prover puts UTXO B into the bitvm address and acquires full control over UTXO A, in which case UTXO B is collateral because it did belong to the prover and the verifier/depositor can slash him and take it if the prover later tries to cheat

I prefer Model B because it's easier for me to code

I know Model A "sounds" simpler ("what's so hard about sending money directly to an address?") but the hard part is making sure the sidechain knows about it. With Model B, I can have UTXO A go to a fixed "receive" address that every depositor uses, and the sidechain can just watch that address for deposits. Any deposit causes a corresponding amount of "sidechain BTC" to be credited to the depositor's sidechain address (which should be specified in the deposit transaction)

With Model A, the "deposit address" is different every time because my model does not have reusable bitvm addresses -- the deposit contract is different every time because there is a different depositor and a different timelock, and since the deposit contract is different, the bitvm address in which it is encoded is different too. So if I use Model A, even though it "sounds" simpler on the surface, I have to figure out an alternative way to let the sidechain know when a deposit happens and what address to "credit" with some sidechain bitcoins. I could probably come up with some proof system for that, but I like Model B better because this part is super simple: just watch for deposits into a fixed deposit address, and credit the depositor with an equivalent amount

Is the depositor the same person that eventually withdraws?

each depositor makes a withdrawal request when he is ready to leave the sidechain, and, assuming there is no dispute, the bridge operator cosigns with him to send him his money straight from his withdrawal contract using the multisig "happy path"

if the bridge operator does not do that quickly the depositor (now withdrawer) can challenge him by proving he submitted a valid withdrawal request, thus giving the prover X blocks to prove he sent the withdrawer the right amount of money. If he doesn't submit a valid proof in time, the withdrawer gets the money in the bitvm address (which is either his original deposit, in model A, or the prover's collateral, in model B, which is the one I actually want to turn into a reality)

In your model it seems like Alice pegs in and also Alice pegs out

Alice pegs in and Alice pegs out unless Alice doesn't have any money anymore

then Bob pegs out instead

using his own withdrawal contract, which he created independently

What if the operator refuses to create a withdrawal contract for Bob?

it is Bob's responsibility to get one before he receives any money on the sidechain

"permissioned entry, permissionless exit"

What infrastructure on the desitination sidechain (let's say Ethereum) is needed for this ?

What infrastructure on the desitination sidechain (let's say Ethereum) is needed for this ?

It needs the ability to "watch" a bitcoin address, parse utxos in that address, find the "amount sent" and some indicator of what "sidechain address" should receive that amount of money (could use an op_return to encode that info), credit that sidechain address with that amount of money, validate transfers that happen on its own ledger, and give users a way to verifiably burn sidechain coins

Thanks for clarifying your design in our voice call.

I think this bridge design is promising if a way to allow for an efficient market to arise for “swapping providers” as well as maybe multiple bridge operators which can register in a smart contract on the sidechain, the same said smart contract could also serve as the standard issuer (upon noticing the prior BTC transfer on Bitcoin ) and burner of the xBTC ( upon the attempt to withdraw back to Bitcoin ) on the said sidechain.

The main pragmatic difficulty with this design is the fact that xBTC tokens on the sidechain are not easily transferable to parties which don’t have a prior withdrawal contract with the bridge operator(s) which guarantees redeem-ability of the xBTC back into real BTC.

if this difficulty could be overcome somehow, then this design would indeed be more trust-minimized than the 1-of-N honest Verifier BitVM design currently being considered as the leading proposal using BitVM