閃電網路筆記

重要文獻：

特色活動

1. 比特幣的交易問題

  • 不適合micropayment
    • 交易速度慢 7/tps 既使segwit 擴容 也進步很少
      • 區塊大小限製 (預防中心化)
      • 挖礦/共識演算法限製 (預防分岔)
    • 手續費高
    • 無法擴展
  • 交易加速的解決方案
    • SQL #中心化
    • sidechain #要有人做出來, 有人用, 中心化
    • 交易通道

2. 多重簽名

2.1 P2MS

BIP 11 : P2MS-多重簽名

  • 提案時間：2011年10月18日
  • 實施時間：2012年1月
  • 缺點：
    • 沒有明確的 交易地址。
    • 市佔率不到 1% , 跟報廢差不多。
    • 鎖定腳本含多個public key 相當站交易空間，被鎖死最多3-of-3。
  • 變動：將Tx scriptSigs 200byte 提升為500byte ，才塞得下3個簽名。
  • 錯誤：使用解鎖腳本出現問題。
  • 鎖定腳本 m-of-n： 
      m {pubkey}...{pubkey} n OP_CHECKMULTISIG

    2 - of - 2：
    類型：資產保戶服務：

    • Key 分配：A key 為用戶自己；B key 為資產保護公司。
    • 場景：用戶 付錢的同時，需要經過 資產保護公司 同意。
    • 缺點：資產保護公司 跑路啥都沒了。

    2 - of - 3:
    類型：線上拍賣平臺：

    • Key 分配：A key 為買家；B key 為賣家；c key 仲裁第三方。
    • 場景：用戶購物時，先把錢存入2 - of - 3地址。。
    • 交易成功：買家 & 賣家簽名。
    • 交易爭議：買家 ＆ 仲裁第三方 or 賣家 ＆ 仲裁第三方。

2.2. P2SH

BIP 13 P2SH - 多重簽名地址(定義3開頭地址)

  • 實施時間：2012年4月
  • 特色：
    • Redeem script 取代 p2ms data
    • 有明確的地址
    • 複雜的部分由接收方處理
    • 使用3 開頭地址承擔交易費用
    • 存儲空間由下一個人承擔
字首 鎖定腳本 地址首字 範例地址
00 P2PKH 1 1AKDDsfTh8uY4X3ppy1m7jw1fVMBSMkzjP
05 P2SH 3 34nSkinWC9rDDJiUY438qQN1JHmGqBHGW7
6F P2PKH（測試網） m/ n ms2qxPw1Q2nTkm4eMHqe6mM7JAFqAwDhpB
C4 P2SH（測試網） 2 2MwSNRexxm3uhAKF696xq3ztdiqgMj36rJo

BIP 16 P2SH-多重簽名 (定義redeam script)

2.3. Segwit

SegWit 特色 :

  • 解決 p2pk, p2pkh, p2ms, p2sh. 交易問題 - 交易延展性問題
  • 將區塊大小改為 Weights 計算
  • 將區塊大小由 Max 1MB 擴容到 1.8MB
  • 降低 Tx 簽名 的 Weights ，使 SegWit 交易可以打將近七摺的手續費
  • 添加 wp2pkh, wp2sh 並且加入交易版本號概念，未來可以升級

BIP 141 : 對於SegWit 做出廣泛的定義
BIP 142 : 舊的SegWit 地址定義，已經被BIP 173 Bech32的地址取代
BIP 143 :

  • 添加交易版本號，到交易當中
  • 定義新的交易驗證流成: wp2pkh, wp2sh

BIP 144 : 定義執持SegWit的p2p網路
BIP 145 : 定義SegWit網路中的getblock
BIP 173 : 定義SegWit地址格式

  • Bech32解決過去p2pkh p2sh的問題：
    • Base 58 佔用 QR code 太多空間
    • 語音讀出時無法辨識大小寫
    • Double-SHA256 效能低，且沒有 錯誤檢測(error-decetion)功能
    • Base58 無法採用 錯誤檢測(error-decetion) ，因為要基於 prime-power
    • Base58 比較複雜 ，且相對較慢

