Public Statement from Wormhole Team

20180828

Wormhole protocol is built upon Omni layer protocol and shares the same security model. USDT, a vital infrastructure of blockchain ecosystem values around 2.7 billion dollars is also operating through Omni protocol. Lately, some rumors are spreading regarding the security of Wormhole protocol. Yet we find no real evidence. We do welcome any constructive suggestion and intend to clarify concerns about Wormhole protocol in order to stop the rumors with this statement. If there were indeed any security problems with Omni protocol (hence Wormhole protocol), USDT would be a more valuable target.

• Security

The security of Wormhole protocol is guaranteed with the following four aspects:

1. The security of BCH network and transactions
2. Traceability of Wormhole data as they are permanently stored in BCH transactions
3. The decentralized time-stamp service provided by BCH network
4. Any data failed to follow Wormhole protocol won’t be parsed by Wormhole nodes

The security model of Wormhole protocol is illustrated in the figure below:

Current BCH network has all the security features that Wormhole protocol needs. The security of Wormhole protocol does not necessarily demand the deployment of possible improvements to BCH protocol, e.g. shortened block confirmation time, pre-consensus, let alone the upper limit of the block size. We disfavor unsubstantiated rumors and welcome any kinds of inspirational discussion based on facts.

Wormhole protocol does not rely on the implementation of pre-consensus and Wormhole nodes have been operating very well since its release. The project assumes nothing related to pre-consensus. Of course, we will pay attention to modifications and improvements on BCH protocol to guarantee the synergy of Wormhole protocol.

Decreasing the inter-block time is a proposal introduced by Bitcoin Unlimited team in 2017 to improve user experience, referring to [1]. Wormhole project was not launched until June in 2018 and was officially released in August, 2018. The discussion of decreasing the inter-block time within the BCH community was way before the birth of Wormhole project.

Wormhole project aims to provide a feasible Token solution on BCH network. The early solution based on OP_GROUP proposed by Andrew Stone [6] did not receive widespread approval from BCH community. Yet, in our opinion, a Token solution for BCH network is important and urgent to BCH’s ecosystem. After extensive research of existing Token solutions, we decided to use Omni protocol, a tested and mature Token solution. Hence, Wormhole protocol was born.

There have been lots of discussions about reducing the inter-block time within the community far earlier than the research and development of Wormhole protocol. Whoever holds the opinion that reducing the inter-block time is necessary because of Wormhole project, is either ignorant or deliberately trying to confuse the public, which would only do harm to BCH community.

• Patents

Wormhole protocol is built upon Omni protocol which adopts MIT open source license. We would like to appreaciate the outstanding work of Omni team again. The implementation of Wormhole project is built upon Bitcoin ABC v0.17.2 and also adopts the same MIT open source license as Omni protocol, referring to [2].

Wormhole protocol is built on open source projects, and the solution belongs to BCH community. We have not and we will not apply for any patent related to the project. Because such behavior goes against our understanding of the spirit of the free and open source software, referring to Wikipedia [3]:

“Free and open-source software (FOSS) is software that can be classified as both free software and open-source software. That is, anyone is freely licensed to use, copy, study, and change the software in any way, and the source code is openly shared so that people are encouraged to voluntarily improve the design of the software. This is in contrast to proprietary software, where the software is under resjptrictive copyright and the source code is usually hidden from the users.”

It’s worth mentioning that the patent application is open and transparent. If Wormhole team has applied any relevant patent, there will be records which can be tracked from the Internet. It is childish and deceptive to randomly choose a patent filed in 2017 that was totally irrelevant to Wormhole protocol and spread slanders that Wormhole team had applied for such patent.

On the contrary, the token contest launched by CoinGeek contains very restrictive terms and conditions regarding to the intellectual property of the selected Token solution as revealed by dexx, a core developer of Omni layer protocol, in his article “Why we don’t participate in CoinGeek’s token contest: our commitment to all Omni users” [5]:
“The control over a solution is essentially given to nChain. Developers and participants are restricted in their ability to make public statements about the solution or the related license agreements.” We do support the spirit and actions of Omni team: “We believe free innovation and an open collaboration will advance the cryptocurrency industry as a whole”.

The open source spirit means knowledge-sharing, mutual benefit, freedom and innovation, etc. Most blockchain projects move forward under the guidance of open source spirit. Permissionless innovation and open cooperation will continue to promote the development of whole blockchain industry.

• Block Size Limit

Operations in Wormhole protocol, like token issuance, transfer, burning etc. are carried by BCH transactions. A typical transfer transaction of Wormhole protocol can be found in [4] and can be parsed following Wormhole protocol specifications as follows:

