BTC 區塊鏈原理

區塊鏈（block chain）：一種分布式資料庫技術，以區塊為單位存盤資料，區塊們以哈希鏈的形式串聯，因此防偽，

• 區塊鏈起源于位元幣（BTC），用于記錄交易資訊，每筆交易相當于 SQL 資料庫的一個事務，
• 本文主要分析位元幣協議中的區塊鏈原理（協議更新之后，一些細節可能變化），
• 參考資料：
  • bitcoin.org
  • bitcoinbook

區塊結構

• 如下圖，一條區塊鏈由多個區塊串聯組成，后一個區塊會記錄前一個區塊的哈希值，構成哈希鏈，
  

  • 哈希運算時采用 SHA256 演算法，
  • 存盤位元組流時采用小端序，
  • 每個區塊采用遞增的序號作為識別符號，又稱為區塊高度（Height），
  • 每個區塊最多允許包含 1MB 的資料，超過則視作無效區塊，

• 一個區塊在結構上分為兩部分：

  • header ：用于存盤該區塊的元資料，
  • body ：用于存盤交易資訊，

• 區塊 header 的長度固定為 80 bytes ，按順序記錄以下資訊：

  • nVersion
    • ：區塊鏈協議的版本，
    • 4 bytes ，int32_t ，
  • previous block header hash
    • ：上一個區塊的 header 的哈希值，用于確保它們不會被篡改，
    • 32 bytes ，char[32] ，
  • merkle root hash
    • ：當前區塊 body 中所有交易資訊的 Merkle Tree 的根哈希，用于確保它們不會被篡改，
    • 32 bytes ，char[32] ，
  • timestamp
    • ：礦工打包當前區塊時的 Unix time 時間戳，必須大于前 11 個區塊的平均時間戳、不大于當前實際時間 +2 小時，
    • 4 bytes ，uint32_t ，
  • nBits（target threshold）
    • ：nonce 的目標閾值，
    • 4 bytes ，uint32_t ，
  • nonce
    • ：一個亂數，
    • 4 bytes ，uint32_t ，

挖礦難度

• 礦工打包新區塊時，需要嘗試指定 nonce 值，比如窮舉，如果使得當前 header 的哈希值小于等于 target threshold ，則有權打包該區塊，被其他礦工承認，
  • SHA256 哈希值的長度為 32 bytes ，而 target threshold 以有損壓縮形式存盤為 nBits ，長度為 4 bytes ，
  • 例：根據 nBits 計算出 target threshold

    >>> nBits  = int('0x170cfecf', 16)                              # 假設 nBits 的取值
    >>> target = 256**(int('0x17', 16) - 3) * int('0x0cfecf', 16)   # 將第一個位元組作為 256 的冪，再乘以后三個位元組
    >>> '0x' + "{:064x}".format(target)
    '0x0000000000000000000cfecf0000000000000000000000000000000000000000'
    

    • 可見 nBits 第一個位元組的值越大，會使 taget 越大，開頭連續的 0 越少，因此挖礦難度越小，
