How Safe Are Today’s Wrapped BTC Bridges?

Published in

Wanchain

13 min readAug 26, 2020

The question of the security of wrapped BTC bridges has been a simmering concern throughout the DeFi community for a long time. Ethereum founder Vitalik Buterin himself highlighted the issue in a recent tweet:

The comments under his post were filled with heated debate from members representing all different corners of Crypto Twitter. Various existing mainstream bridge solutions such as those from Republic Protocol (REN) and Wanchain (WAN) were brought up.

From my research into secure cross-chain technology as part of my work at Wanchain, I have a good general understanding of various cross-chain BTC mechanisms. Lets take a look at just exactly how they work and why people use them:

The How…

The simplest and most straightforward understanding of BTC cross-chain bridges is that a user transfers “real” BTC to an address on the Bitcoin blockchain where it is locked. After this address receives the “real” BTC, it will mint a “fake” ERC20 BTC on Ethereum. This type of token is known as a mapping token or a “wrapped” token, and is freely usable as a representation of BTC on Ethereum. When going the other direction, the ERC20 BTC is burned (destroyed), and the locked BTC on Bitcoin is released. ERC20-based BTC tokens minted on Ethereum are prefixed with a symbol to indicate the protocol or organization behind the cross-chain bridge. For example, wanBTC, renBTC, sBTC, WBTC, tBTC, etc.

The general process for moving BTC from its own native Bitcoin blockchain and back again is described by this simple 2-step process.

The Why…

In essence, when minting wrapped BTC, “real” BTC is exchanged for “fake” BTC. Some might ask, why would I want to use “fake” BTC?

It comes down to technical requirements. The DeFi industry is now booming with billions of dollars flowing into lending, options, and other types of DeFi applications. The rate of its exponential increase is going faster and faster every day. However, this growth is primarily on the Ethereum blockchain. DeFi applications on Ethereum can only support ERC20 tokens, so BTC must be converted to the “fake” ERC20 version in order to be used for lending, borrowing, trading, etc. on all the latest and greatest hyped DeFi platforms out there. It is a legitimate use case. However, when wrapping BTC or other non-Ethereum assets to exist on the Ethereum blockchain, one must be especially careful about the mechanism used to wrap those assets.

What Could Go Wrong?

Now that we understand how wrapped BTC works and why people use it, let’s take a look at the potential dangers associated with this process. The fundamental danger with all wrapped BTC is the possibility that the “real” BTC on the Bitcoin blockchain could be unlocked and released to someone else, and leave token holders of the “fake” ERC20 BTC holding the bag. With the “real” BTC that that token was supposed to be used to redeem for now gone, the “fake” ERC20 BTC is now rendered worthless. The way in which this theft might happen wholly depends on the specific mechanism used for the cross-chain bridge that is used to bring BTC over to Ethereum or any other blockchain that has DeFi applications on it like Cosmos or Polkadot.

Cross-chain Bridge Types

Centralized Custodial Bridge

With a custodial bridge, the address which BTC is sent to on Bitcoin is simply the address of an organization that promises that they will mint ERC20 BTC for you on Ethereum. In this solution, the person or organization managing the bridge must be trusted to hold the real BTC and not run away with it. The most prominent example of this model is the widely used ERC20 WBTC, which is solely and entirely backed by BitGo’s guarantee.

Decentralized Smart Contract Managed Bridge

Of course, in the world of blockchain and DeFi, many prefer decentralized, non-custodial solutions. Decentralized solutions are preferred and considered “safer” as they negate the need of a trusted third party (as is the case with BitGo in the WBTC model), and rather are directly managed by immutable smart contract logic.

A few of the key technologies powering such solutions are secure multi-party computation (MPC) and the related technology of Threshold Signature Schemes (TSS).

MPC is a cryptographic technique which allows for multiple participants to perform operations on a number of inputs without any participant revealing their own input to the group.