{“id”: 38,
“txDBSerialNum”: “154720”, “protocol”: “whc”, “txData”: {

“fee”: “5000”,
“txid”: “3c09372c5cc830c8a523f3d7472755babdd66b1118f347753ae793b11f9d68b8”, “type”: “Simple Send”,
“block”: 541355,
“valid”: true,
“amount”: “50.00000000”,
“ismine”: false,
“version”: 0,
“type_int”: 0,
“blockhash”: “000000000000000000fc68a45e592f417f9b4eed1c55b834030d54c04702a016”, “blocktime”: 1533029935,
“precision”: “0”,
“propertyid”: 1,
“confirmations”: 828,
“sendingaddress”: “bitcoincash:qzp3ww6whlf8659e9wx0apw8l2m5w6nfxchyajkyx5”, “positioninblock”: 34,
“referenceaddress”: “bitcoincash:qq893ghdg697e5t5anh5fqpxwxxhw3akyu9l7wej0q”

}

}

As shown above, this transaction contains three outputs: one for the target account address, one for the change address, and one OP_RETURN carrying the detailed information of WHC transaction.

No transaction fees are charged in Wormhole protocol. Users only need to pay BCH transaction fees to miners. There is extra OP_RETURN data in WHC transaction thus the size of WHC transaction will be larger than normal BCH transaction. Thus, Wormhole protocol prefers large block than small block.

To attract more users, Wormhole protocol needs to lower BCH transaction fees and enlarge BCH block size to carry more transactions within one block. Limiting the block size of BCH network has never been our intention. The proper block size should be determined by the capacity of BCH network and the real demands.

Wormhole protocol is a second-layer protocol based on BCH network. BCH network provides a solid foundation for Wormhole protocol. Thus, the throughput capacity of the underlying BCH network is critical to Wormhole protocol. Higher transaction fee caused by large-scale traffic jam in BCH network will harm the availability of Wormhole protocol. This is something we would like to avoid in every sense. Thus again, we do favor large blocks other than small blocks.

Wormhole protocol allows anyone verifiably creates their token or assets. The foundation of Wormhole protocol is BCH transaction. It is obvious that Wormhole protocol will not compete with BCH. In fact, most token use cases are related to exchanges currently. Wormhole protocol only demands that the confirmation time of WHC transactions is in accordance with the confirmation time of the underlying BCH transactions.

• Burning Address

Proof-of-Burn (PoB) mechanism is utilized in Wormhole protocol to exchange Bitcoin Cash (BCH) for Wormhole Cash (WHC). To take the BCH that are exchanged for WHC out of circulation, Wormhole team picked a special Bitcoin Cash address that no one has a corresponding private key as the burning address: qqqqqqqqqqqqqqqqqqqqqqqqqqqqqu08dsyxz98whc. The encoded 160-bit hash value in the address is: 000000000000000000000000000000000071E76C.

There are two more concerns to the selection of burning address besides the obvious restriction that on one is supposed to have any corresponding public/private key pair: the address should be fresh new and preferably featured with some characteristics unique to Wormhole protocol. Wormhole team started with the 160-bit all-zero hash value and looped upward with step-size 1 until an address ended with substring “whc” is obtained according to Bitcoin Cash’s new address encoding rule. It is worth mentioning that the native cryptocurrency, XCP, in project Counterparty is also created by PoB mechanism, referring to [8].

The leading 137-bit zeros in the hash value encoded in the burning address guarantees that Wormhole team possess no corresponding public/private key pair. The generation code of the burning address is demonstrated in GitHub repository, referring to [7]. For detailed information regarding to the validation of the burning address and the related security consideration, referring to [9].

• References

1. Bitcoin Cash development and testing accord. https://www.bitcoinunlimited.info/cash-development-plan
2. MIT license in Wormhole project. https://github.com/copernet/wormhole/blob/master/COPYING
3. Wikipedia: Free and open-source software. https://en.wikipedia.org/wiki/Free_and_open-source_software
4. Wormhole Transaction. https://bch.btc.com/3c09372c5cc830c8a523f3d7472755babdd66b1118f347753ae793b11f9d68b8
5. Why we don’t participate in CoinGeek’s token contest. https://medium.com/omnilayer/why-we-dont-participate-in-coingeek-s-token-contest-our-commitment-to-all-omni-users-28dfac5d0df0
6. Bitcoin Cash Scripting Applications: Representative Tokens (OP_GROUP) https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-representative-tokens-ece42de81285
7. Github Project genburn: Codes for Generating Wormhole’s Burn Address. https://github.com/copernet/genburn
8. Counterparty blog: Why Proof-of-Burn. https://counterparty.io/news/why-proof-of-burn/
9. On the Burning Address of Wormhole Protocol. https://medium.com/@wormholecash/on-the-burning-address-of-wormhole-protocol-3962ffa8de96