[Shipped] Building out Incognito’s trustless bridge to Bitcoin and all other blockchains

[duc]

Updates for the week of April 20-24, 2020:

• As we’ve updated previously, the trustless bridge v2 was deployed on testnet last week and has been testing aggressively this week by QA team, thanks @hardy for your testing effort on this.
• Along the way, a few bugs have been spotted and two typical ones were related to block header relaying processes for both Bitcoin and Binance chain. Fortunately, these two have been fixed, you can find the PRs for them at: https://github.com/incognitochain/incognito-chain/pull/872 https://github.com/incognitochain/incognito-chain/pull/875
• Next week, apart from testing and bug fixing, we’ll be working on an implementation for trustless bridge v3 (Ethereum bond contract) that’s been late for 1 week or so against what we planned.

[duy]

@duc thanks for the update.

@duc

• Next week, apart from testing and bug fixing, we’ll be working on an implementation for trustless bridge v3 (Ethereum bond contract) that’s been late for 1 week or so against what we planned.

can you elaborate more on protecting privacy for custodians? how will the custodians deposit into the ethereum smart contract? will that be a direct call from the custodian eth address or will be through pEthereum? personally, i would call it through pEthereum so that i can keep my privacy without disclosing i’m a custodian.

@duc

similar concerns on privacy for custodians. how is the deposit address (btc custodial address generated? is it linked to the custodian’s identity? if so, how can we avoid that?

[duc]

hey @duy thanks for your great questions. To be honest, when we designed originally the trustless bridge, pEthereum has not existed yet. Yeah, you’re right, we can leverage the work of pEthereum to be able to preserve privacy for custodians once they deposit into Ethereum bond contract (if they want, otherwise they can always make a direct call to contract for sure)
And in order to avoid the “link” between custodian’s identity and his deposit address (say bitcoin address), the address would be generated from custodian’s Incognito private key. You can think the key as a seed for the bitcoin key-pair generation function. The custodian has then fully control on the newly created bitcoin address such as signing on a bitcoin transaction by using his own incognito private key, … Moreover, the generation is one way and irreversible so no one can link those two addresses together (custodian’s incognito and bitcoin addresses)

[duc]

Updates for the week of April 27 - May 1, 2020:

• This week we’ve been working closely with QA team to help them with their testing scenarios for the trustless bridge. Due to the processes’ complexity, the testing seemed to take much more time than expected so @thach was joining us to help speed it up (besides @hardy)

• Good news is the bridge between Incognito and Bitcoin is working well on testnet now. QA team will be proceeding to test with Binance chain next week.

• We’re also facing some issues that will need to be resolved next week too:

1. Simple payment verification (SPV) for transactions from Binance chain is mostly relying on block headers that would be relayed into Incognito chain by a relayer worker. Unfortunately, Binance chain is producing blocks too fast (~ 3 block/s) that both the relayer and Incognito chain could not manage to achieve that fast yet. Pointing to public full-nodes provided and maintained by Binance team will probably be a backup solution for the problem.

2. Re-design the way to choose custodians for redeem flow a bit in order to make it more flexible and convenient for custodians and even redeemers by increasing the opportunity for redeemers to get their public coins (btc, bnb, …) back from custodians who more likely willing to do it.

[thaibao]

Hi team

@Rocky(thach) will join us to take care of portal v2 BNB
About fullnode for Binance relaying, we can setup a strong fullnode. But tx fee is a new issue for this relaying, when we is high, relaying need to pay a high fee for relaying tx, an economic issue.

And your team also tell me about big size of Binance, it will hurt incognito db size

Thank

[thaibao]

I’m runing a node to sync data from testnet and get error nil pointer

I suggest we will review why we can not get Custodian pool state by key and change some code to make sure this is not error with nil pointer

Thanks

[duc]

Updates for the week of May 4 - May 8, 2020:

• Regarding Binance chain’s headers relaying, we decided to point to a fullnode maintained by Binance team as a solution for the issue we faced/mentioned last week. At the moment we think this is a practical and acceptable solution when Binance chain is pretty centralized and is being controlled 100% by Binance team (100% validators in Binance’s committee are being run by the team and never swap)

• The QA team still works on trustless bridge v2 testing this week. The testing report details can be found here Quality control strategy to minimize oversight for Q2 2020. There were a few bugs that mostly related to liquidation process. We’ve fixed and the fix will be deployed to testnet early next week.

• We’ve also re-designed the way to choose custodians for redeem flow that allows custodians to volunteer to return public coins (btc, bnb) to redeemers first and the system will choose more custodians if needed afterward. This will be implemented next week too.

[thaibao]

@duc

The QA team still works on trustless bridge v2 testing this week. The testing report details can be found here Quality control strategy to minimize oversight for Q2 2020 . There were a few bugs that mostly related to liquidation process. We’ve fixed and the fix will be deployed to testnet early next week.

Hi @0xkraken @hardy
Because consensus-v2 with multiview(fix block proposor) still waiting these bug to continuously deploy on testnet. Please commit that you can check these issue before 13 May so that I can deploy it. Because when deploy consensus-v2 earlier, we can make decision ealier for deploying for mainnet

cc @0xkumi and team consensus

Thanks

[Fatfaa]

So did the trustless bridge ever become deployed? If so which coins currently use this?

[0xkraken]

Hi @Fatfaa, thanks for your question.
We have deployed Incognito’s trustless bridge to Bitcoin and Binance chain with Incognito bond contract. For your information, we have been developing the trustless bridge v3 with Ethereum bond contract. Please see here for more details: Incognito's trustless bridge V3 with Ethereum bond contract

[Fatfaa]

Thanks for clarifying! We need a chart that shows what is what currently, dev team is so fast!