• difficulty 表示挖礦難度，
  • 計算公式如下：

    diffculty = difficulty_1_target / target
    

    • 可見 difficulty 與 target 成反比，取值越小則挖礦難度越小，最小為 1 ，
  • difficulty_1_target 表示區塊鏈的初始難度，是一個常數：

    >>> difficulty_1_target = 2**(256-32)-1
    >>> '0x' + "{:064x}".format(difficulty_1_target)
    '0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff'
    >>> difficulty_1_target / target
    21659675333681.926
    

  • 當 difficulty 為 1 時，target 達到允許的最大值 ‘0x1d00FFFF’ ，因為有損壓縮丟失了右側的所有 ‘0xF’ ，所以有的程式會將 difficulty_1_target 計算成偏小的值：

    >>> _target = 256**(int('0x1d', 16) - 3) * int('0x00FFFF', 16)
    >>> '0x' + "{:064x}".format(_target)
    '0x00000000ffff0000000000000000000000000000000000000000000000000000'
    >>> _target / target
    21659344833264.848
    

    • 丟失右側 ‘0xF’ 的 difficulty_1_target 常用于快速估算難度，稱為 bdiff（Bitcoin difficulty），
    • 標準的 difficulty_1_target 常用于正式挖礦，稱為 pdiff（Pool difficulty），
  • 例：根據 nBits 估算出 difficulty

    >>> nBits      = int('0x170cfecf', 16)
    >>> difficulty = 256**(29 - (nBits >> 24))*(65535.0 / ((float)(nBits & 0xFFFFFF)))
    >>> difficulty
    21659344833264.848
    

  • BTC 預計每隔 10 分鐘生成一個新區塊，為了維持這一速率，會每隔 2016 個區塊調整一次挖礦難度，重新計算 nBits ：

    expected_time  = 2016*10    # 理論上最近 2016 個區塊應該消耗 2016*10 分鐘即 2 周
    actual_time    = ...        # 實際上最近 2016 個區塊消耗的時長
    new_difficulty = old_difficulty * ( actual_time / expected_time )
    new_nBits      = ...        # 根據 new_difficulty 算出 new_nBits
    

• 理論上，SHA256 哈希值有 2^256 種可能性，而 nonce 只有 2^32 種可能性，因此可能窮舉 nonce 的所有值之后依然不滿足 target threshold ，
  • 例如 2020 年發布的螞蟻礦機 S19 ，額定算力為 95 THash/s ，遍歷 nonce 所有值的耗時不超過 1 秒：

    >>> (2**32) / (95*10**9)
    0.045
    

  • 當 nonce 被窮舉完時，礦工通常會在 coinbase 交易中使用一個 4 bytes 的亂數，稱為 extraNonce ，從而增加到 2^64 種可能性，
  • 例如 2020 年的位元幣全網算力達到了 150 EHash/s = 150 * 10^3 PHash/s = 150 * 10^6 THash/s ，遍歷 nonce + extraNonce 消耗的秒數為：

    >>> round((2**64) / (150*10**15))
    123
    

    因此挖礦難度自動上調得很大，從而限制產生新區塊的耗時依然為 10 分鐘，礦工還需要用其它變數來增加可能性，

賬戶

• BTC 協議中，用戶可以根據 ECDSA 演算法隨機生成一對私鑰、公鑰，代表一個 BTC 賬戶，相當于一個銀行賬戶的密碼、賬戶名，

  • 示例：

    0xL3HpQs5M7tZLN1m6zmJ9YSPuFzA4gJDJy8Ru2hd5nAwcZC4tPm1T  # 私鑰
    0x1N8nCD314Z87BgYsK1y3vwRpAk8S1qbRcg                    # 公鑰
    

    • 前綴 0x 表示十六進制，
    • 私鑰需要保密，而公鑰公開給其他人，
  • BTC 采用橢圓曲線數字簽名演算法（ECDSA）對交易資料進行數字簽名，其中采用的橢圓曲線為 secp256k1 ，
    • 用戶可以撰寫一個訊息，將訊息的哈希值用私鑰加密之后公布，稱為數字簽名，其他人可使用對應的公鑰解讀數字簽名，從而驗證該訊息的內容沒有被篡改，并且是由該公鑰對應的私鑰簽署的，
  • 虛榮地址（Vanity Addresses）：雖然 BTC 私鑰、公鑰是隨機的，但用戶可以嘗試生成大量私鑰、公鑰，直到公鑰中包含有意義的單詞，比如 ILoveU ，
  • bitaddress ：一個網站，用于隨機生成 BTC 賬戶，支持離線使用，