3. 時間鎖

  • nLockTime：off-chain 絕對時間鎖 UNIX/block
    • 提案者：中本聰 bitcoin 0.1
    • 狀況：今年年初 nLockTime 設置為 0 僅為 20 %
  • CheckLockTimeVerify（CLTV)：on-chain 絕對時間鎖(nLockTime格式) UNIX/block
    • BIP65 - OP_CHECKLOCKTIMEVERIFY
      • new opcode：OP_CHECKLOCKTIMEVERIFY（CLTV）
      • 功能：讓資金在未來的某個時間點可以可以被某人使用
    • 場景：
      • 第三方託管｜Escrow Lenny 經過 3 個月後，Alice 或 Bob 中的一個可以用以下 OPCode 支付資金 
              IF
          <now + 3 months> CHECKLOCKTIMEVERIFY DROP
          <Lenny's pubkey> CHECKSIGVERIFY
          1
      ELSE
          2
      ENDIF
      <Alice's pubkey> <Bob's pubkey> 2 CHECKMULTISIG
      • 雙因素錢包｜非交互式定期退款｜Non-interactive time-locked refunds
        • 雙因素錢包 | Two-factor wallets 
            IF
      <service pubkey> CHECKSIGVERIFY
  ELSE
      <expiry time> CHECKLOCKTIMEVERIFY DROP
  ENDIF
  <user pubkey> CHECKSIG
        • Payment Channels = CLTV style channel
      • Trustless Payments for Publishing Data 
          IF
      HASH160 <Hash160(encryption key)> EQUALVERIFY
      <publisher pubkey> CHECKSIG
  ELSE
      <expiry time> CHECKLOCKTIMEVERIFY DROP
      <buyer pubkey> CHECKSIG
  ENDIF
      • Proving sacrifice to miners’ fees
      • 凍結資金 | Freezing Funds 
          <expiry time> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG
      • Replacing the nLockTime field entirely
    • 實現 CLTV 單嚮通道
      • 缺點：
        • 有壽命
        • 要等待退款
        • 單嚮
  • Relative locktime (RLT)(相對時間 - on chain)
    • BIP68 - Relative lock-time using consensus-enforced sequence numbers
      • 提出：nsequence 時間格式
    • BIP112 - CHECKSEQUENCEVERIFY
      • new opcode：CHECKSEQUENCEVERIFY(CSV)
      • 功能：搭配 nsequence 解鎖
      • 場景：
        • Escrow with Timeout 
            IF
      2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIG
  ELSE
      "30d" CHECKSEQUENCEVERIFY DROP
      <Alice's pubkey> CHECKSIG
  ENDIF
        • Retroactive Invalidation
        • Hash Time-Locked Contracts
        • Bidirectional Payment Channels
        • Lightning Network 
            HASH160 <revokehash> EQUAL
  IF
      <Bob's pubkey>
  ELSE
      "24h" CHECKSEQUENCEVERIFY DROP
      <Alice's pubkey>
  ENDIF
  CHECKSIG

            HASH160 <revokehash> EQUAL
  IF
      <Bob's pubkey>
  ELSE
      "2015/12/15" CHECKLOCKTIMEVERIFY DROP
      <Alice's pubkey>
  ENDIF
  CHECKSIG

            HASH160 DUP <R-HASH> EQUAL
  IF
      "24h" CHECKSEQUENCEVERIFY
      2DROP
      <Alice's pubkey>
  ELSE
      <Commit-Revocation-Hash> EQUAL
      NOTIF
          "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
      ENDIF
      <Bob's pubkey>
  ENDIF
  CHECKSIG

           HASH160 DUP <R-HASH> EQUAL
 SWAP <Commit-Revocation-Hash> EQUAL ADD
 IF
     <Alice's pubkey>
 ELSE
     "2015/10/20 10:33" CHECKLOCKTIMEVERIFY
     "24h" CHECKSEQUENCEVERIFY
     2DROP
     <Bob's pubkey>
 ENDIF
 CHECKSIG
        • 2-Way Pegged Sidechains
              IF
          lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> REORGPROOFVERIFY
      ELSE
          withdrawLockTime CHECKSEQUENCEVERIFY DROP HASH160 p2shWithdrawDest EQUAL
      ENDIF
    • BIP113
      • 功能：定義新的去中心化時間
  • Bitcoin’s Time Locks

4. 交易延展性問題

  • BIP 62(x)：提出了九種交易延展性問題 link
  • BIP 66(O): 強製執行DER編碼link
  • SegWit(O)