TSS is a related cryptographic technique which allows for the MPC process to be completed as long as a certain threshold of participants join the process. For example, with 21 MPC participants and a TSS threshold of 15, as long as 15 or more of the participants join the process, the calculations will be performed successfully.

Refer to this article from Wanchain’s Noah Maizels for a deeper dive into MPC and TSS with illustrative examples (specifically the varient of TSS known as Shamir’s Secret Sharing).

MPC and TSS Applied to Cross-chain Bridges

Many of the MPC / TSS implementations used by cross-chain projects / protocols are derived from the classic paper Robust Threshold DSS Signatures by Rosario Gennaro, Stanisław Jarecki, Hugo Krawczyk and Tal Rabin published in 1996.

Unfortunately the principles described in this paper are often used directly by cross-chain projects without modification or innovation in their implementations of MPC / TSS.

Wanchain introduced its implementation of MPC / TSS in its first cross-chain bridge between BTC and Wanchain all the way back in 2017. Our implementation of it drew heavily from the 1996 Gennaro paper, while also introducing an innovative algorithm which reduces the number of interactions in the MPC calculation process.

An important concept in the application of MPC technology to cross-chain bridges is the relationship between the individual private key of each participating MPC node and the group private key of the whole node set.

The group private key is the key which is used to control the MPC-managed locked account where the BTC is held on the native Bitcoin blockchain. Any holder of this key has full control over all assets in that account.

However, no individual is ever meant to hold this key. Rather, a group of nodes work together to generate the group private key through the MPC mechanism described by Gennaro in 1996. This group private key is generated when each participating MPC node contributes their own individual private key. TSS is applied through this process to ensure that even if a few nodes are offline or deliberately choose not to participate, the process will complete as long as more than some threshold number of nodes participate. Therefore, the entire mechanism is highly fault-tolerant, and even if individual MPC nodes are malicious, it will not affect the protocol operation.

Re-grouping

While MPC allows for a group of nodes to operate a locked BTC account without any individual node holding the private key themselves, there still exists the possibility that the threshold number of MPC participants may collude to work together in order to steal the locked BTC. Node regrouping, or “churning,” is a common tactic used to reduce the possibility of node collusion. Regrouping is a technique where the nodes that comprise the MPC group that manages the locked account are periodically shuffled, so that no one same group of nodes manages the locked account for a long period of time. This shuffling makes it much more difficult for participants to identify and collude with each other.

Of course, since the group private key is derived from a combination of all participating node’s individual private keys, every time a new group is formed, a new group private key and associated locked account are necessarily generated by protocol design.

MPC & TSS in renBTC’s Cross-chain Bridge

Let’s take a look at how the increasingly popular renBTC uses MPC and TSS in their cross-chain bridge. According to their technical white paper, their approach is also based on the aforementioned Robust Threshold DSS Signatures paper.

On their website and official documentation, they emphasize that the management of cross-chain BTC accounts is done by a group of “dark nodes” using MPC and TSS (specifically, Shamir’s Secret Sharing), and the members of this group of “dark nodes” are periodically regrouped.

Paradoxically, we found that the Bitcoin address provided by renBTC that users transfer their real BTC to for locking has not changed since the first day it went online.

The process to generate renBTC is as follows. First, the user transfers BTC to a one-time address. See Figure 1 below.

Then, from that one-time address, the user sends their BTC to the locked account. See Figure 2 below.

However, that locked account has never changed. As you can see in the figure below, it is a honey pot of nearly 9,000 BTC.

According to Gennaro logic, if the account address is really generated by MPC, and the dark nodes involved in account management really churn, then the account address must also be updated periodically. That’s how MPC works.

Thus, there is a contradiction between the observed facts of the renBTC bridge implementation and the described technology in the documentation. This difference seems to indicate that the renBTC bridge does not in fact use the model as described in the technical white paper.

We thereby doubt whether the locked BTC address was in fact generated using MPC. After a review of the code on GitHub and various technical documents, we were unable to find an explanation for this apparent contradiction.