• 生成一對私鑰、公鑰的步驟：

  1. 用戶生成一個很大的隨機整數，作為私鑰（private key），

     • 私鑰的長度為 256 bits = 32 bytes ，通常經過 Base58Check 編碼，表示成 52 位長度的十六進制數，
     • 用戶選擇私鑰時應該盡量隨機，避免與其他人相同，

  2. 根據 ECDSA 演算法，計算出私鑰在橢圓曲線上對應的一個點，其坐標 x、y 作為公鑰，

     • 通過私鑰可以計算出對應的公鑰，但不能通過公鑰反推出私鑰，而且值域龐大，使得窮舉幾乎不可能，
     • 未壓縮公鑰（uncompressed）：拼接坐標 x、y 的值，并加上前綴 0x04 用于區分，總長度為 1+32+32 = 65 bytes ，
     • 壓縮公鑰（compressed）：只采用坐標 x 的值，并加上前綴 0x02 或 0x03 表示坐標 y 為偶數或奇數，總長度為 33 bytes ，
       • 橢圓曲線關于 x 軸對稱，一個坐標 x 對應兩個 y 點，且在 secp256k1 曲線中，這兩個 y 點分別為偶數、奇數，因此需要通過前綴區分，
       • 使用壓縮公鑰時，需要給私鑰加上后綴 0x01 用于區分，其長度增加 1 位元組，
       • 壓縮格式的公鑰、私鑰更方便記錄，是用戶通常看到的格式，也是一般錢包采用的匯入格式（Wallet Import Format，WIF），
       • 錢包軟體在實際使用公鑰時，會從壓縮格式轉換成非壓縮格式，

  3. 計算壓縮公鑰的 SHA256 哈希值，再計算其結果的 RIPEMD-160 哈希值，

  4. 將公鑰哈希值（public key hash）經過 Base58Check 編碼，表示成 34 位長度的十六進制數，稱為賬戶地址（address），

• Base58Check 編碼是為了將資料表示成更短的值，并加上校驗碼，并不會加密原資料，程序如下：

  1. 輸入原資料 payload ，
  2. 在 payload 之前加上 1 位元組的地址版本號 version ，
     • P2PKH 地址的 version 為 0x00 ，因此 base58 編碼之后，開頭為 1 ，
     • P2SH 地址的 version 為 0x05 ，因此編碼之后，開頭為 3 ，
     • BTC 私鑰的 version 為 0x80 ，因此編碼之后，未壓縮格式的開頭為 5 ，壓縮格式的開頭為 K 或 L ，
  3. 對 version-payload 計算兩次哈希值，取開頭的 4 位元組作為校驗碼 checksum ，
     • 如果網路傳輸之后，再次計算兩次哈希值，發現開頭與校驗碼不一致，則說明編碼值出錯，
  4. 在 payload 末尾加上校驗碼 checksum ，將 version-payload-checksum 進行 base58 編碼，
     • 與 base64 相比，base58 的特點：
       • 移除了 +/ 兩個特殊字符，只允許使用大小寫字母、數字，
       • 移除了 0OIi 四個容易混淆的字母，

交易

• block body 中可以包含 n≥1 筆交易（transaction），最大數量取決于區塊的容量限制，

  • 包含的第一筆交易必須是 coinbase 交易，
    • coinbase 交易不存在輸入，憑空產生一定量可以輸出的 BTC ，作為打包該區塊的礦工的獎勵，
  • 其后可以包含 m≥0 筆普通交易，
    • 當交易被保存到區塊中之后，其內容就不能被改變，
    • 通常采用交易的哈希值作為其識別符號，稱為 txid ，
    • BTC 交易時，最小的單位為聰（satoshis），1 BTC = 10^8 聰，

