[Shipped] Incognito’s trustless non-custodial Bitcoin bridge

[0xkraken]

Introduction

We are designing a general solution for building trustless bridge to UTXO-based blockchains and Bitcoin is the first network having rolled out with the approach.

Shielding

Users who want to use the Incognito platform for private transactions have to port their current tokens from external chains to the corresponding private tokens in Incognito (BTC in bitcoin chain to pBTC in Incognito chain).

At first, users send their public tokens to a multisig address created by beacon validators in the external chain. This multisig address is unique for each Incognito payment address. After users send public tokens (BTC) to their corresponding multisig address, a worker will help users generate the transaction proof and send it to Incognito validators. After Incognito validators successfully validate the transaction proof, a corresponding amount of private token (pBTC) will be mined and sent back to the user’s Incognito address.

For example: if a user sends 0.1 BTC to the multisig address, that user will receive 0.1 pBTC.

Unshielding

When users want to exit the Incognito mode of their tokens, they need to create a unshield request. This request is similar to burning their private tokens and providing a remote address for Incognito validators to send back their public tokens.

Unshielding requests that happened in a short period of time will be merged into batches. This mechanism will help reduce the Bitcoin network fee for each unshielding request, and minimize spending UTXOs on the external chain.

For example: if a user requests to unshield 0.1 pBTC (burn 0.1 pBTC), this user will get back 0.1 BTC minus fee for creating an unshielding Bitcoin transaction (this fee will be sent to Bitcoin miners, Incognito doesn’t receive this fee).

Protocol Flow

(We will use Bitcoin as the example of public tokens in our protocol flow)

Generate Bitcoin Address for each Incognito Payment Address

Each Incognito Payment Address will have a unique corresponding Bitcoin Address for sending BTC. A user who wants to shield BTC has to send BTC to the corresponding Bitcoin Address that is generated with information from Incognito validators.

This Bitcoin address can be generated on the local side. Incognito beacon validators will public their master Bitcoin public key, we use the HD-Wallet mechanism following the Bitcoin protocol to generate extended Bitcoin public key for each Incognito payment address (the payment address will be used as the chaincode, and child index is equal to zero). These Bitcoin public keys will be merged to generate a Bitcoin P2WSH multisig address for each Incognito payment address.

Shield

After users transfer their BTC to their corresponding Bitcoin Address (OTMultisig). Users can send this transaction proof to Incognito validators combined with their Incognito payment address. Incognito validators will verify these proofs. If a proof is successfully validated, an amount of pBTC will be minted and sent to its corresponding Incognito payment address.

Unshield

Users create an unshielding request (burning an amount of pToken which is equal to unshielding amount). After that, beacon validators will create external transactions that spend UTXOs from the Bitcoin multisig wallets. These UTXOs are received from shielding requests. Receivers of that transaction are the user’s external Bitcoin wallet address, and the amount is the corresponding unshielding amount.

!

When users unshield, in order to reduce the network fee, and minimize spending UTXOs on the external chain, we introduce the feature: Parallel Batch Processing for the list of unshielding requests. It means, all unshielding requests of users will be added to the list of waiting unshielding requests, and beacon validators will handle them every interval time.

Sign Bitcoin Transaction

When Incognito beacon validators want to spend a UTXO in a multisig wallet, they have to sign the Bitcoin transaction for spending these UTXOs.

Similar to the process that we created Bitcoin public keys for each Incognito payment address, Incognito beacon validators will generate Bitcoin private keys for each Incognito payment address and sign Bitcoin raw transactions with these keys.

Replace-By-Fee and Check Unshielding Transaction Confirmation

Incognito validators can’t directly communicate with the external blockchain. A worker will feed external chain information into the Incognito chain.

After Incognito beacon validators signed a broadcasted unshielding transaction, that worker will broadcast to the external chain. This worker will monitor until that broadcasted transaction is confirmed and notify the Incognito chain. Incognito chain will receive this information and update the list of UTXOs that the multisig wallets are holding (append the change UTXO that is sent back).

Depending on the external chain condition, in some period of time, transactions can be stuck after a very long time. A worker will listen to the external chain and feed new fees for broadcasted unshielding transactions.

[cusdt.eth]

Thanks for the information. I’ll be studying the Github intently.

[Mike_Wagner]

Interesting. I need to read this again a few more times.

[Revolve]

@0xkraken

When unshielding, the beacon validators will create a raw transaction over the external chain (e.g., Bitcoin Chain) with at least ⅔ signatures of total validators to send back public tokens to users.

As new validators come one, don’t you have to change the multiSigniture to account for that? Also this might potentially slow down withdraws.
But it definitely is a step in the right direction, we desperately need decentralization asap.

[marko]

Awesome!! This is exactly how I believe incognito should be functioning but never mentioned it because I thought you were working on something else.

How many members of the multisig will there be? Who can be able to be a member?

I’m curious the process if someone wants to get their collateral back and stop being a member of the multisig. Obviously you can’t “unlearn” a private key. Also, if the multisig members are not putting up collateral to overcollateralize the position, what keeps them incentivized to doing their part in continuing to sign transactions as needed? If too many of the multisig members leave, there will not be enough left to unshield a coin.

