V God: Are the various BTCs on Ethereum reliable?

Editor's Note: This article comes fromGolden Finance, reprinted by Odaily with authorization.

Editor's Note: This article comes from

Golden Finance

Golden Finance

, reprinted by Odaily with authorization.

First of all, this topic is not a concern of the author alone. On August 17 this year, Vitalik, the founder of Ethereum, tweeted: "I am still very worried about whether these BTC mapping tokens posted on Ethereum are reliable or not?" The implication is that there are various lettered BTC tokens on Ethereum, but is it a truly "decentralized" and secure solution?

Under Vitalik's Twitter, we saw a lot of heated discussions among people in the international blockchain circle, and also mentioned various mainstream BTC cross-chain solutions, such as REN, WAN, etc. The author has been engaged in research on secure cross-chain technology at Wanchain, so I usually do some superficial research on various cross-chain BTC solutions. Here I would like to share with you some of our views.

The so-called BTC cross-chain, the simplest and most direct understanding is that a user transfers the "real" BTC from the wallet to a BTC address, and this address will give you a "fake" BTC on Ethereum after receiving the "real" BTC The mapped tokens, as shown in the flow chart below:

Let's take a look at a solution similar to the recently popular renBTC. According to its technical white paper, it is also based on the technology in the paper "Robust Threshold DSS Signatures" as its TSS solution. And in this project introduction, it is emphasized that its managed cross-chain BTC accounts are generated by a group of "dark nodes", and the members of this group of "dark nodes" must be periodically rotated. But paradoxically, we found that the BTC address provided by renBTC for users to transfer to real BTC for locking has not changed since the first day of its launch. The process is that the user first transfers BTC to a one-time address (Figure 1 below), and then the one-time address is aggregated to the locked account (Figure 2 below), and the locked account has not changed as shown in the figure below.

figure 1

figure 2

image description

figure 1

image description

figure 2

If the account address is "really" generated by MPC, and the "dark nodes" participating in account management will be rotated periodically, then the account address will also be updated periodically instead of remaining unchanged. Therefore, the propagandized technology and the implementation of the project appeared contradictory. Then why do the descriptions in technical white papers and product implementations seem to be completely different? This leads us to further thinking, is the address of this "custodial" BTC generated by MPC? If yes, how can it be explained that there has been no change? At least we found nothing from its Github code repository and various reference technical documents.

However, REN's problems go far beyond that. The ECDSA threshold signature scheme adopted by renBTC does not satisfy the theory of "threshold optimal". That is to say, after setting the threshold value t, at least 2t+1 "dark nodes" are required to participate in order to ensure smooth calculation Implementation, combined with the possible disconnection of some nodes, the number of nodes in the final implementation is 3t+1. That is to say, in this state, as long as about one-third of the nodes collude to steal cross-chain BTC, it is very dangerous. For the same reason, refer to the BFT Byzantine Fault Tolerance Protocol, which has been slightly criticized by the industry. At least two-thirds consensus, so renBTC's TSS scheme has a great risk in security.