• 一個交易主要包含以下內容：

  • version ：交易格式的版本號，占 4 bytes ，
  • in-counter ：表示輸入項的數量，
  • inputs ：包含 n≥1 個輸入項，
    • 每個輸入項的主要內容：
      • index ：輸入項在 inputs 中的序號，從 0 開始遞增，
      • previous txid ：指向輸入的 BTC 來自的之前交易，這會將該交易的 UTXO 全部輸入當前交易，
      • sigScript
  • out-counter ：表示輸出項的數量，
  • outputs ：包含 n≥1 個輸出項，
    • 每個輸出項的主要內容：
      • index
      • value ：輸出的 BTC 數量，
      • pkScript
    • 一個交易的總輸入減去總輸出的差值，會被礦作業為手續費，即 fee = sum(inputs) – sum(outputs) ，
  • locktime ：表示允許將該交易打包到區塊中的最早時間，占 4 bytes ，
    • 如果取值小于 5 億，則視作區塊高度，
    • 如果取值大于 5 億，則視作 Unix 時間戳，
    • 交易通常將 locktime 設定為 0x00000000 ，表示不限制，

• 如果一個賬戶收到了一些 BTC ，則可以發起一筆交易，輸入一些 BTC ，然后輸出給其它賬戶，

  • 所有賬戶收到的 BTC ，都來自歷史交易的輸出，且源頭都是 coinbase 交易，
  • 如果一個交易輸出的 BTC ，尚未被目標賬戶花費，則稱為未花費交易輸出（Unspent TX Output，UTXO），
    • 一個賬戶擁有的所有 UTXO ，稱為該賬戶的余額，
    • 一個交易的 UTXO 必須被一次性全部花費，例如 UTXO 為 5 BTC 時，用戶可以新建一個交易，轉賬 1 BTC 給別人，然后將剩下的 BTC 轉賬給自己，
  • 統計 BTC 區塊鏈上發生的所有交易的輸入、輸出，就可以知道所有賬戶的余額，
    • BTC 并沒有提供直接查詢賬戶余額的資料庫，但一些區塊鏈瀏覽器提供了這種查詢功能，

• 發起一個交易的程序如下：

  1. 用戶撰寫一個交易，
  2. 用戶生成交易的 sigScript ，存放在交易的 inputs 中，
  3. 用戶將交易廣播到 BTC 網路上，等待礦工將它打包入新區塊，

sigScript

：簽名腳本（Signature Script，sigScript），

• sigScript 包含以下內容：
  • pubKey ：賬戶公鑰
  • sig ：使用賬戶私鑰，生成交易資料的數字簽名，
• 交易延展性（Transaction Malleability）攻擊
  • ：一種攻擊方式，指改變未打包交易中的簽名，使得交易的哈希值改變，導致參考該交易 txid 的其它交易失效，
    • 由于橢圓曲線的對稱性，可以計算出兩個有效的簽名，還可以根據任意一個簽名推算出另一個簽名，
  • 常見的解決辦法：
    • 等待一個交易被打包，再參考它的 txid ，但這就不能實作閃電交易，
    • 規定只采用取值較小的那個簽名，
    • 使用 SegWit ，

pkScript

：公鑰腳本（Pubkey Script，pkScript），采用一種基于堆疊的腳本語言，包含一些指令，

• pkScript 可以宣告一些條件，當 sigScript 滿足條件時才能花費 UTXO ，

  • 比如 P2PKH 通常的條件是：輸出 n 個 BTC ，并指定一個公鑰，只有擁有該公鑰對應私鑰的人，才有權花費該 UTXO ，

• pkScript 又稱為鎖定腳本（locking script），因為它輸出的 BTC 一直不可用，直到有人提供滿足條件的 sigScript ，