5. 交易通道的演進

  • 交易通道的演進 bitcoin.wiki
    1. Nakamoto high-frequency transactions(nSequence+nLockTime)

      提出日期：bitcoin 0.1 缺點: 可以串通礦工 一起決定最終版本

  1. Spillman-style payment channels

    提出日期：2013年4月20日
    提出作者：Peter Todd
    實現：BitcoinJ bitcointalk , bitcoin.org 機製：nlocktime 讓礦工無法打包交易
    詳細過程：bitcoin.wiki
    特色：

    • 單嚮支付通道
    • 特定時間到期(nSequence) 缺點：
    • 無法抵擋交易延展性攻擊
    • 資金無法原路返回
  2. CLTV-style payment channels

    提出日期：2014年10月1日
    提出：BIP 65 鎖定$到未來 (O) bip 特色：

    • 單嚮支付通道
    • 特定時間到期

    優點：

    • 抵抗Spillman-style payment channels交易延展性問題(前提依賴 新的OP_CLTV 軟分叉)
  3. Poon-Dryja payment channels 閃電網路BOLT3採用

    提出日期：2016年4月10日
    提出作者：Joseph Poon, Thaddeus Dryja[lightning.network] 論文：The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
    特色： > * 雙嚮 > * 沒有期限

  4. Decker-Wattenhofer duplex payment channels

    提出：2015年8月4日
    提出單位：Distributed Computing Group, ETH Zurich 論文：A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels

    • 依賴 BIP 68 相對時間鎖(O)
    • 由兩個單嚮(Spillman-nSequence)支付通道組成
  5. Decker-Russell-Osuntokun eltoo Channels

    提出時間：2018年5月2日
    提出作者：Christian Decker,Rusty Russell[Blockstream], Olaoluwa Osuntokun[Lightning Labs]
    論文：eltoo: A Simple Layer2 Protocol for Bitcoin

  6. Hashed Time-Locked Contracts (HTLCs)
  7. Reahing The Ground With Lightning

    論文：Reahing The Ground With Lightning

6. 輕量級節點

7. 閃電網路搭建&問題

7.1. 單嚮通道

  • 過程
    • A & B 創建一個 wp2sh-address-AB
    • A 把錢丟進去 (保證金交易（Funding Transaction）) #預防B跑路拿不到錢
    • 設定一個 nlocktime 把 A的錢 在未來的某個時間點 打款給自己
    • 開始刷新交易….天荒地老…
    • 廣播最後一筆紀錄
  • 缺點
    • 單嚮
    • 要等到nlocktime 才可以贖回

7.2. RSMC，全稱Revocable Sequence Maturity Contract

可撤銷的相對時間鎖合約 Bitcoin Lightning Network: RSMC

押金交易 - Funding Tx 承諾交易 - Commitment Tx

  • 過程
    • 生成wp2sh 地址
    • 雙方掏錢 打錢進去-保證金交易(Funding Transaction）
    • 設定退款，雙方壓多少 退多少
      • 交易結構
        • Ａ的
          • 承諾交易
          • 退款金額
        • B 的
          • 承諾交易
          • 退款金額
            • 每交易一次，四個狀態刷新，舊的狀態廢除
            • 關閉通道的 sequence 為 0
            • 要完成 承諾交易 才可以釋出 funding 交易

      • 違約 (A違約)
        • 交易結構
          • Ａ的
            • 承諾交易(O)->B1 立刻領到錢
            • 退款金額(O)->Ａ2&B1 (sequence)收錢，要等sequence 一段時間做為逞罰
          • B 的
            • 承諾交易(x)->A1
            • 退款金額(x)->Ａ1&B2 (sequence)
      • 交易結構 (逞罰機製)
        • Ａ的
          • 承諾交易->B1 立刻領到錢
          • 退款金額->Ａ2&B1 (sequence)
          • 逞罰交易 取得B1私鑰 ，拿Ａ2簽
        • B 的
          • 承諾交易->A1
          • 退款金額->Ａ1&B2 (sequence)
          • 逞罰交易 取得A1私鑰 ，拿B2簽
        • 如果 A 反悔 廣播 承諾交易->B、退款金額->Ａ(sequence)
        • B 發起 逞罰交易 會贏 因為 Ａ還要等sequence
        • 舊的交易才會有 逞罰交易（偵防塔 應該就存這些
        • 逞罰機製 私鑰天上傳無所謂
  • 特色
    • 雙嚮
    • 不需要等待贖回時間
    • 保證雙方都不作惡

7.3. HTLC 哈希時間所合約

問題

library

錢包 (在地/遠端, 全/剪裁/輕節點, 直接/網站交互)

  • 中心化錢包
  • 去中心化錢包

偵防塔 聊天 選擇性支援

  • HD wallet
  • tor lightning-onion
  • 剪裁

    9. 閃電網路狀態

  • 閃電網路瀏覽器
  • 其他
    • liquid network

Cypherpunks Core

Rusty Russell’s Coding Blog old、new

Bitmex Research

EthFans - 狀態通道

閃電網路當前的主要局限

閃電 VS 雷電：瞭望塔模式

菜鳥

其他

BitcoinMagazine

Understanding the Lightning Network

CSDN

Living a Simple Life is a Happy Life

問題

  • 閃電網路通道 是2-of-2 交易，那要收取手續費，最後一筆支出會是三個人收到錢？
  • 正義交易權力太大，為什麼可以轉走所有的錢。是否存在可以陷害人
  • 閃電網路上 實現智能合約
Written on October 10, 2020