BCH發錯地址是如何丟幣的？

早上的時候看到某幣圈大V的微博，他說由於Bitcoin.com把Bitcoin Cash Wallet作爲默認錢包形成了用戶的丟幣。我趕忙更新了bitcoin.com錢包試用了下。

錢包的改動很簡單，就把Bitcoin Cash Wallets做爲首選，這樣就形成用戶丟幣了......
其實這事和Roger Ver真的沒有啥關係，估計該大V如今還不清楚BCH是如何丟失的吧！（該大V還宣稱數百萬的BTC所以而丟失）

第一個問題丟幣的究竟是什麼幣種？

先來看第一個問題，哪一個幣種的幣丟失了，是BTC仍是BCH。若是連這個都搞不清楚後面的問題就更難說明白了，這裏先聲明，只考慮最近出現的由於發錯地址而丟幣的狀況，不包含用戶私鑰丟失，密碼忘記等狀況。
咱們知道BCH去掉了SW交易的地址，另外還有區塊大小，動態難度調整等。在地址上和BTC是沒有區別除了SW地址之外，那麼就能夠得出一個結論包含了SW交易的BTC的地址集合是要大於BCH的地址集合的，意思就是說你在BCH上生成的地址均可以在BTC上生成而可使用。
BTC和BCH使用同一種地址編碼技術，一種可能出現的狀況是用戶會發錯地址，原本是想構建交易發送BCH到A地址的，最後發現A地址是BTC的，這種狀況下只要有對應的私鑰，不管是BTC或者BCH上面均可以生成對應的地址找回幣。
而剛剛說了BTC的地址集合是大於BCH的，也就是說若是BCH上面有私鑰的地址確定能夠在BTC上生成的，反過來卻不是。BCH上面不支持SW的地址，BTC上面生成的SW地址BCH不可以使用，丟幣問題也是和SW的地址有關。錯誤的把BCH在發送到SW地址上纔可能會出現BCH丟失的狀況。

## 第二個問題什麼樣的地址會形成丟幣？
上面已經說了把BCH打到SW地址上纔可能會出現丟幣的問題，這裏仍是要簡單作下介紹。
能夠簡單的地址分爲三類：普通地址（1開頭），多種簽名地址（3開頭），另外的就是SW地址，當前使用的SW地址都是鑲嵌在P2SH中的P2WPKH地址它也是3開頭的地址。

P2SH（bip16)是Gavin Andresen提出的一種pay to script Hash的方法，容許發送者構建更加豐富的交易類型。

P2SH的鎖定腳本例子:

OP_HASH160 86107606107baa4d1fc6711e22de7f0ef2056766 OP_EQUAL

而在贖回腳本里面，須要提供一段腳本(redeemScript)，經過的條件須要知足該腳本可執行返回true，且其hash值與後面的值相同，最終腳本相似於:

redeemScript OP_HASH160 86107606107baa4d1fc6711e22de7f0ef2056766 OP_EQUAL

咱們經常使用的多種簽名實際上是P2SH的一種方式，當前另一種使用P2SH比較多的就是SW地址。上面例子中的P2SH腳本其實就是一個SW地址的鎖定腳本。該地址在支持SW交易的BTC中能夠發送SW交易解鎖，而在BCH鏈上的只會識別成一個P2SH的地址，地址是合法的（能夠簡單認爲在BCH就認爲是一個多重簽名的地址）。
當有人把BCH發送到這種SW地址上面的時候麻煩就出現了，BCH上面不支持SW交易，沒法生成對應的解鎖腳本。
那麼把BCH誤發到SW地址上是否是就沒有辦法挽回了呢？答案是否認的。

SW交易是如何"騙"老節點的