A Few Final Thoughts…

This year, especially in the last couple of months, the DeFi phenomena has grown into a massive movement. The types of applications and the total value locked in DeFi protocols has grown exponentially.

Although some may cry “bubble”, the eye watering valuations are actually being driven by truly innovative products, and not just empty promises. However, as DeFi business applications flourish, core blockchain technologies, such as secure and decentralized cross-chain technology, have kept pace. The purpose of this article is not to single out REN in particular, but rather to ignite rational discussion about issues of security within the world of cross-chain DeFi.

First, what level of compromise between the products described in a white paper and the actual implementation are acceptable?

Second, for projects such as Ren that have not yet revealed their source code, what level of detail should we demand in their documentation? Are general references to engineering approaches acceptable, or should we demand specific implementation details?

In the first ICO boom, we saw far too many projects which rose to incredibly high valuations based on a white paper and a slick story alone. The entire industry, including each of us individually, was more or less a victim.

With that collective experience in hindsight, let’s make sure not to make the same mistakes twice. Let’s cut down on the technical mumbo jumbo, exaggeration, and hand waving, and focus on building practical solutions grounded in strong theoretical principles.

Wanchain’s decentralized and trustless wanBTC is scheduled to launch on Ethereum in Q3 / Q4 of this year, and we welcome the community’s evaluation of it. We look forward to presenting more details about its implementation soon.

“You can fool all the people some of the time, and some of the people all the time, but you cannot fool all the people all the time.” — Abraham Lincoln

Authors:

Li Ni, Dr. Guo Zhongzhong

With contributions from:

Guo Wu, Noah Maizels, Nicholas Krapels

Cited Works:

[1] Rosario Gennaro and Steven Goldfeder. “Fast Multiparty Threshold ECDSA with Fast Trustless Setup”. English. In: ACM, 2018, pp. 1179–1194. isbn: 9781450356930;1450356931;

[2] Rosario Gennaro, Steven Goldfeder, and Arvind Narayanan. “ThresholdOptimal DSA/ECDSA Signatures and an Application to Bitcoin Wallet Security”. In: Applied Cryptography and Network Security. Ed. by Mark Manulis, Ahmad-Reza Sadeghi, and Steve Schneider. Cham: Springer International Publishing, 2016, pp. 156–174. isbn: 978–3–319–39555–5.

[3] Rosario Gennaro et al. “Robust Threshold DSS Signatures”. In: Advances in Cryptology — EUROCRYPT ’96. Ed. by Ueli Maurer. Berlin, Heidelberg: Springer Berlin Heidelberg, 1996, pp. 354–371. isbn: 978–3–540–68339–1.

[4] Philip MacKenzie and Michael K. Reiter. “Two-party generation of DSA signatures”. In: International Journal of Information Security 2.3 (Aug. 2004), pp. 218–239. doi: 10.1007/s10207- 004- 0041- 0. url: https://doi.org/10.1007/s10207–004–0041–0.

[5] Ivan Damg˚ard et al. “Implementing AES via an Actively/Covertly Secure Dishonest-Majority MPC Protocol”. In: Security and Cryptography for Networks. Ed. by Ivan Visconti and Roberto De Prisco. Berlin, Heidelberg: Springer Berlin Heidelberg, 2012, pp. 241–263. isbn: 978–3–642–32928–9.

[6] Ran Canetti. “Security and Composition of Multiparty Cryptographic Protocols”. In: Journal of Cryptology 13.1 (Jan. 2000), pp. 143–202. doi: 10.1007/s001459910006.

[7] Torben P. Pedersen. “Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing”. In: Proceedings of the 11th Annual International Cryptology Conference on Advances in Cryptology. CRYPTO ’91. Berlin, Heidelberg: Springer-Verlag, 1991, pp. 129–140. isbn: 3540551883.