Also, the opposite problem: How do you propose to limit the number of participants without putting up collateral? There are large players even with validator nodes and if collectively they gain access to 2/3 signatures, they can steal the coins. Without collateral there is no penalty.

Others can chime in here—I am not the most technical person. I’ve just watched other projects that use this sort of mechanism. It’s brilliant but also not without problems.

[Matt6412]

Has this concept ever been used? Does this concept favor nodes that are selected every epoch (team controlled) to be the gatekeepers of funds? Just trying to figure out if this is actually decentralized or just a form of a better trustless setup

[0xkraken]

Hi @marko, @Revolve,
Thank you so much because of your interest in Portal v4.
Members of the multisig wallet of Portal v4 include seven fixed beacon validators in Incognito chain. Currently, we don’t swap beacon validators and make sure there are always at least 5 validators (> ⅔) are available so it doesn’t make slow down the unshielding process.

[marko]

Hi @0xkraken
Thanks so much for your reply. That seems like a good plan for V4.

Who are the seven fixed beacon validators that control the multisig? Are these all different members of the team?

[Tempestblack]

I just got a chance to read the entire string and indeed marko and revovle raise valid issues but overall this upgrade will be incredibly amazing and I along with the community at large look forward to its implementation…great job @0xkraken…

[0xkraken]

The new status of Bridge v4 (20/01 - 23/02/2021):

What result?

• We finalized the design protocol with the trustless non-custodians approach by using the multisig wallet which is public tokens custody.
• We completed implementing almost features on Bridge v4 (including both shielding and unshielding flow).

What next?

• We do local tests on our flows and write unit tests for them.

Thanks all.

[AloneWalker]

Hi @0xkraken,
I am very interested in the way you guys make the network more and more trustless. Still, does what you say,

@0xkraken

Members of the multisig wallet of Portal v4 include seven fixed beacon validators in Incognito chain. Currently, we don’t swap beacon validators and make sure there are always at least 5 validators (> ⅔) are available so it doesn’t make slow down the unshielding process.

imply that these seven fixed beacon validators will never be swapped, never be replaced? In that case, I think the beacon chain will be a single point-of-failure and thus, the network will be more vulnerable.

[AloneWalker]

Compare to the current centralized approach, this is still much better.

[0xkraken]

Hi @AloneWalker, thanks for your question.
First, we don’t release beacon validators to make sure the stability of the network currently. But it’s only temporary. We are trying to release beacon nodes soon.

Second, although the private keys of the multi-sig wallet are generated by beacon validators, we will make sure attackers can’t re-generate or get the private keys even they find a way to access the servers of beacon nodes.

[AloneWalker]

@0xkraken

Hi @AloneWalker, thanks for your question.
First, we don’t release beacon validators to make sure the stability of the network currently. But it’s only temporary. We are trying to release beacon nodes soon.

The replacing of fixed beacon validators will make it very hard to the recovery of the multisig private key.

@0xkraken

Second, although the private keys of the multi-sig wallet are generated by beacon validators, we will make sure attackers can’t re-generate or get the private keys even they find a way to access the servers of beacon nodes.

Perhaps could you explain more about this technique? Or could you give me any keyword?

[0xkraken]

Hi everyone,

We want to give you some updates about the process of the proposal.
We will speed up the process of implementing trustless bridge v4 in order to improve the current trusted bridge for Bitcoin sooner. Here are the new timelines of the proposal:

• 20/1 - 23/2: finalize the protocol design and finish the implementation of Bridge v4.
• 24/2 - 2/3: complete shielding flow (unit tests + local tests + implementation docs), feature flag for Bridge v4.
• 3/3 - 9/3: complete unshielding flow (unit tests + local tests + implementation docs).
• 10/3 - 16/3: complete replacement fee + submitting the external txs confirmed (unit tests + local tests + implementation docs).
• 17/3 - 23/3: complete workers for bridge v4.
• 24/3 - 31/3: complete local testing by QC team.
• 1/4 - 9/4: complete testing on testnet environment. Prepare some necessary things for migration to the trusted bridge and ensure the security of beacon keys.

Note: We will deploy bridge v4 on the code base of privacy v1 in this release. Then, we will merge privacy v2’s code after privacy v2 gets the stable release.

[Tempestblack]

Thank you for the updated news @0xkraken…

[0xkraken]

The replacing of fixed beacon validators will make it very hard to the recovery of the multisig private key.

Your concern is totally reasonable. Maybe we only run bridge v4 while beacon validators are fixed. Since we release beacon validators, maybe we will switch to Bridge v3 - the completely trustless decentralized bridge.

Perhaps could you explain more about this technique? Or could you give me any keyword?

In order to ensure the security of multisig private keys, we will use cryptography to encrypt the seeds (which are used to generate the private keys of multisig wallet) on beacon servers. Therefore, if any attackers access beacon servers, but they can’t collect the seeds and generate the private keys.

[Matt6412]

@0xkraken

Since we release beacon validators, maybe we will switch to Bridge v3 - the completely trustless decentralized bridge.

Is bridge v3 the over collateralized approached method ? If so why go back to that?

[duc]

This was shipped with the release, so concluding it now.