想要找回發送到錯誤地址上的BCH，就須要明白SW交易是如何「騙」老節點的。
SW升級是一個軟分叉，也就是意味着SW交易也須要在老版本節點上驗證經過，SW交易要"騙"老節點，讓老節點在不清楚SW交易具體結構的狀況下還能夠正確驗證交易，那如何"騙"老節點呢？
簡單來講SW的地址實際上是RedeemScript（贖回腳本）的一個hash，好比咱們拿一個最簡單的sw的交易舉例：c586389e5e4b3acb9d6c8be1c19ae8ab2795397633176f5a6442a261bbdefc3a

• 該交易的輸入地址：35SegwitPieWKVHieXd97mnurNi8o6CM73

• 輸入的腳本: OP_HASH160 2928f43af18d2d60e8a843540d8086b305341339 OP_EQUAL

• WitnessScript：160014a4b4ca48de0b3fffc15404a1acdc8dbaae226955

• Witness: 30450221008604ef8f6d8afa892dee0f31259b6ce02dd70c545cfcfed8148179971876c54a022076d771d6e91bed212783c9b06e0de600fab2d518fad6f15a2b191d7fbd262a3e01

039d25ab79f41f75ceaf882411fd41fa670a4c672c23ffaf0e361a969cde0692e8

只須要分析WitnessScript便可，這部分是用來讓老版本驗證該交易是合法的，這個腳本能夠分爲兩部分

16 0014a4b4ca48de0b3fffc15404a1acdc8dbaae226955

其中16是用來壓棧的操做符，後面的數據（0014a4b4ca48de0b3fffc15404a1acdc8dbaae226955）的hash就是鎖定腳本的hash值2928f43af18d2d60e8a843540d8086b305341339，這樣把該腳本給老版本，老版本驗證該腳本確定是能夠經過的。老版本的客戶端運行的時候，該解鎖腳本能夠正確運行，老版本的客戶端是不用關心公鑰和簽名數據的。這樣就成功的"騙"了老版本的節點。

上面介紹的是SW交易如何"騙"老版本客戶端的，這和BCH用戶錯誤地發幣到SW地址又有什麼關係呢？
由於BCH客戶端和BTC老版本客戶端的驗證方式是同樣的，能夠這麼說SW交易有辦法合法地在老版本客戶端上驗證經過，固然它也能夠在BCH客戶端上驗證經過的。
這是一個btc.com幫忙找回的BCH例子https://www.blocktrail.com/BCC/address/3DutBysquuSbQxYA6EEq3m8VBQDBqa55mw/transactions
其交易詳情爲：

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

它在BCH上的解鎖腳本(用來讓老版本客戶端經過驗證的)是：2200205c4b9ef7c8896cef0d2a8fd3693d3877e0f4d1d3904fbcaf9cac1bcfb324d9b2，該交易在BTC鏈上也會動用過：https://btc.com/b25ae18255104fa8e871f5b7bcca5e30b11b67a1720555e710f36dfe6ab85397 能夠找到該解鎖腳本:

總結

若是你使用的是普通地址的交易，或者多重簽名的交易都是安全的，不會出現發送錯誤地址丟幣的狀況，不管是在BCH鏈上仍是BTC鏈上，即便你原本想發BTC的發到了BCH地址上也是能夠找回的，反之亦然。這裏的前提是你有辦法找到接受地址的私鑰。
當你把BCH發送到SW地址上時，就沒有辦法使用對應的私鑰找回幣了，若是該SW地址上的幣在BTC鏈上面動用過，發送的BCH有可能會直接被黑客盜走，只要發送過黑客就能拿到解鎖腳本，拿走該地址上的BCH，沒有BTC鏈上沒有發送過幣是安全的。
若是你不當心把BCH發送到SW地址上，首先作的是不要再作任何發幣的操做，能夠到btc.com尋求幫助，能夠找回你的BCH，若是你發送的SW地址的幣在BTC鏈上動用過的話，你的BCH就有可能會被黑客盜走。
另外BCH社區準備升級地址格式，看樣子這樣作仍是頗有意義的。

打賞地址: 16uoPajbFeKcVXdwDSuGxb7unYy1X1rMss