• pkScript 的幾種型別：

  • Pay To Pubkey（P2PK）
    • ：將 BTC 轉賬給公鑰，
  • Pay To Public Key Hash（P2PKH）
    • ：將 BTC 轉賬給公鑰哈希，
    • P2PK 常用于 BTC 早期的交易，后來被 P2PKH 取代，主要原因：
      • P2PKH 使用公鑰哈希，更短，
      • P2PKH 使用公鑰哈希，隱藏了公鑰，提供了額外的安全性，直到用戶花費該賬戶時，才會提供公鑰，
  • Pay To Script Hash（P2SH）
    • ：將 BTC 轉賬給腳本哈希，
      • 如果其他人提供的 sigScript 中，包含與 P2SH 哈希一致的腳本，稱為贖回腳本（redeem script），則有權花費該 UTXO ，
    • 通過贖回腳本可實作復雜的功能，例如多重簽名、SegWit 兼容地址，
  • Pay to Witness Pubkey Hash（P2WPKH）
    • ：與 P2PKH 類似，但啟用了 SegWit ，
  • Pay to Witness Script Hash（P2WSH）
  • Null Data（空資料）
    • ：用于在 pkScript 中添加任意位元組的空資料，

隔離見證

：隔離見證，一種 BTC 的擴容方案，屬于軟分叉升級，

• 原理：給區塊附加一個稱為 witness 的結構，將交易中的見證資料（主要包含 sigScript ）移出，存放在 witness 區域，

  • 這會減小交易的一大半體積，可以在區塊中打包更多交易，
  • witness 區域的 tree 哈希記錄在 coinbase 交易中，從而嵌入 Merkle Tree ，
  • 此時的區塊稱為 SegWit 格式，基礎容量（稱為 size ）依然限制為 1MB ，附加 witness 資料時的總體積（稱為 weight ）限制為 4MB ，
  • 此時交易的哈希值稱為 wtxid ，改變 sigScript 時，不會影響 wtxid ，避免了 Transaction Malleability 攻擊，

• 使用 SegWit 時，賬戶地址有兩種格式：

  • 原生地址（Native）：采用 Bech32 編碼格式，只允許使用小寫字母、數字，長度為 42 位，開頭為 bc1 ，
  • 兼容地址（Nested）：采用 P2SH 地址，開頭為 3 ，
    • 原生地址地址的效率比兼容地址更高，
    • 傳統地址（Legacy）不支持與 SegWit 原生地址轉賬，
    • SegWit 兼容地址支持與傳統地址、SegWit 原生地址轉賬，

• SegWit 軟分叉還涉及到 BTC 社區的治理問題，相關歷史：

  • 2015 年，Bitcoin Core 開發人員提出了 BIP141 ，提議 SegWit ，是此時 BTC 變動最大的一次軟分叉升級，
  • 2016 年，Bitcoin Core 按 BIP9 方式開始 SegWit 軟分叉，但支持 SegWit 的礦工遠未達到 95% 的激活閾值，主要原因：
    • SegWit 尚未推廣，早期升級的收益較小，
    • 舊區塊可通過 AsicBoost 演算法提高挖礦的哈希算力，
    • SegWit 增加了區塊的復雜性，需要修改很多客戶端代碼，不如硬分叉簡單，
  • 2017 年 2 月，社區的開發人員提出了 BIP148 ，提議用戶激活軟分叉（User Activated Soft Fork，UASF），逼迫礦工激活 SegWit ，
    • BIP148 大意為：從 8 月開始，采用 BIP148 的節點會拒絕不支持 SegWit 的新區塊，導致發生硬分叉，
    • BIP9 讓礦工投票決定軟分叉升級，而 UASF 使得用戶也擁有了控制權，但這更像一個抗議行動，不支持的礦工只是少了打包這部分用戶交易的手續費收益，
  • 2017 年 4 月，Charlie Lee 與礦工協商之后，成功在 LTC 上激活 SegWit ，
  • 2017 年 5 月，一些公司和礦池簽署了紐約共識（New York Agreement，NYA），表示作為激活 SegWit 的交換，要求也激活 SegWit2x ，
    • 原理：與 SegWit 不同，直接將區塊的基礎容量限制從 1MB 增加到 2MB ，屬于硬分叉升級
    • SegWit2x 與 BCH 的區塊擴容類似，受到 Bitcoin Core 開發人員的反對，最終在 11 月放棄了該提議，
  • 2017 年 5 月，一個開發人員提出了 BIP91 ，使得 BIP148 與 SegWit2x 兩派可以兼容，避免發生硬分叉，
    • BIP91 的內容與 BIP148 相似，但沒有限制時間，
    • BIP91 部署之后，激活它的閾值為 80% ，當 BIP141 被激活或失敗時，BIP91 就會停止，
  • 2017 年 7 月，市場擔心 BIP148 硬分叉的風險，BTC 價格從 $2700 跌到 $2000 ，促使礦工們支持 BIP91 并激活它，
  • 2017 年 8 月，SegWit2x 終于激活，
    • 此時，大部分礦工、錢包軟體依然沒有升級 SegWit ，但是采用 SegWit 原生地址的用戶越來越多，為了服務這部分用戶，礦工、錢包軟體也會逐漸升級 SegWit ，