[8] Rosario Gennaro et al. “Secure Distributed Key Generation for DiscreteLog Based Cryptosystems”. English. In: Journal of Cryptology 20.1 (2007), pp. 51–83.

[9] Adi Shamir. “How to Share a Secret”. In: Commun. ACM 22.11 (Nov. 1979), pp. 612–613. issn: 0001–0782. doi: 10.1145/359168.359176. url: https://doi.org/10.1145/359168.359176.

[10] Gilad Asharov et al. “A Full Proof of the BGW Protocol for Perfectly Secure Multiparty Computation”. English. In: Journal of Cryptology 30.1 (2017), pp. 58–151.

[11] Shafi Goldwasser, Silvio Micali, and Charles Rackoff. “The Knowledge Complexity of Interactive Proof Systems”. English. In: SIAM Journal on Computing 18.1 (1989), pp. 186–208.

[12] Silvio Micali and Phillip Rogaway. “Secure Computation”. In: Advances in Cryptology — CRYPTO ’91. Ed. by Joan Feigenbaum. Berlin, Heidelberg: Springer Berlin Heidelberg, 1992, pp. 392–404. isbn: 978–3–540–46766–3.35

[13] Donald Beaver. “Foundations of Secure Interactive Computing”. In: Advances in Cryptology — CRYPTO ’91. Ed. by Joan Feigenbaum. Berlin, Heidelberg: Springer Berlin Heidelberg, 1992, pp. 377–391. isbn: 978–3–540–46766–3.

[14] Jens Groth. “On the Size of Pairing-Based Non-interactive Arguments”. In: May 2016, pp. 305–326. isbn: 978–3–662–49895–8. doi: 10.1007/978–3–662–49896–5_11.

[15] Ethan Buchman, Jae Kwon, and Zarko Milosevic. The latest gossip on BFT consensus. 2018. arXiv: 1807.04938v3 [cs.DC].

[16] P. Feldman. “A practical scheme for non-interactive verifiable secret sharing”. In: 28th Annual Symposium on Foundations of Computer Science (sfcs 1987). Oct. 1987, pp. 427–438. doi: 10.1109/SFCS.1987.4.

[17] Lloyd R. Welch and Elwyn R. Berlekamp. Error Correction for Algebraic Block Codes. U.S. Patent 4,633,470. Dec. 1986.

[18] Shuhong Gao. “A New Algorithm for Decoding Reed-Solomon Codes”. In: Communications, Information and Network Security. Ed. by Vijay K. Bhargava et al. Boston, MA: Springer US, 2003, pp. 55–68. isbn: 978–1–4757–3789–9. doi: 10.1007/978–1–4757–3789–9_5.

[19] R. McEliece and D. Sarwate. On sharing secrets and Reed-Solomon codes. English. 1981.

[20] Manuel Cerecedo, Tsutomu Matsumoto, and Hideki Imai. “Efficient and secure multiparty generation of digital signatures based on discrete logarithms”. In: IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences 76 (Apr. 1993).

[21] Michael Ben-Or, Shafi Goldwasser, and Avi Wigderson. “Completeness Theorems for Non-Cryptographic Fault-Tolerant Distributed Computation”. In: Proceedings of the Twentieth Annual ACM Symposium on Theory of Computing. STOC ’88. Chicago, Illinois, USA: Association for Computing Machinery, 1988, pp. 1–10. isbn: 0897912640. doi: 10.1145/62212.62213. url: https://doi.org/10.1145/62212.62213.

[22] Donald Beaver. “Efficient Multiparty Protocols Using Circuit Randomization”. In: Proceedings of the 11th Annual International Cryptology Conference on Advances in Cryptology. CRYPTO ’91. Berlin, Heidelberg: Springer-Verlag, 1991, pp. 420–432. isbn: 3540551883.

[23] J. Bar-Ilan and D. Beaver. “Non-cryptographic fault-tolerant computing in constant number of rounds of interaction”. English. In: ACM, 1989, pp. 201–209. isbn: 0897913264;9780897913263;