In the morning, I saw a weibo post from a big V in the coin circle. He said that because Bitcoin.com took Bitcoin Cash Wallet as the default Wallet, users lost coins. I quickly updated my Bitcoin.com wallet to try it out.

bitcoin.com wallet

The wallet was simply changed to Bitcoin Cash Wallets as the preferred option which caused users to lose coins…… Roger Ver has nothing to do with this, so I don’t know how BCH got lost. (The big V also claims that millions of BTCS were lost.)

The first question is what kind of currency is the coin lost?

Let’s look at the first question, which currency is lost, BTC or BCH. If even this is not clear about the following question is more difficult to understand, here first declare, only consider the recent occurrence of the wrong address and lost coins, not including the loss of user private key, password forget and so on. We know that BCH has removed addresses for SW transactions, block sizes, dynamic difficulty adjustments, etc. There is no difference between BTC and BTC in terms of address except SW address, then it can be concluded that the address set of BTC containing SW transactions is larger than the address set of BCH, meaning that any address you generate on BCH can be generated and used on BTC. BTC and BCH use the same address coding technology, one possible situation is that the user will send the wrong address, originally wanted to build A transaction to send BCH to address A, and finally found that address A is BTC, in this case, as long as there is A corresponding private key, both BTC and BCH can generate the corresponding address recovery coins. The address set of BTC is greater than that of BCH, that is, if BCH has a private key on the address can be generated on BTC, but not vice versa. The BCH does not support the SW address, and the SW address generated on the BTC cannot be used. The coin loss problem is also related to the SW address. If the BCH is incorrectly sent to the SW address, the BCH may be lost.

The second question is what kind of address can cause coin loss?

It has been said above that the problem of losing coins may occur only when you dial BCH to the SW address. Here is a brief introduction. Addresses can be simply divided into three types: common addresses (starting with 1), multiple signature addresses (starting with 3), and SW addresses. Currently, SW addresses are all P2WPKH addresses embedded in P2SH, which also start with 3.

P2SH (BIP16) is a pay-to-script Hash approach proposed by Gavin Andresen that allows senders to build richer transaction types.

P2SH lock script example:

OP_HASH160 86107606107baa4d1fc6711e22de7f0ef2056766 OP_EQUAL

In the redeemScript, a redeemScript needs to be provided, and the conditions must meet that the script can return true and its hash value is the same as the following value. The final script is similar to:

redeemScript OP_HASH160 86107606107baa4d1fc6711e22de7f0ef2056766 OP_EQUAL

The multiple signatures we often use are actually a form of P2SH, and another type of P2SH that is currently used a lot is SW addresses. The P2SH script in the above example is actually a lock script for the SW address. This address in the BTC that supports SW transactions can send SW transactions to unlock, while the address on the BCH chain will only be recognized as a P2SH address, which is legal (it can simply be considered a multi-signed address in the BCH). The problem arises when someone sends a BCH to such a SW address. The BCH does not support SW transactions and cannot generate the corresponding unlock script. Is there no way to recover the BCH sent to the SW address by mistake? The answer is no.

How does SW transaction “cheat” old nodes

To retrieve a BCH sent to the wrong address, you need to understand how the SW transaction “tricked” the old node. SW upgrade is a soft fork, which means that SW transactions also need to be verified on the old nodes. SW transactions need to “trick” the old nodes into correctly verifying transactions without knowing the specific structure of SW transactions. How can “trick” the old nodes? Simply put, the address of the SW is actually a hash of a RedeemScript. For example, let’s take the simplest SW transaction: c586389e5e4b3acb9d6c8be1c19ae8ab2795397633176f5a6442a261bbdefc3a

  • Enter the address of the transaction: 35 segwitpiewkvhiexd97mnurni8o6cm73
  • Input script: 2928 f43af18d2d60e8a843540d8086b305341339 OP_HASH160 OP_EQUAL
  • A4b4ca48de0b3fffc15404a1acdc8dbaae226955 WitnessScript: 160014
  • Witness: 30450221008604ef8f6d8afa892dee0f31259b6ce02dd70c545cfcfed8148179971876c54a022076d771d6e91bed212783c9b06e0de600fab2d518fa d6f15a2b191d7fbd262a3e01 039d25ab79f41f75ceaf882411fd41fa670a4c672c23ffaf0e361a969cde0692e8

All you need to do is analyze the WitnessScript, which is being used by older versions to verify that the deal is legal. The script can be divided into two parts

16 0014a4b4ca48de0b3fffc15404a1acdc8dbaae226955

Where 16 is the operator used to press the stack, At the back of the data (0014 a4b4ca48de0b3fffc15404a1acdc8dbaae226955) the hash is the hash value 2928 f43af18d2d60e8a843540d8086b305341339 locking script, so the script to the old version, Older versions verify that the script is definitely passable. The unlock script can run correctly on an older version of the client, which does not care about the public key and signature data. This successfully “tricked” the older version of the node.

The above is about how the SW transaction “tricks” the old version client. What does this have to do with BCH users sending coins to the SW address by mistake? Since the BCH client and the old BTC client are authenticated in the same way, it can be said that the SW transaction can be authenticated legally on the old BCH client, of course it can also be authenticated on the BCH client. This is a btc.com help find BCH example www.blocktrail.com/BCC/address… The transaction details are as follows:

{... {"txid": "ac3db4411e1ce8cc76e3ebe2f7d0a538c6033fcf80484a97902eef7d6a5e34e6"."vout": 0."scriptSig": {
        "asm": "00205c4b9ef7c8896cef0d2a8fd3693d3877e0f4d1d3904fbcaf9cac1bcfb324d9b2"."hex": "2200205c4b9ef7c8896cef0d2a8fd3693d3877e0f4d1d3904fbcaf9cac1bcfb324d9b2"
      },
      "sequence": 4294967295},... }Copy the code

It on BCH unlock script (used to let the old version of the client through validation) is: 2200205 c4b9ef7c8896cef0d2a8fd3693d3877e0f4d1d3904fbcaf9cac1bcfb324d9b2, the deal will also be used in BTC chain: Btc.com/b25ae182551… You can find the unlock script:

WitnessScript

conclusion

If you use the common address transaction, or the multi-signature transaction is safe, there will be no wrong address to lose coins, whether on the BCH chain or BTC chain, even if you intended to send BTC to the BCH address can be recovered, and vice versa. The premise here is that you have a way to find the private key that accepts the address. When you put the BCH sent to SW address, there is no way to use the corresponding private key currency recover, if the currency on the SW address in BTC chain used above, BCH is likely to be sent directly by hackers stole from, as long as send a hacker can get the unlock script, take the BCH on the address, no BTC chain did not send money is safe. If you accidentally send the BCH to the SW address, the first thing to do is not to do any operation of issuing coins, you can go to BTC.com for help, you can find your BCH, if you send the SW address of the coins used in the BTC chain, your BCH may be stolen by hackers. In addition, the BCH community is going to upgrade the address format, which seems to make sense.

Exceptional address: 16 uopajbfekcvxdwdsugxb7unyy1x1rmss

16uoPajbFeKcVXdwDSuGxb7unYy1X1rMss