合約交易

多重簽名

：多重簽名（multi-signature，multisig），一種基于 P2SH 的交易方式，

• 原理：將 BTC 轉賬到一個 P2SH 地址，通過 pkScript 指定 n 個公鑰，要求 sigscript 至少用 m 個對應的私鑰簽名才有效，
  • 其中 1≤m≤n≤15 ，又稱為 m-of-n 交易，
• 1of2 是允許兩個賬戶中的任意一個都有權花費 UTXO ，
• 2of3 適合三方交易，例如 A 想花費 BTC 從 B 處購買商品，先將 BTC 轉賬到 2of3 多簽地址，
  • 如果仲裁方判斷交易成功，則與 B 一起簽名，將 BTC 轉賬給 B ，
  • 如果仲裁方判斷交易失敗，則與 A 一起簽名，將 BTC 轉賬給 A ，
  • 沒有 A 或 B 的同意，仲裁方不能私自轉走 BTC ，

閃電交易

：閃電交易（Lightning Network，LN），一種 layer2 技術，基于鏈下交易（Off-Chain），

• 官方檔案

• 原理：在區塊鏈下進行任意數量的交易，然后將這些交易的結果保存到區塊鏈，主要步驟如下：

  1. 開啟通道：兩個賬號將一筆 BTC 轉賬到一個多簽地址，暫時鎖定，稱為開啟一個閃電交易通道（channel），
  2. 使用通道：雙方建立對等連接（Peer connection），私下進行一些交易，
  3. 關閉通道：雙方根據交易結果，將多簽地址的 BTC 分配給雙方，

• 在通道中，雙方私下進行的交易只需要互相知道，不必公布到區塊鏈上，稱為承諾交易（commitment transaction），

  • 每個承諾交易，表示此時的通道狀態，即雙方應該分別擁有通道的多少 UTXO ，
  • 每創建一個新的承諾交易，就撤銷舊的承諾交易，
    • 為此雙方要交換一個承諾撤銷密鑰，證明它已撤銷，
    • 如果一方將已撤銷的承諾交易廣播到鏈上，企圖雙花攻擊，則另一方可以根據撤銷密鑰，廣播一個更新的懲罰交易（Penalty transaction），將通道的全部資產轉給自己，
  • 每個承諾交易設定了 locktime ，如果某方離線，則另一方等待 locktime 時間之后就可以將承諾交易公布到鏈上，從而關閉通道，
    • 每個承諾交易的 locktime 依次遞減，因此越新的承諾交易能越早公布到鏈上，
    • 準備關閉通道時，雙方簽署最后一筆承諾交易，立即公布到鏈上，

• 閃電交易通道只能連通兩個賬戶，但大量相互開啟通道的賬戶可以組成閃電交易網路，

  • 假設 A 與 B 之間存在通道，B 與 C 之間存在通道，則 A 可以通過 B 間接轉賬給 C ，此時 B 稱為路由節點，像計算機網路的路由轉發，
  • 哈希時間鎖定合約（Hash Time Locked Contracts，HTLC）：一種智能合約，用于保證路由節點的可信任，作業流程如下：
    1. A 創建一個密鑰 secret ，私下發送給 C ，
    2. A 在 A、B 之間的通道，使用 secret 的哈希值簽署一個 HTLC 合約，將 BTC 轉入合約，合約大意為：如果 B 能在 locktime 時間內發現 secret ，則有權獲得合約的 UTXO ，否則資金將回傳給 A ，
    3. B 在 B、C 之間的通道，也創建一個使用同樣 secret 哈希值的 HTLC 合約，請求 C 提供 secret ，但是合約鎖定的 UTXO 微少一點，因為 B 收取了手續費，locktime 也更短一點，
    4. C 提供 secret ，完成 B 的 HTLC 合約，得到 UTXO ，然后 B 再提供 secret ，完成 A 的 HTLC 合約，
       • 即使 B 下線，C 依然可以完成 B 的 HTLC 合約，只有 B 會受到損失，
  • 一些大型的路由節點可連接大量用戶，像中心化網路，
  • 一些路由節點會擔任瞭望塔（watchtower），監控網路，廣播懲罰交易，

• 優點：

  • TPS 很高
  • 手續費很低：支付給路由節點的費用很低，適合以 satoshis 為單位的小額交易，
  • 耗時短：每個交易不超過一分鐘，不需要等待區塊鏈打包、確認，
  • 隱私：只有開啟通道、關閉通道的兩次交易需要公布到鏈上，期間的交易不會上鏈，路由節點也不會知道整個交易的源頭、終點，
  • 耗費區塊空間小：通道中的交易不必保存到區塊鏈，

• 相關歷史：

  • 2017 年 5 月，LTC 區塊鏈進行了第一次閃電交易，
  • 2019 年 1 月，twitter 用戶發起了一場稱為閃電火炬（Lightning Torch）的行動，用于推廣閃電交易，
    • 規則：通過閃電交易發送一筆小額 BTC ，收到轉賬的賬戶添加 10w satoshis 之后再發送給下一個賬戶，以此類推，
    • 這筆 BTC 傳遞了將近 300 次，最終被捐贈，

CoinJoin

：一種混幣方案，

• 原理：n 個賬戶共同發起一筆 BTC 交易，分別輸入 C 數量的 BTC ，然后分別輸出 C 數量到 n 個賬戶，

  • 如果輸出賬戶與輸入賬戶都不同，則難以確定它們之間的對應關系，任一輸出賬戶受某個輸入賬戶所有人控制的概率是 1/n ，因此即使輸入賬戶暴露了現實身份，輸出賬戶也重新得到了匿名性，
  • n 的數量越大，混淆度越高，

• BTC 賬戶具有匿名性，但賬戶的交易程序、余額都是公開的，難以保護隱私，

  • 例如用戶 A 使用一個 BTC 賬戶在網上購物，轉賬記錄都是公開的，其他人可以知道他購買的所有商品，推測他的消費習慣、個人喜好，
    • 如果購物時的 IP 地址、物流資訊被泄露，賬戶就失去了匿名性，即使 A 將 BTC 轉入其它賬戶，其他人也知道新賬戶的地址，推測新賬戶很可能屬于他，

• 混幣（Coin Mixing）

  • ：指混淆多個賬戶的交易程序，使得難以確定每個賬戶的收入來自哪個賬戶、支出去向哪個賬戶，只能知道每個賬戶收入、支出的數量以及余額，
  • 常見的混幣方案：
    • 通過第三方平臺轉賬：比如將幣轉入中心化交易所，再由從交易所轉出到其它賬戶地址，但這樣需要擔心交易所的提現風險，而且交易所也能查出交易程序、記錄 KYC 資訊，
    • CoinJoin
  • 閃電交易也加強了隱私，但并不屬于混幣，而是避免交易程序上鏈，