密碼龐克 Cypherpunks Taiwan

Cypherpunks Taiwan 小聚圓滿落幕｜謝謝每一位參與這場自由技術對話的人

2025-04-01T00:00:00+00:00

3/31，我們在 Tempo House 二樓，正式啟動了 Cypherpunks Taiwan 的重啟。這是一場關於隱私、制度、自由技術與去中心化未來的對話，也是一場由社群自發發起的集體行動。我們想找回一個空間，讓關心這些議題的人可以見面、交流、共振。

🎤 感謝每一位講者，為現場帶來深刻與真誠的聲音：

Dr. Awesome Doge｜Founder @Cypherpunks Taiwan

《Revive Cypherpunk》

密碼龐克不只是簡單的技術社群，更是一場持續進行的倫理實踐運動。密碼龐克們堅信：唯有透過密碼學，我們才能在高度監控的數位社會中奪回自由與主權。這場活動讓來自各國的 Cypherpunks 齊聚一堂，交流實踐經驗，並再次強調那句核心信念——以技術為工具，以自由為核心。
Max Wu｜ Co-Founder @HackMD

《HackMD, the core of community and how it works》

HackMD 是密碼龐克精神在協作領域的實踐。透過簡潔開放的 Markdown 語言，結合 OT 與 CRDT 等底層協定，讓社群能夠自由建構知識、無需仰賴中心化的審查與控制。正如密碼龐克們用匿名網路與加密通訊對抗監控資本主義，Max 也透過工具設計，持續賦能社群，實現技術上的自主與自由。
林旅強 Richard｜ Co-Founder @開源社

《我（們）與 Cypherpunk 的距離》

Richard 在商業領域中的角色，可以被視為一種實踐密碼龐克原則的努力。Richard 善用其在戰略層面的影響力，引導技術與產品的發展方向，使其更貼近密碼龐克對「數位自主」、「抗衡監控」的核心願景。這種實踐展現了密碼龐克精神在現實世界中的另一種可能。
Neil Lee｜執行董事 @EchoX

《在監管壓力下，合規與隱私技術的平衡》

延續密碼龐克「我們不指望政府或企業給我們隱私，我們用密碼學捍衛它」的理念，Neil 正在監管與技術的灰色地帶中，探索合規框架下的隱私保護。EchoX 尋求在「透明 vs. 隱私」之間找到平衡點，讓個人財務資料仍能在法規下保持應有的自主性與防護力。
特別嘉賓：寶博士（現任立法委員） & Peter @Plan B Network

兩位的臨時對談，從政策現場聊到產業鏈結與資安隱私，精彩內容讓現場氣氛沸騰。Plan B Network 更大方贊助冷錢包，讓與會者除了思想上的收穫，還能實際帶回一份對自身資產的加密保障

🙏 活動成果

現場超過 60 人參與，從技術人、開源工作者、公職、研究者到圈外人，這場活動證明了：

關心制度與技術的人還很多，只是缺一個聚在一起的場域。

📸 講者簡報與活動照片整理中，後續將分享至社群頻道
📬 想參與下一次？歡迎加入 Telegram 群組：https://t.me/cypherpunkstw

未來展望

Cypherpunks write code — and build community.

我們不只是懷舊，而是試著定義未來的「開源社會基礎建設」。

這場聚會不是終點，而是一行剛 commit 的程式碼。

See you next round.

#CypherpunksTaiwan #Privacy #OpenSource #Web3 #Decentralization #CryptoCulture #TaiwanTechCommunity #HackMD #TONX #Tether #去中心化 #資料主權

📸 活動精選照片

Rust Bitcoin 開發入門（四）：進階應用與整合

2025-03-25T00:00:00+00:00

這是 Rust Bitcoin 開發入門系列的最後一篇。本篇探討如何構建完整的 Bitcoin 應用，包括與節點互動、錢包開發和實際部署考量。

系列文章導航：

1. 區塊鏈數據存取策略

1.1 理解不同的存取方式

要構建實際的 Bitcoin 應用，你需要與區塊鏈數據互動。有幾種主要的方式可以做到這一點，每種都有其優缺點。

Bitcoin Core RPC 是最直接的方式。你運行一個完整節點，透過 JSON-RPC 介面查詢數據。這種方式提供了最高的安全性和隱私性——你不依賴任何第三方。缺點是需要存儲完整的區塊鏈（數百 GB），且初始同步需要數天。

Electrum 協議 使用客戶端-伺服器模式。輕量級客戶端連接到 Electrum 伺服器，伺服器維護一個索引的區塊鏈數據庫。客戶端可以快速查詢地址餘額和交易歷史，而不需要下載完整區塊鏈。缺點是你需要信任伺服器提供正確的數據（除非你自己運行伺服器）。

Esplora API 是 Blockstream 開發的另一種輕量級解決方案，透過 REST API 提供區塊鏈數據。它類似於 Electrum，但使用標準的 HTTP 介面，更容易整合。

選擇哪種方式取決於你的應用需求。對於個人錢包，Electrum 或 Esplora 通常足夠。對於需要最高安全性的應用（如交易所），你應該運行自己的完整節點。

1.2 Bitcoin Core RPC

Bitcoin Core 提供了一個豐富的 JSON-RPC 介面，可以查詢區塊鏈狀態、管理錢包和廣播交易。使用 bitcoincore-rpc crate 可以方便地從 Rust 存取這個介面。

首先需要配置 Bitcoin Core 啟用 RPC：

# bitcoin.conf
server=1
rpcuser=your_username
rpcpassword=your_password
rpcport=8332  # mainnet

然後在 Rust 中連接：

use bitcoincore_rpc::{Auth, Client, RpcApi};

fn connect_to_node() -> anyhow::Result<Client> {
    let rpc = Client::new(
        "http://127.0.0.1:8332",
        Auth::UserPass("your_username".into(), "your_password".into()),
    )?;

    // 驗證連接
    let info = rpc.get_blockchain_info()?;
    println!("已連接到 Bitcoin Core");
    println!("區塊數: {}", info.blocks);
    println!("同步進度: {:.2}%", info.verification_progress * 100.0);

    Ok(rpc)
}

RPC 提供了廣泛的功能。你可以查詢區塊鏈信息、獲取特定區塊和交易、管理錢包、估算費率、廣播交易等。

fn rpc_examples(rpc: &Client) -> anyhow::Result<()> {
    // 獲取最新區塊
    let best_hash = rpc.get_best_block_hash()?;
    let block = rpc.get_block(&best_hash)?;
    println!("最新區塊包含 {} 筆交易", block.txdata.len());

    // 估算費率（6 區塊確認目標）
    let fee = rpc.estimate_smart_fee(6, None)?;
    if let Some(rate) = fee.fee_rate {
        println!("建議費率: {} sat/vB", rate.to_sat() / 1000);
    }

    // 獲取 mempool 狀態
    let mempool = rpc.get_mempool_info()?;
    println!("Mempool 中有 {} 筆待確認交易", mempool.size);

    Ok(())
}

1.3 Electrum 協議

Electrum 協議設計用於輕量級客戶端。它讓你可以快速查詢特定地址的餘額和歷史，而不需要掃描整個區塊鏈。

use electrum_client::{Client, ElectrumApi};

fn electrum_example() -> anyhow::Result<()> {
    // 連接到 Electrum 伺服器
    let client = Client::new("ssl://electrum.blockstream.info:60002")?;

    // 查詢地址餘額
    let address = Address::from_str("bc1q...")?;
    let script = address.script_pubkey();

    let balance = client.script_get_balance(&script)?;
    println!("已確認餘額: {} sat", balance.confirmed);
    println!("未確認餘額: {} sat", balance.unconfirmed);

    // 獲取交易歷史
    let history = client.script_get_history(&script)?;
    println!("共有 {} 筆相關交易", history.len());

    // 獲取未花費輸出
    let utxos = client.script_list_unspent(&script)?;
    for utxo in utxos {
        println!("UTXO: {}:{} - {} sat",
            utxo.tx_hash, utxo.tx_pos, utxo.value);
    }

    Ok(())
}

Electrum 的一個重要特性是訂閱功能。你可以訂閱特定地址的變化通知，這對於支付處理器等需要監控入帳的應用很有用。

fn monitor_address(client: &Client, script: &Script) -> anyhow::Result<()> {
    // 訂閱地址狀態變化
    let status = client.script_subscribe(script)?;
    println!("初始狀態: {:?}", status);

    // 在實際應用中，你會在後台執行緒中監聽變化
    // 當地址收到新交易時，會收到通知

    Ok(())
}

2. 使用 BDK 構建錢包

2.1 什麼是 BDK

BDK（Bitcoin Development Kit）是一個現代化的錢包開發框架。它抽象了錢包開發的複雜性，讓開發者可以專注於應用邏輯，而不是底層的區塊鏈細節。

BDK 的設計理念是基於「描述符」（descriptors）。描述符是一種標準化的方式來描述如何生成地址和花費資金。這種方法比傳統的「地址列表」方式更靈活，可以輕鬆支持各種腳本類型（P2PKH、P2WPKH、多簽等）。

BDK 的架構分為幾層：

錢包層 處理地址生成、交易構建和簽名。它不關心如何獲取區塊鏈數據或如何存儲狀態。

區塊鏈後端 提供區塊鏈數據。BDK 支持多種後端：Electrum、Esplora、Bitcoin Core RPC 等。你可以根據需求選擇。

數據庫後端 存儲錢包狀態（已知交易、UTXO 等）。BDK 支持內存數據庫、SQLite 等。

2.2 創建 BDK 錢包

讓我們從創建一個簡單的錢包開始。我們將使用助記詞生成密鑰，創建原生 SegWit（BIP84）錢包。

use bdk::{
    Wallet,
    database::MemoryDatabase,
    bitcoin::Network,
};
use bip39::Mnemonic;

fn create_wallet() -> anyhow::Result<Wallet<MemoryDatabase>> {
    // 生成新的助記詞（實際應用中應該讓用戶備份）
    let mnemonic = Mnemonic::generate(12)?;
    println!("請備份您的助記詞: {}", mnemonic);

    // 從助記詞派生主密鑰
    let seed = mnemonic.to_seed("");
    let xprv = bitcoin::bip32::Xpriv::new_master(Network::Testnet, &seed)?;

    // 創建 BIP84 描述符
    // 外部鏈（接收地址）：m/84'/1'/0'/0/*
    // 內部鏈（找零地址）：m/84'/1'/0'/1/*
    let external = format!("wpkh({}/84'/1'/0'/0/*)", xprv);
    let internal = format!("wpkh({}/84'/1'/0'/1/*)", xprv);

    // 創建錢包
    let wallet = Wallet::new(
        &external,
        Some(&internal),
        Network::Testnet,
        MemoryDatabase::default(),
    )?;

    // 生成幾個地址
    println!("\n生成的地址:");
    for i in 0..3 {
        let addr = wallet.get_address(bdk::wallet::AddressIndex::New)?;
        println!("  {}: {}", i, addr);
    }

    Ok(wallet)
}

描述符的威力在於其靈活性。你可以輕鬆創建不同類型的錢包：

// 單簽 P2WPKH（原生 SegWit）
let single_sig = "wpkh([fingerprint/84'/0'/0']xpub.../0/*)";

// 2-of-3 多簽
let multisig = "wsh(multi(2,[fp1]xpub1.../0/*,[fp2]xpub2.../0/*,[fp3]xpub3.../0/*))";

// Taproot
let taproot = "tr([fingerprint/86'/0'/0']xpub.../0/*)";

2.3 同步和查詢

創建錢包後，需要與區塊鏈同步以獲取餘額和交易歷史。

use bdk::{
    blockchain::{ElectrumBlockchain, GetHeight},
    SyncOptions,
};

fn sync_and_query(wallet: &Wallet<MemoryDatabase>) -> anyhow::Result<()> {
    // 創建區塊鏈後端
    let blockchain = ElectrumBlockchain::from(
        electrum_client::Client::new("ssl://electrum.blockstream.info:60002")?
    );

    println!("當前區塊高度: {}", blockchain.get_height()?);

    // 同步錢包
    println!("正在同步...");
    wallet.sync(&blockchain, SyncOptions::default())?;
    println!("同步完成");

    // 查詢餘額
    let balance = wallet.get_balance()?;
    println!("\n餘額:");
    println!("  已確認: {} sat", balance.confirmed);
    println!("  待確認入帳: {} sat", balance.untrusted_pending);
    println!("  待確認出帳: {} sat", balance.trusted_pending);

    // 列出 UTXO
    let utxos = wallet.list_unspent()?;
    if !utxos.is_empty() {
        println!("\nUTXO:");
        for utxo in utxos {
            println!("  {}:{} - {} sat",
                utxo.outpoint.txid,
                utxo.outpoint.vout,
                utxo.txout.value);
        }
    }

    Ok(())
}

2.4 構建和發送交易

BDK 的交易構建器提供了直觀的 API 來創建交易。它自動處理選幣、費用計算和找零。

use bdk::{SignOptions, FeeRate};
use bdk::blockchain::Blockchain;

fn send_transaction(
    wallet: &Wallet<MemoryDatabase>,
    blockchain: &ElectrumBlockchain,
    recipient: &Address,
    amount_sat: u64,
) -> anyhow::Result<Txid> {
    // 構建交易
    let mut builder = wallet.build_tx();

    builder
        // 添加接收者
        .add_recipient(recipient.script_pubkey(), amount_sat)
        // 設置費率（sat/vB）
        .fee_rate(FeeRate::from_sat_per_vb(10.0))
        // 啟用 RBF（允許稍後提高費率）
        .enable_rbf();

    // 完成構建
    let (mut psbt, tx_details) = builder.finish()?;

    println!("交易詳情:");
    println!("  發送金額: {} sat", amount_sat);
    println!("  手續費: {} sat", tx_details.fee.unwrap_or(0));

    // 簽名
    let finalized = wallet.sign(&mut psbt, SignOptions::default())?;
    if !finalized {
        anyhow::bail!("簽名未完成");
    }

    // 提取最終交易
    let tx = psbt.extract_tx();
    let txid = tx.compute_txid();

    // 廣播
    blockchain.broadcast(&tx)?;
    println!("交易已廣播: {}", txid);

    Ok(txid)
}

BDK 還支持更複雜的場景，如手動選幣：

fn advanced_transaction(wallet: &Wallet<MemoryDatabase>) -> anyhow::Result<()> {
    let mut builder = wallet.build_tx();

    // 手動選擇特定的 UTXO
    let utxos = wallet.list_unspent()?;
    if let Some(utxo) = utxos.first() {
        builder.add_utxo(utxo.outpoint)?;
    }

    // 或者使用特定的選幣策略
    // builder.coin_selection(LargestFirstCoinSelection);

    // 添加 OP_RETURN 數據
    // builder.add_data(&[1, 2, 3, 4]);

    // 設置自定義序列號（用於時間鎖）
    // builder.set_sequence(Sequence::from_height(144));

    Ok(())
}

3. 安全考量

3.1 密鑰管理

密鑰管理是 Bitcoin 應用最關鍵的安全面向。私鑰一旦洩露，資金就會永久丟失。以下是一些最佳實踐。

內存安全：敏感數據（私鑰、助記詞）在使用後應該立即從內存中清除。Rust 的 zeroize crate 提供了這個功能。

use zeroize::Zeroize;

fn secure_key_handling() {
    let mut secret = [0u8; 32];
    // ... 使用 secret ...

    // 使用完畢後清零
    secret.zeroize();
}

永遠不要記錄敏感數據：日誌中不應該出現私鑰、助記詞或其他敏感信息。這是一個常見的錯誤。

// 錯誤！不要這樣做
println!("私鑰: {}", private_key);

// 正確：只記錄非敏感信息
println!("正在處理地址: {}", address);

考慮使用硬體錢包：對於生產環境，考慮整合硬體錢包（如 Ledger 或 Trezor）。私鑰永遠不離開硬體設備，大大降低了被盜風險。

3.2 輸入驗證

永遠不要信任外部輸入。在處理用戶提供的地址或金額之前，必須驗證其有效性。

fn validate_inputs(
    address_str: &str,
    amount_sat: u64,
    network: Network,
) -> anyhow::Result<(Address, Amount)> {
    // 驗證地址格式
    let address = Address::from_str(address_str)
        .map_err(|e| anyhow::anyhow!("無效的地址格式: {}", e))?;

    // 驗證網路
    if !address.is_valid_for_network(network) {
        anyhow::bail!("地址與網路不匹配");
    }

    // 驗證金額
    if amount_sat < 546 {
        anyhow::bail!("金額低於粉塵限制");
    }

    if amount_sat > 21_000_000 * 100_000_000 {
        anyhow::bail!("金額超過 Bitcoin 總供應量");
    }

    let amount = Amount::from_sat(amount_sat);
    Ok((address.assume_checked(), amount))
}

3.3 錯誤處理

適當的錯誤處理對於安全和用戶體驗都很重要。使用結構化的錯誤類型，並確保不在錯誤消息中洩露敏感信息。

use thiserror::Error;

#[derive(Error, Debug)]
pub enum WalletError {
    #[error("餘額不足")]
    InsufficientFunds {
        required: u64,
        available: u64,
    },

    #[error("無效的接收地址")]
    InvalidAddress,

    #[error("網路連接失敗")]
    NetworkError(#[from] std::io::Error),

    #[error("交易構建失敗")]
    TransactionError(String),
}

// 在日誌中只顯示安全的信息
impl WalletError {
    pub fn safe_message(&self) -> &str {
        match self {
            Self::InsufficientFunds { .. } => "餘額不足",
            Self::InvalidAddress => "地址驗證失敗",
            Self::NetworkError(_) => "網路連接問題",
            Self::TransactionError(_) => "交易處理失敗",
        }
    }
}

4. 完整錢包應用範例

4.1 架構設計

一個生產級的錢包應用需要考慮許多面向：用戶界面、狀態管理、錯誤處理、日誌記錄等。這裡我們展示一個簡化但完整的命令列錢包。

pub struct WalletApp {
    wallet: Wallet<SqliteDatabase>,
    blockchain: ElectrumBlockchain,
    network: Network,
}

impl WalletApp {
    /// 創建新錢包
    pub fn create(
        name: &str,
        mnemonic: &str,
        passphrase: &str,
        network: Network,
        data_dir: &Path,
    ) -> anyhow::Result<Self> {
        // 驗證助記詞
        let mnemonic = Mnemonic::parse(mnemonic)?;

        // 派生密鑰
        let seed = mnemonic.to_seed(passphrase);
        let xprv = Xpriv::new_master(network, &seed)?;

        // 構建描述符
        let coin_type = if network == Network::Bitcoin { "0" } else { "1" };
        let external = format!("wpkh({}/84'/{}'/ 0'/0/*)", xprv, coin_type);
        let internal = format!("wpkh({}/84'/{}'/0'/1/*)", xprv, coin_type);

        // 創建數據庫
        let db_path = data_dir.join(format!("{}.db", name));
        let database = SqliteDatabase::new(&db_path)?;

        // 創建錢包
        let wallet = Wallet::new(&external, Some(&internal), network, database)?;

        // 連接區塊鏈
        let electrum_url = match network {
            Network::Bitcoin => "ssl://electrum.blockstream.info:60002",
            _ => "ssl://electrum.blockstream.info:60002",
        };
        let blockchain = ElectrumBlockchain::from(
            electrum_client::Client::new(electrum_url)?
        );

        Ok(Self { wallet, blockchain, network })
    }

    /// 同步錢包
    pub fn sync(&self) -> anyhow::Result<()> {
        self.wallet.sync(&self.blockchain, SyncOptions::default())?;
        Ok(())
    }

    /// 獲取餘額
    pub fn balance(&self) -> anyhow::Result<Balance> {
        let b = self.wallet.get_balance()?;
        Ok(Balance {
            confirmed: b.confirmed,
            pending: b.untrusted_pending + b.trusted_pending,
        })
    }

    /// 獲取新地址
    pub fn new_address(&self) -> anyhow::Result<Address> {
        Ok(self.wallet.get_address(AddressIndex::New)?.address)
    }

    /// 發送交易
    pub fn send(
        &self,
        recipient: &Address,
        amount: Amount,
        fee_rate: f32,
    ) -> anyhow::Result<Txid> {
        // 驗證
        if !recipient.is_valid_for_network(self.network) {
            anyhow::bail!("地址網路不匹配");
        }

        // 構建交易
        let mut builder = self.wallet.build_tx();
        builder
            .add_recipient(recipient.script_pubkey(), amount.to_sat())
            .fee_rate(FeeRate::from_sat_per_vb(fee_rate))
            .enable_rbf();

        let (mut psbt, _) = builder.finish()?;

        // 簽名
        self.wallet.sign(&mut psbt, SignOptions::default())?;

        // 廣播
        let tx = psbt.extract_tx();
        self.blockchain.broadcast(&tx)?;

        Ok(tx.compute_txid())
    }
}

pub struct Balance {
    pub confirmed: u64,
    pub pending: u64,
}

4.2 命令列介面

使用 clap crate 可以輕鬆創建命令列介面：

use clap::{Parser, Subcommand};

#[derive(Parser)]
#[command(name = "btc-wallet")]
#[command(about = "簡單的 Bitcoin 錢包")]
struct Cli {
    #[command(subcommand)]
    command: Commands,

    #[arg(long, default_value = "testnet")]
    network: String,

    #[arg(long, default_value = "~/.btc-wallet")]
    data_dir: String,
}

#[derive(Subcommand)]
enum Commands {
    /// 創建新錢包
    Create { name: String },

    /// 從助記詞恢復
    Restore { name: String },

    /// 顯示餘額
    Balance { name: String },

    /// 獲取新地址
    Address { name: String },

    /// 發送 Bitcoin
    Send {
        name: String,
        to: String,
        amount: u64,
        #[arg(default_value = "10")]
        fee_rate: f32,
    },

    /// 列出交易
    History { name: String },
}

fn main() -> anyhow::Result<()> {
    let cli = Cli::parse();

    match cli.command {
        Commands::Create { name } => {
            // 生成助記詞並創建錢包
            let mnemonic = Mnemonic::generate(12)?;
            println!("您的助記詞（請安全備份）:\n{}", mnemonic);

            let wallet = WalletApp::create(
                &name,
                &mnemonic.to_string(),
                "",
                parse_network(&cli.network)?,
                Path::new(&cli.data_dir),
            )?;

            let address = wallet.new_address()?;
            println!("\n錢包已創建");
            println!("您的第一個地址: {}", address);
        }

        Commands::Balance { name } => {
            let wallet = load_wallet(&name, &cli)?;
            wallet.sync()?;
            let balance = wallet.balance()?;
            println!("已確認: {} sat", balance.confirmed);
            println!("待確認: {} sat", balance.pending);
        }

        // ... 其他命令 ...
    }

    Ok(())
}

5. 實戰專案：支付處理器

讓我們構建一個簡單的支付處理器，展示如何將所學知識應用到實際場景。

5.1 設計

支付處理器需要：

為每筆訂單生成唯一的支付地址
監控地址的入帳
確認付款後通知商家

pub struct PaymentProcessor {
    wallet: WalletApp,
    pending_payments: HashMap<String, PaymentRequest>,
}

pub struct PaymentRequest {
    pub order_id: String,
    pub address: Address,
    pub amount: Amount,
    pub expires_at: u64,
    pub callback_url: String,
}

pub struct PaymentConfirmation {
    pub order_id: String,
    pub txid: Txid,
    pub amount: Amount,
    pub confirmations: u32,
}

5.2 創建支付請求

impl PaymentProcessor {
    pub fn create_payment(
        &mut self,
        order_id: String,
        amount: Amount,
        callback_url: String,
        ttl_seconds: u64,
    ) -> anyhow::Result<PaymentRequest> {
        // 生成新地址
        let address = self.wallet.new_address()?;

        // 計算過期時間
        let now = SystemTime::now()
            .duration_since(UNIX_EPOCH)?
            .as_secs();
        let expires_at = now + ttl_seconds;

        let request = PaymentRequest {
            order_id: order_id.clone(),
            address: address.clone(),
            amount,
            expires_at,
            callback_url,
        };

        // 存儲待處理支付
        self.pending_payments.insert(order_id, request.clone());

        Ok(request)
    }
}

5.3 監控支付

impl PaymentProcessor {
    pub async fn monitor_payments(&mut self) {
        let mut interval = tokio::time::interval(Duration::from_secs(30));

        loop {
            interval.tick().await;

            // 同步錢包
            if let Err(e) = self.wallet.sync() {
                eprintln!("同步錯誤: {}", e);
                continue;
            }

            // 檢查每個待處理支付
            let now = SystemTime::now()
                .duration_since(UNIX_EPOCH)
                .unwrap()
                .as_secs();

            let mut completed = Vec::new();
            let mut expired = Vec::new();

            for (order_id, request) in &self.pending_payments {
                // 檢查過期
                if now > request.expires_at {
                    expired.push(order_id.clone());
                    continue;
                }

                // 檢查是否收到付款
                if let Some(confirmation) = self.check_payment(request) {
                    if confirmation.confirmations >= 1 {
                        self.notify_payment(&request.callback_url, &confirmation).await;
                        completed.push(order_id.clone());
                    }
                }
            }

            // 清理已完成和過期的支付
            for id in completed {
                self.pending_payments.remove(&id);
            }
            for id in expired {
                self.pending_payments.remove(&id);
            }
        }
    }

    fn check_payment(&self, request: &PaymentRequest) -> Option<PaymentConfirmation> {
        // 查詢地址的交易
        // 檢查是否有符合金額的入帳
        // 返回確認信息
        None
    }

    async fn notify_payment(&self, url: &str, confirmation: &PaymentConfirmation) {
        // 發送 HTTP 回調通知商家
    }
}

6. 測試策略

6.1 單元測試

單元測試應該覆蓋所有核心邏輯，不依賴外部服務。

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_address_generation() {
        let mnemonic = "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about";
        // 這是一個已知的測試助記詞，可以驗證派生結果

        let seed = Mnemonic::parse(mnemonic).unwrap().to_seed("");
        let xprv = Xpriv::new_master(Network::Testnet, &seed).unwrap();

        // 驗證派生的地址符合預期
    }

    #[test]
    fn test_amount_validation() {
        // 有效金額
        assert!(validate_amount(1000, 546, 1_000_000).is_ok());

        // 低於粉塵限制
        assert!(validate_amount(100, 546, 1_000_000).is_err());

        // 超過上限
        assert!(validate_amount(10_000_000, 546, 1_000_000).is_err());
    }
}

6.2 Regtest 整合測試

對於需要實際區塊鏈互動的測試，使用 regtest 網路。Regtest 是一個本地測試網路，你可以隨時生成區塊，非常適合測試。

# 啟動 regtest 節點
bitcoind -regtest -daemon

# 生成區塊
bitcoin-cli -regtest generatetoaddress 101 

#[cfg(test)]
mod integration_tests {
    #[test]
    #[ignore]  // 需要 regtest 環境
    fn test_full_transaction_flow() {
        // 1. 連接到 regtest 節點
        // 2. 生成一些區塊以獲得可花費的 UTXO
        // 3. 創建並發送交易
        // 4. 生成區塊確認交易
        // 5. 驗證結果
    }
}

7. 總結

本系列帶你從零開始學習使用 Rust 開發 Bitcoin 應用。我們涵蓋了：

第一篇：Rust 環境設置、rust-bitcoin 基礎類型、密碼學原語

第二篇：HD 錢包、地址生成、UTXO 模型、交易構建

第三篇：Bitcoin Script、多簽、ECDSA 和 Schnorr 簽名、Miniscript

第四篇：節點互動、BDK 錢包開發、安全最佳實踐

進一步學習

掌握了這些基礎後，你可以繼續探索：

Taproot 深入：MAST、腳本樹、MuSig2
閃電網路：使用 LDK（Lightning Development Kit）
隱私技術：CoinJoin、PayJoin、Silent Payments
Layer 2：狀態通道、Rollups

Bitcoin 是一個不斷發展的生態系統。保持學習，關注 BIP 提案和社區討論，你會發現這個領域有無限的可能性。

參考資源

官方文檔

學習資源

社群

恭喜完成 Rust Bitcoin 開發入門系列！你現在有了構建 Bitcoin 應用的堅實基礎。實踐是最好的學習方式——開始構建你的第一個專案吧！

Cypherpunks Taiwan 重啟：我們為何再次聚集？

2025-03-24T00:00:00+00:00

從 2019 到現在，世界與網路都變了很多，但我們對隱私的渴望沒有改變。在數位身份、鏈上足跡與 AI 大模型全面滲透的時代，Cypherpunks 的核心信念——Privacy is necessary for an open society in the electronic age，從未如此重要。這些年來，我們見證了[比特幣](/tags/bitcoin)的主流化、Web3 的爆炸成長，也見證了過度中心化平台對個人自由與資訊掌控權的反撲。是時候重新聚集了。

為什麼重啟 Cypherpunks Taiwan？

Cypherpunks Taiwan 並不是為了「追逐熱點」，我們想建立的，是一個屬於台灣技術社群的節點——一個可以討論[密碼學](/tags/cryptography)、隱私工具、抗審查機制、去中心化協議的地方，一個能吸引真正關心自由與技術的你加入的社群。

這一次，我們的目標不只是討論技術，更希望拓展邊界、吸引對抗中心化壓力的潛在同盟者，不論你是否來自[區塊鏈](/tags/blockchain)產業，只要你在思考如何用科技解決問題、保護自由，那你就是我們想認識的對象。

我們想討論的，是這些問題：

在現代網路架構下，隱私還有多少選項？
去中心化的理想，如何與現實世界的運營模式協作？
面對鏈上永久紀錄與實名制風潮，我們還能怎麼設計新的技術解法？
「做自由的工具」與「成為主流產品」之間，有沒有第三條路？

與我們一起分享這些問題的講者們

Dr. Awesome Doge | Founder @Cypherpunks Taiwan

Cypherpunks Taiwan 創辦人，自 2014 年開始投身比特幣與加密貨幣領域，早期即深度參與去中心化技術的推廣與社群建設。身為全球最大中文加密社群「比特幣中文社團」的共同創辦人之一，成功凝聚來自全球華語圈的愛好者與開發者，截至目前社團成員已超過 16.9 萬人，成為華語世界最具影響力、最活躍的加密社群之一

Max Wu｜Co-Founder @ HackMD

HackMD 共同創辦人暨 CEO，在網路產業與開源社群擁有豐富經驗。HackMD 是一個協作式 Markdown 編輯器，促進團隊與個人之間的知識共享，最近推出的文件夾功能更進一步提升了使用者體驗。

🔗 延伸閱讀

林旅強（Richard Lin）｜Co-Founder @ 開源社

資深開源推動者，曾任 COSCUP 志工，並於中研院自由軟體鑄造場深耕多年。2014 年聯合創辦中國開源社，後任職華為近八年專注開源與開發者生態建設，現為 01.AI（創辦人李開復）開源暨開發者關係負責人。

李佳憲（Neil Lee）｜執行董事 @ EchoX

LeadBest Consulting Group 共同創辦人與前執行長，長期推動數位轉型、Web3 發展與開源創新。過去曾創辦時間軸科技、協助建立 friDay 購物等平台，並活躍於敏捷文化與去中心化應用的落地實踐。

🔗 延伸閱讀

邀請你加入：#Cypherpunks 小聚 — Make Privacy Great Again

我們將在 Tempo House 辦一場開放的技術小聚，邀請過去在台灣推動開源、去中心化與隱私技術的講者現身分享，也會安排足夠的交流時間，讓我們彼此認識、重新建立這個社群的連結。

活動資訊

📅 時間：3 月 31 日（一）18:00 - 22:30
📍 地點：Tempo House 二樓（台北市中山區建國北路二段 12 號）
🔗 報名：活動報名連結

我們相信，Cypherpunks write code——但更重要的是，他們也聚在一起，互相認識，互相支持。

這場重啟，會是我們的第一步。等你來。

Rust Bitcoin 開發入門（三）：腳本與簽名

2025-03-24T00:00:00+00:00

這是 Rust Bitcoin 開發入門系列的第三篇。本篇深入探討 Bitcoin Script 編程和各種簽名機制的 Rust 實現。

系列文章導航：

1. 理解 Bitcoin Script

1.1 什麼是 Bitcoin Script

Bitcoin Script 是 Bitcoin 的程式語言，用於定義資金的花費條件。每一筆 Bitcoin 輸出都被一個腳本「鎖定」，而花費這筆輸出需要提供一個能夠「解鎖」它的腳本。

Script 的設計有幾個重要特點。首先，它是基於堆疊（stack）的語言，類似於 Forth。操作數被推入堆疊，操作碼則從堆疊中取出操作數並將結果推回。其次，它故意不是圖靈完備的——沒有循環結構，執行時間是可預測的。這確保了節點可以快速驗證交易，不會被惡意的無限循環攻擊。

理解 Script 對於 Bitcoin 開發很重要，因為它是所有智能合約功能的基礎。從簡單的單簽名支付到複雜的多重簽名、時間鎖和條件支付，都是透過 Script 實現的。

1.2 腳本執行模型

當驗證一筆交易時，節點會執行以下過程：

將花費者提供的解鎖腳本（scriptSig 或 witness）執行，結果留在堆疊上
然後執行被花費輸出的鎖定腳本（scriptPubKey）
如果執行完成後堆疊頂部是「真」（非零值），且沒有發生錯誤，則驗證通過

這種「先解鎖，後驗證」的模型讓花費者可以提供滿足條件的數據（如簽名），然後由鎖定腳本驗證這些數據是否正確。

use bitcoin::script::{Script, ScriptBuf, Builder};
use bitcoin::opcodes::all::*;

fn script_execution_demo() {
    // P2PKH 的鎖定腳本：
    // OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG

    // 執行過程：
    // 1. 解鎖腳本推入： 
    // 2. OP_DUP：複製堆疊頂部的 pubkey
    // 3. OP_HASH160：對複製的 pubkey 計算 hash
    // 4. 推入 pubkey_hash
    // 5. OP_EQUALVERIFY：比較兩個 hash，不相等則失敗
    // 6. OP_CHECKSIG：使用 signature 和 pubkey 驗證簽名
}

1.3 使用 Rust 構建腳本

rust-bitcoin 提供了多種構建腳本的方式。Builder 類型讓你可以逐步添加操作碼和數據：

use bitcoin::script::{Script, ScriptBuf, Builder};
use bitcoin::opcodes::all::*;

fn build_scripts() -> anyhow::Result<()> {
    // 使用 Builder 構建 P2PKH 腳本
    let pubkey_hash = hex::decode("89abcdefabbaabbaabbaabbaabbaabbaabbaabba")?;

    let p2pkh_script = Builder::new()
        .push_opcode(OP_DUP)
        .push_opcode(OP_HASH160)
        .push_slice(&pubkey_hash)
        .push_opcode(OP_EQUALVERIFY)
        .push_opcode(OP_CHECKSIG)
        .into_script();

    println!("Script: {}", p2pkh_script);
    println!("ASM: {}", p2pkh_script.to_asm_string());

    // 也可以使用便捷函數
    let pubkey_hash = bitcoin::PubkeyHash::from_str(
        "89abcdefabbaabbaabbaabbaabbaabbaabbaabba"
    )?;
    let p2pkh_shortcut = ScriptBuf::new_p2pkh(&pubkey_hash);

    // 兩種方式產生相同的腳本
    assert_eq!(p2pkh_script, p2pkh_shortcut);

    Ok(())
}

你也可以解析腳本來檢查其結構：

fn parse_script(script: &Script) {
    for instruction in script.instructions() {
        match instruction {
            Ok(bitcoin::script::Instruction::Op(op)) => {
                println!("操作碼: {:?}", op);
            }
            Ok(bitcoin::script::Instruction::PushBytes(data)) => {
                println!("數據: {}", hex::encode(data.as_bytes()));
            }
            Err(e) => println!("解析錯誤: {}", e),
        }
    }
}

2. 標準腳本類型

2.1 P2PK 和 P2PKH

P2PK（Pay-to-Public-Key）是最早的腳本類型，直接將公鑰嵌入腳本中。解鎖只需要提供簽名。這種格式現在已經不常用，因為它暴露了公鑰，而且腳本較長。

P2PKH（Pay-to-Public-Key-Hash）改進了這個設計，只在腳本中存儲公鑰的雜湊值。解鎖時需要同時提供公鑰和簽名。這有兩個好處：腳本更短，而且在資金被花費之前，公鑰不會暴露。

fn standard_scripts(pubkey: &PublicKey) -> anyhow::Result<()> {
    // P2PK： OP_CHECKSIG
    let p2pk = Builder::new()
        .push_key(pubkey)
        .push_opcode(OP_CHECKSIG)
        .into_script();

    // P2PKH：OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG
    let p2pkh = ScriptBuf::new_p2pkh(&pubkey.pubkey_hash());

    println!("P2PK 大小: {} bytes", p2pk.len());
    println!("P2PKH 大小: {} bytes", p2pkh.len());
    // P2PKH 較短，因為 pubkey_hash 只有 20 bytes，而公鑰有 33 bytes

    Ok(())
}

2.2 P2SH

P2SH（Pay-to-Script-Hash）是一個強大的抽象，允許支付到任意腳本的雜湊值。發送者不需要知道腳本的內容——他們只需支付到一個以 3 開頭的地址。只有在花費時，完整的腳本才會被揭示。

這種設計有幾個優點。首先，複雜的腳本（如多重簽名）可以用短小的地址表示，減少發送者的負擔。其次，腳本的複雜性成本由花費者承擔，而不是發送者。第三，它為腳本升級提供了靈活性——只要雜湊值相同，底層腳本可以改變。

fn p2sh_demo(inner_script: &Script) {
    // P2SH：OP_HASH160  OP_EQUAL
    let p2sh = ScriptBuf::new_p2sh(&inner_script.script_hash());

    // 解鎖 P2SH 需要：
    // 1. 滿足內部腳本的數據
    // 2. 內部腳本本身

    // 例如，對於包裝的 P2PKH：
    // scriptSig:   
}

2.3 SegWit 腳本（P2WPKH 和 P2WSH）

SegWit（Segregated Witness）升級引入了新的腳本類型，將簽名數據移到交易的「見證」部分。這解決了交易可延展性問題，並降低了費用。

P2WPKH 是 P2PKH 的 SegWit 版本。鎖定腳本非常簡短：OP_0 <20-byte-pubkey-hash>。OP_0 表示見證版本 0。解鎖數據（簽名和公鑰）放在 witness 欄位中。

P2WSH 是 P2SH 的 SegWit 版本，使用 32-byte 的腳本雜湊：OP_0 <32-byte-script-hash>。

fn segwit_scripts(pubkey: &PublicKey) -> anyhow::Result<()> {
    // P2WPKH
    let wpkh = pubkey.wpubkey_hash()?;
    let p2wpkh = ScriptBuf::new_p2wpkh(&wpkh);

    // P2WSH（包裝多簽腳本）
    let multisig_script = create_multisig_script(2, &[pubkey1, pubkey2, pubkey3]);
    let wsh = multisig_script.wscript_hash();
    let p2wsh = ScriptBuf::new_p2wsh(&wsh);

    // SegWit 腳本的特點是非常簡短
    // 複雜度在 witness 中，費用較低

    Ok(())
}

2.4 Taproot（P2TR）

Taproot 是 Bitcoin 腳本能力的最新重大升級。P2TR 腳本的格式是 OP_1 <32-byte-tweaked-pubkey>，其中 OP_1 表示見證版本 1。

Taproot 的核心創新是「tweaked key」。輸出公鑰是內部公鑰加上一個調整值（tweak），這個調整值可以承諾（commit）到一棵腳本樹。這意味著：

如果所有參與者同意，可以使用密鑰路徑（key path）花費——只需一個簽名
如果需要使用特定條件，可以使用腳本路徑（script path）——揭示並執行該腳本
未使用的腳本永遠不會暴露，保護了隱私

fn taproot_scripts(secp: &Secp256k1<secp256k1::All>) -> anyhow::Result<()> {
    let internal_key = XOnlyPublicKey::from_str("...")?;

    // 簡單的 P2TR（無腳本樹）
    let p2tr = ScriptBuf::new_p2tr(secp, internal_key, None);

    // 帶腳本樹的 P2TR
    let script_a = Builder::new()
        .push_x_only_key(&internal_key)
        .push_opcode(OP_CHECKSIG)
        .into_script();

    let taproot = TaprootBuilder::new()
        .add_leaf(0, script_a)?
        .finalize(secp, internal_key)?;

    let tweaked_key = taproot.output_key();
    let p2tr_with_scripts = ScriptBuf::new_p2tr_tweaked(tweaked_key);

    Ok(())
}

3. 多重簽名

3.1 理解多重簽名

多重簽名（multisig）是 Bitcoin 最重要的腳本功能之一，要求多個密鑰中的一部分來授權交易。常見的配置包括 2-of-3（三個密鑰中任意兩個）和 3-of-5。

多重簽名有許多應用場景。對於個人用戶，它提供了備份和安全性——即使丟失一個密鑰，資金仍然可以取回；即使一個密鑰被盜，攻擊者也無法單獨花費資金。對於組織，它實現了共同控制——需要多人同意才能移動資金。

傳統的多簽使用 OP_CHECKMULTISIG 操作碼，但這有一些缺點：公鑰數量和門檻在腳本中可見，費用隨公鑰數量線性增加。Taproot 時代的多簽有更好的選擇，我們稍後會討論。

3.2 構建傳統多簽腳本

fn create_multisig_script(m: u8, pubkeys: &[PublicKey]) -> ScriptBuf {
    let n = pubkeys.len() as u8;
    assert!(m <= n && n <= 20, "無效的 M-of-N 參數");

    let mut builder = Builder::new().push_int(m as i64);

    for pubkey in pubkeys {
        builder = builder.push_key(pubkey);
    }

    builder
        .push_int(n as i64)
        .push_opcode(OP_CHECKMULTISIG)
        .into_script()
}

fn multisig_demo() -> anyhow::Result<()> {
    // 創建三個公鑰
    let pubkeys: Vec<PublicKey> = vec![
        PublicKey::from_str("02...")?,
        PublicKey::from_str("02...")?,
        PublicKey::from_str("02...")?,
    ];

    // 2-of-3 多簽
    let multisig = create_multisig_script(2, &pubkeys);

    // 通常包裝在 P2WSH 中以節省費用
    let p2wsh = ScriptBuf::new_p2wsh(&multisig.wscript_hash());

    println!("多簽腳本: {}", multisig);
    println!("P2WSH 腳本: {}", p2wsh);

    Ok(())
}

3.3 花費多簽

花費多簽交易需要提供足夠數量的有效簽名。對於傳統的 OP_CHECKMULTISIG，還需要注意一個著名的 bug：操作碼會額外消耗一個堆疊元素（通常使用 OP_0 佔位）。

fn spend_multisig(
    tx: &mut Transaction,
    input_index: usize,
    multisig_script: &Script,
    signatures: Vec<Vec<u8>>,
) {
    // 傳統多簽的解鎖腳本：
    // OP_0   ... 

    let mut witness = Witness::new();

    // OP_0（CHECKMULTISIG bug 的佔位符）
    witness.push(&[]);

    // 添加簽名
    for sig in signatures {
        witness.push(&sig);
    }

    // 對於 P2WSH，需要添加腳本
    witness.push(multisig_script.as_bytes());

    tx.input[input_index].witness = witness;
}

4. 簽名機制詳解

4.1 ECDSA 簽名

ECDSA（Elliptic Curve Digital Signature Algorithm）是 Bitcoin 最初使用的簽名演算法。簽名過程包括：

計算要簽名的消息（交易數據的特定哈希）
使用私鑰和隨機數生成簽名
簽名由兩個數值 (r, s) 組成，以 DER 格式編碼

簽名哈希（sighash）的計算方式取決於腳本類型。傳統腳本使用原始的 sighash 演算法，而 SegWit 使用 BIP143 定義的新演算法，後者包含了被花費 UTXO 的金額，防止了某些類型的攻擊。

use bitcoin::sighash::{SighashCache, EcdsaSighashType};

fn ecdsa_signing(
    tx: &Transaction,
    input_index: usize,
    utxo_script: &Script,
    utxo_amount: Amount,
    private_key: &PrivateKey,
) -> anyhow::Result<Vec<u8>> {
    let secp = Secp256k1::new();
    let public_key = private_key.public_key(&secp);

    // 對於 P2WPKH，scriptCode 是對應的 P2PKH 腳本
    let script_code = ScriptBuf::new_p2pkh(&public_key.pubkey_hash());

    // 計算 BIP143 sighash
    let mut sighash_cache = SighashCache::new(tx);
    let sighash = sighash_cache.p2wpkh_signature_hash(
        input_index,
        &script_code,
        utxo_amount,
        EcdsaSighashType::All,
    )?;

    // 創建簽名
    let message = Message::from_digest_slice(sighash.as_byte_array())?;
    let signature = secp.sign_ecdsa(&message, &private_key.inner);

    // DER 編碼 + sighash type
    let mut sig_bytes = signature.serialize_der().to_vec();
    sig_bytes.push(EcdsaSighashType::All.to_u32() as u8);

    Ok(sig_bytes)
}

4.2 Sighash 類型

Sighash 類型控制簽名涵蓋交易的哪些部分，提供了靈活的簽名選項：

SIGHASH_ALL（0x01）：最常見，簽名涵蓋所有輸入和輸出。任何改變都會使簽名無效。

SIGHASH_NONE（0x02）：只簽名輸入，不簽輸出。簽名者同意花費這些輸入，但不關心資金去向。這很危險，因為任何人都可以修改輸出。

SIGHASH_SINGLE（0x03）：簽名所有輸入和同一索引的輸出。用於某些特殊的多方協議。

ANYONECANPAY（0x80）：可以與上述任何類型組合。只簽名當前輸入，允許其他人添加更多輸入。這可以用於眾籌——多人可以各自添加輸入到同一筆交易。

fn sighash_types_demo() {
    // 不同 sighash 類型的用例

    // ALL：標準支付
    // "我同意花費這些輸入，將資金發送到這些輸出"

    // NONE：簽名授權
    // "我授權花費這些輸入，任何人可以決定去向"

    // SINGLE：交換
    // "我願意用我的輸入換取這個特定的輸出"

    // ALL|ANYONECANPAY：眾籌
    // "如果達成這個輸出，我願意貢獻我的輸入"
}

4.3 Schnorr 簽名

Taproot 引入了 Schnorr 簽名（BIP340），它比 ECDSA 有多個優點：

更小的簽名：64 bytes，而 ECDSA 是 71-72 bytes。

線性性：多個簽名可以聚合成一個。這意味著 n-of-n 多簽可以表現得像單簽，大大提高隱私和效率。

批量驗證：多個簽名可以同時驗證，比逐個驗證更快。

更簡單的安全證明：Schnorr 的數學結構更簡潔。

use bitcoin::secp256k1::{Keypair, XOnlyPublicKey};

fn schnorr_signing(
    tx: &Transaction,
    input_index: usize,
    prevouts: &[TxOut],
    keypair: &Keypair,
) -> anyhow::Result<Vec<u8>> {
    let secp = Secp256k1::new();

    // 計算 Taproot sighash
    let prevouts = Prevouts::All(prevouts);
    let mut sighash_cache = SighashCache::new(tx);
    let sighash = sighash_cache.taproot_key_spend_signature_hash(
        input_index,
        &prevouts,
        TapSighashType::Default,
    )?;

    // Schnorr 簽名
    let msg = Message::from_digest_slice(sighash.as_byte_array())?;
    let signature = secp.sign_schnorr(&msg, keypair);

    // Schnorr 簽名固定 64 bytes
    Ok(signature.as_ref().to_vec())
}

4.4 Taproot 簽名的兩種路徑

Taproot 交易可以通過兩種方式花費：

密鑰路徑（Key Path）：如果你控制內部密鑰（或聚合密鑰），只需提供一個 Schnorr 簽名。這是最有效率的方式，witness 只包含一個 64-byte 簽名。

腳本路徑（Script Path）：揭示並執行腳本樹中的一個腳本。witness 包含：

滿足腳本的數據（如簽名）
腳本本身
Control block（包含內部公鑰和 Merkle 證明）

fn taproot_spending_demo() {
    // Key path spending
    // witness: [schnorr_signature]
    // 最簡潔，64 bytes

    // Script path spending
    // witness: [script_args...] [script] [control_block]
    // 較大，但允許複雜條件
}

5. Miniscript

5.1 為什麼需要 Miniscript

直接編寫 Bitcoin Script 是容易出錯的。腳本可能看起來正確但有微妙的 bug——例如，忘記了 OP_CHECKMULTISIG 的佔位 bug，或者條件分支不完整。更糟糕的是，很難分析一個腳本的所有可能花費方式。

Miniscript 解決了這些問題。它是 Bitcoin Script 的一個子集，具有以下特點：

可組合性：你可以安全地組合不同的條件，而不用擔心它們之間的交互。

可分析性：給定一個 Miniscript，你可以自動分析：所有可能的花費方式、每種方式的 witness 大小、涉及的公鑰和時間鎖。

編譯優化：從高階策略語言編譯為最優的 Script。

5.2 策略語言

Miniscript 使用一種簡潔的策略語言來描述花費條件：

pk(KEY) - 需要 KEY 的簽名
older(N) - 相對時間鎖，N 個區塊後
after(N) - 絕對時間鎖
sha256(H) - 需要 SHA256 原像
and(A, B) - 需要 A 和 B 同時滿足
or(A, B) - A 或 B 其中之一
thresh(k, A, B, C...) - k-of-n 條件

例如，or(pk(Alice), and(pk(Bob), older(144))) 表示：Alice 可以立即花費，或者 Bob 在 144 個區塊（約 1 天）後可以花費。

use miniscript::policy::Concrete;
use miniscript::Segwitv0;

fn miniscript_demo() -> anyhow::Result<()> {
    let alice = "02alice...";
    let bob = "02bob...";

    // 定義策略
    let policy_str = format!(
        "or(pk({}),and(pk({}),older(144)))",
        alice, bob
    );

    // 解析策略
    let policy = Concrete::<PublicKey>::from_str(&policy_str)?;

    // 編譯為 Miniscript
    let miniscript = policy.compile::<Segwitv0>()?;

    // 獲取 Script
    let script = miniscript.encode();

    println!("策略: {}", policy);
    println!("Miniscript: {}", miniscript);
    println!("Script 大小: {} bytes", script.len());

    Ok(())
}

5.3 描述符（Descriptors）

描述符是錢包軟體用來描述地址生成方式的標準格式。它們結合了腳本類型和密鑰資訊：

pkh(KEY) - P2PKH 地址
wpkh(KEY) - P2WPKH 地址
sh(wpkh(KEY)) - P2SH-P2WPKH
tr(KEY) - 簡單 P2TR
wsh(multi(2,KEY1,KEY2,KEY3)) - 2-of-3 P2WSH 多簽

描述符可以包含 HD 派生路徑，允許錢包批量生成地址：

wpkh([fingerprint/84'/0'/0']xpub.../0/*)

這表示：使用 BIP84 路徑派生的擴展公鑰，生成接收地址（/0/*）。

6. 進階腳本技巧

6.1 時間鎖

時間鎖是 Bitcoin 腳本的重要功能，允許資金只能在特定時間後被花費。

CHECKLOCKTIMEVERIFY（CLTV）實現絕對時間鎖。值小於 5 億被解釋為區塊高度，大於等於 5 億被解釋為 Unix 時間戳。

CHECKSEQUENCEVERIFY（CSV）實現相對時間鎖，從 UTXO 被創建開始計算。這對於閃電網路等協議至關重要。

fn timelock_script(pubkey: &PublicKey, blocks: i64) -> ScriptBuf {
    //  OP_CSV OP_DROP  OP_CHECKSIG
    Builder::new()
        .push_int(blocks)
        .push_opcode(OP_CSV)
        .push_opcode(OP_DROP)
        .push_key(pubkey)
        .push_opcode(OP_CHECKSIG)
        .into_script()
}

6.2 HTLC（哈希時間鎖合約）

HTLC 是閃電網路和原子交換的基礎。它允許有條件的支付：如果接收者在時限內揭示原像（preimage），可以領取資金；否則發送者可以取回。

fn htlc_script(
    recipient_pubkey: &XOnlyPublicKey,
    sender_pubkey: &XOnlyPublicKey,
    payment_hash: &[u8],
    timeout: i64,
) -> ScriptBuf {
    // IF
    //   OP_SHA256  OP_EQUALVERIFY  OP_CHECKSIG
    // ELSE
    //    OP_CLTV OP_DROP  OP_CHECKSIG
    // ENDIF

    Builder::new()
        .push_opcode(OP_IF)
            .push_opcode(OP_SHA256)
            .push_slice(payment_hash)
            .push_opcode(OP_EQUALVERIFY)
            .push_x_only_key(recipient_pubkey)
            .push_opcode(OP_CHECKSIG)
        .push_opcode(OP_ELSE)
            .push_int(timeout)
            .push_opcode(OP_CLTV)
            .push_opcode(OP_DROP)
            .push_x_only_key(sender_pubkey)
            .push_opcode(OP_CHECKSIG)
        .push_opcode(OP_ENDIF)
        .into_script()
}

6.3 Taproot 腳本樹

Taproot 允許將多個腳本組織成 Merkle 樹。每個葉子是一個獨立的花費條件。當使用某個腳本花費時，只需揭示該腳本和 Merkle 證明，其他腳本保持隱藏。

這種設計特別適合有多個備用花費方式的場景。例如，一個「金庫」可能有：

密鑰路徑：擁有者的正常花費
腳本 A：緊急恢復密鑰
腳本 B：延遲後的繼承人

fn taproot_tree_demo() -> anyhow::Result<()> {
    let secp = Secp256k1::new();
    let internal_key = XOnlyPublicKey::from_str("...")?;

    // 創建腳本
    let emergency_script = create_emergency_script(&emergency_key);
    let inheritance_script = create_inheritance_script(&heir_key, 52560); // ~1年

    // 構建樹
    let taproot = TaprootBuilder::new()
        .add_leaf(1, emergency_script)?
        .add_leaf(1, inheritance_script)?
        .finalize(&secp, internal_key)?;

    // 正常使用：key path（單簽名）
    // 緊急情況：script path A
    // 繼承：script path B（需要等待）

    Ok(())
}

7. 實戰：完整的 HTLC 交易

讓我們將所有概念結合起來，實現一個完整的 HTLC 交易流程。

fn htlc_transaction_flow() -> anyhow::Result<()> {
    let secp = Secp256k1::new();

    // 參與者
    let sender = Keypair::new(&secp, &mut rand::thread_rng());
    let recipient = Keypair::new(&secp, &mut rand::thread_rng());

    // 創建 preimage 和 hash
    let preimage = b"this is the secret";
    let payment_hash = sha256::Hash::hash(preimage);

    // 構建 HTLC Taproot

    // 成功路徑
    let success_script = Builder::new()
        .push_opcode(OP_SHA256)
        .push_slice(payment_hash.as_byte_array())
        .push_opcode(OP_EQUALVERIFY)
        .push_x_only_key(&recipient.x_only_public_key().0)
        .push_opcode(OP_CHECKSIG)
        .into_script();

    // 退款路徑（100 區塊後）
    let refund_script = Builder::new()
        .push_int(100)
        .push_opcode(OP_CSV)
        .push_opcode(OP_DROP)
        .push_x_only_key(&sender.x_only_public_key().0)
        .push_opcode(OP_CHECKSIG)
        .into_script();

    // 構建 Taproot（sender 作為內部密鑰）
    let taproot = TaprootBuilder::new()
        .add_leaf(1, success_script.clone())?
        .add_leaf(1, refund_script.clone())?
        .finalize(&secp, sender.x_only_public_key().0)?;

    let htlc_address = Address::p2tr_tweaked(
        taproot.output_key(),
        Network::Testnet
    );

    println!("HTLC 地址: {}", htlc_address);

    // ... 創建資金交易 ...

    // 成功花費（知道 preimage）
    // witness: [signature] [preimage] [script] [control_block]

    // 退款花費（超時後）
    // witness: [signature] [script] [control_block]
    // 並且 nSequence >= 100

    Ok(())
}

8. 總結

本篇深入探討了 Bitcoin Script 和簽名機制。我們學習了：

Script 基礎：堆疊執行模型、操作碼、腳本構建
標準腳本類型：從 P2PKH 到 Taproot 的演進
多重簽名：傳統多簽和 Taproot 時代的選擇
簽名機制：ECDSA、Schnorr 和各種 sighash 類型
Miniscript：安全、可分析的腳本開發
進階技巧：時間鎖、HTLC、Taproot 腳本樹

關鍵要點：

Script 定義了資金的花費條件
Schnorr 簽名提供了更小的簽名和聚合能力
Taproot 結合了效率和靈活性
Miniscript 使腳本開發更安全

下一篇將探討進階應用，包括與 Bitcoin 節點互動、完整的錢包開發和實際部署考量。

參考資源

BIP 文檔

Miniscript 資源

Rust Bitcoin 開發入門（二）：地址生成與交易構建

2025-03-23T00:00:00+00:00

這是 Rust Bitcoin 開發入門系列的第二篇。本篇深入探討 Bitcoin 地址的生成機制和交易的構建過程。

系列文章導航：

1. HD 錢包深入理解

1.1 為什麼需要 HD 錢包

在 Bitcoin 早期，用戶需要為每筆交易手動生成新的私鑰，並分別備份每一個私鑰。這種方式有明顯的問題：備份繁瑣、容易丟失，而且如果使用舊備份恢復錢包，可能會遺漏新生成的地址中的資金。

BIP32 提出了層級確定性（Hierarchical Deterministic，HD）錢包的概念，徹底改變了這個情況。HD 錢包從一個「種子」衍生出所有的私鑰，這意味著你只需要備份一次種子，就能恢復整個錢包的所有地址——包括未來創建的地址。

這個設計的數學基礎是單向函數和哈希函數的特性：從種子可以確定性地計算出無限多個子密鑰，但從子密鑰無法反推種子。這提供了安全性和便利性的完美平衡。

1.2 BIP32 層級派生

BIP32 定義了密鑰派生的具體方法。每個密鑰都可以派生出子密鑰，形成一個樹狀結構。派生路徑用斜線分隔的數字表示，例如 m/44'/0'/0'/0/0。

路徑中的每個數字代表一層派生：

m 是主密鑰（master key），從種子直接生成
數字後面的撇號（’）表示「硬化派生」（hardened derivation）
沒有撇號的數字表示「普通派生」（normal derivation）

硬化派生和普通派生的區別至關重要。普通派生允許從父公鑰派生子公鑰，這意味著如果攻擊者獲得了擴展公鑰（xpub），他可以計算出所有非硬化路徑下的子公鑰。更危險的是，如果攻擊者同時獲得了任何一個子私鑰和父公鑰，他就能推算出父私鑰。

硬化派生解決了這個問題。它的派生過程需要父私鑰參與，因此即使攻擊者獲得了擴展公鑰，也無法推導出硬化路徑下的子密鑰。這就是為什麼 purpose、coin type 和 account 層級總是使用硬化派生。

use bitcoin::bip32::{Xpriv, Xpub, DerivationPath, ChildNumber};
use bitcoin::Network;
use bitcoin::secp256k1::Secp256k1;

fn hd_derivation_demo() -> anyhow::Result<()> {
    let secp = Secp256k1::new();

    // 從種子創建主私鑰
    let seed = hex::decode(
        "000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f"
    )?;

    let master_xpriv = Xpriv::new_master(Network::Bitcoin, &seed)?;
    let master_xpub = Xpub::from_priv(&secp, &master_xpriv);

    // 硬化派生：m/0'
    // 注意 index 使用 0，但指定為 Hardened
    let child_hardened = master_xpriv.derive_priv(
        &secp,
        &[ChildNumber::Hardened { index: 0 }]
    )?;

    // 普通派生：m/0
    let child_normal = master_xpriv.derive_priv(
        &secp,
        &[ChildNumber::Normal { index: 0 }]
    )?;

    // 使用派生路徑字串
    let path = DerivationPath::from_str("m/84'/0'/0'/0/0")?;
    let derived = master_xpriv.derive_priv(&secp, &path)?;

    Ok(())
}

1.3 BIP39 助記詞

雖然種子是一串隨機的位元組，但人類很難記憶或抄寫這樣的數據。BIP39 提出了助記詞（mnemonic）的概念，將種子編碼為一組英文單詞。

助記詞的生成過程是這樣的：首先生成一定長度的隨機熵（128 到 256 位），然後計算熵的 SHA256 校驗和，取校驗和的前幾位附加到熵的末尾。最後將這個組合數據分割成 11 位一組，每組對應 BIP39 字典中的一個單詞。

熵的長度決定了助記詞的數量。128 位熵產生 12 個單詞，256 位熵產生 24 個單詞。更長的助記詞提供更高的安全性，但 12 個單詞（128 位熵）在實際使用中已經足夠安全。

use bip39::{Mnemonic, Language};

fn mnemonic_demo() -> anyhow::Result<()> {
    // 生成 12 字助記詞
    let mnemonic = Mnemonic::generate_in(Language::English, 12)?;
    println!("助記詞: {}", mnemonic);

    // 從助記詞生成種子
    // 可以使用可選的密碼短語增加安全性
    let passphrase = "";
    let seed = mnemonic.to_seed(passphrase);

    // 種子是 512 位（64 bytes）
    println!("種子長度: {} bytes", seed.len());

    // 驗證現有助記詞
    let phrase = "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about";
    let parsed = Mnemonic::parse_in(Language::English, phrase)?;

    // 獲取原始熵
    let entropy = parsed.to_entropy();
    println!("熵: {}", hex::encode(&entropy));

    Ok(())
}

密碼短語（passphrase）是一個重要但經常被忽視的功能。它在從助記詞生成種子時作為額外的輸入。不同的密碼短語會生成完全不同的種子，從而產生完全不同的錢包。這提供了額外的安全層：即使攻擊者獲得了你的助記詞，沒有密碼短語他也無法存取你的資金。這也可以用來創建「誘餌錢包」——使用空密碼短語的錢包放少量資金，真正的資金存放在有密碼短語的錢包中。

1.4 標準派生路徑

隨著時間推移，社區制定了多個 BIP 來標準化派生路徑，確保不同錢包軟體之間的互操作性。

BIP44 定義了傳統地址（P2PKH）的路徑格式：m/44'/coin'/account'/change/index。這裡 44 是 purpose，表示遵循 BIP44 標準。coin 是幣種代碼（Bitcoin 是 0，Testnet 是 1）。account 允許用戶在同一個錢包中維護多個獨立的帳戶。change 為 0 表示外部鏈（用於接收付款），為 1 表示內部鏈（用於找零）。index 是地址的序號。

BIP49 為 P2SH-P2WPKH（兼容 SegWit）地址定義了 purpose 49。

BIP84 為原生 SegWit（P2WPKH）地址定義了 purpose 84。

BIP86 為 Taproot（P2TR）地址定義了 purpose 86。

use bitcoin::bip32::{Xpriv, DerivationPath};
use bitcoin::{Network, Address, PublicKey};
use bitcoin::secp256k1::Secp256k1;

struct HDWallet {
    master_xpriv: Xpriv,
    network: Network,
}

impl HDWallet {
    fn derive_address(&self, purpose: u32, account: u32, is_change: bool, index: u32)
        -> anyhow::Result<Address>
    {
        let secp = Secp256k1::new();
        let coin = if self.network == Network::Bitcoin { 0 } else { 1 };
        let change = if is_change { 1 } else { 0 };

        let path = DerivationPath::from_str(&format!(
            "m/{}'/{}'/{}'/{}'/{}",
            purpose, coin, account, change, index
        ))?;

        let derived_xpriv = self.master_xpriv.derive_priv(&secp, &path)?;
        let public_key = PublicKey::new(
            derived_xpriv.to_priv().public_key(&secp)
        );

        let address = match purpose {
            44 => Address::p2pkh(&public_key, self.network),
            49 => Address::p2shwpkh(&public_key, self.network),
            84 => Address::p2wpkh(&public_key, self.network),
            86 => {
                let internal_key = bitcoin::key::UntweakedPublicKey::from(
                    derived_xpriv.to_priv().public_key(&secp)
                );
                Address::p2tr(&secp, internal_key, None, self.network)
            }
            _ => anyhow::bail!("不支援的 purpose: {}", purpose),
        };

        Ok(address)
    }
}

2. 地址類型詳解

2.1 地址的本質

Bitcoin 地址不是存儲資金的「帳戶」，而是指定誰可以花費資金的「條件」的編碼形式。當你發送 Bitcoin 到一個地址時，實際上是在創建一個輸出，這個輸出被一個特定的腳本鎖定。地址是這個鎖定腳本的便於人類閱讀的表示。

不同的地址類型對應不同的腳本模式。理解這些差異對於開發者來說很重要，因為它們影響交易大小、費用和功能。

2.2 P2PKH（Pay-to-Public-Key-Hash）

P2PKH 是最原始的地址類型，以數字 1 開頭。它的鎖定腳本要求提供一個公鑰和對應的簽名，且公鑰的雜湊值必須匹配地址中編碼的值。

這種設計有一個隱私優點：在資金被花費之前，公鑰不會出現在區塊鏈上，只有公鑰的雜湊值是可見的。這為抵禦某些理論上的量子計算攻擊提供了一定保護——即使量子電腦能從公鑰推導私鑰，在公鑰暴露之前，資金仍然是安全的。

use bitcoin::{Address, PublicKey, Network};

fn p2pkh_demo(public_key: &PublicKey) {
    let address = Address::p2pkh(public_key, Network::Bitcoin);
    // 格式：1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2

    // 對應的 scriptPubKey：
    // OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG
}

2.3 P2SH（Pay-to-Script-Hash）

P2SH 以數字 3 開頭，允許支付到任意腳本的雜湊值，而不是特定的公鑰雜湊。這種靈活性使得複雜的腳本（如多重簽名）可以使用簡短的地址表示。

P2SH 的一個常見用途是包裝 SegWit 腳本（P2SH-P2WPKH 和 P2SH-P2WSH），為不支援原生 SegWit 地址的舊錢包提供兼容性。發送者不需要知道底層使用的是什麼腳本——他們只需支付到這個以 3 開頭的地址即可。

2.4 P2WPKH（原生 SegWit）

P2WPKH 是 SegWit 升級引入的原生見證地址類型，以 bc1q 開頭。它的功能與 P2PKH 類似，但簽名數據被移到了交易的「見證」部分，不計入傳統的區塊大小限制。

這帶來了多個好處。首先是費用節省：見證數據的費用權重只有非見證數據的四分之一，典型的 P2WPKH 交易比 P2PKH 交易便宜約 38%。其次是解決了交易可延展性（malleability）問題，這對於閃電網路等二層協議至關重要。

fn p2wpkh_demo(public_key: &PublicKey) {
    let address = Address::p2wpkh(public_key, Network::Bitcoin);
    // 格式：bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

    // scriptPubKey 很簡短：
    // OP_0 <20-byte-pubkey-hash>
}

2.5 P2TR（Taproot）

P2TR 是 2021 年啟用的 Taproot 升級引入的地址類型，以 bc1p 開頭。它代表了 Bitcoin 腳本能力的重大進步。

Taproot 地址可以通過兩種方式花費：密鑰路徑（key path）和腳本路徑（script path）。密鑰路徑是最簡單的情況——只需提供一個 Schnorr 簽名。腳本路徑允許使用複雜的條件，但這些條件被隱藏在 Merkle 樹中，只有在使用特定條件時才會揭示。

這種設計的隱私優勢是巨大的。無論底層腳本多複雜，如果所有參與者同意（使用密鑰路徑），交易看起來就像一個普通的單簽名交易。觀察者無法區分簡單支付和複雜的多方協議。

fn p2tr_demo(secp: &Secp256k1<secp256k1::All>, private_key: &PrivateKey) {
    let internal_key = bitcoin::key::UntweakedPublicKey::from(
        private_key.public_key(secp)
    );

    // 只有密鑰路徑，沒有腳本樹
    let address = Address::p2tr(secp, internal_key, None, Network::Bitcoin);
    // 格式：bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr
}

2.6 地址解析與驗證

在處理用戶輸入的地址時，驗證非常重要。無效的地址會導致資金永久丟失。rust-bitcoin 提供了完整的地址解析和驗證功能。

use bitcoin::{Address, Network};
use std::str::FromStr;

fn validate_address(addr_str: &str, expected_network: Network) -> anyhow::Result<Address> {
    // 解析地址（這會驗證格式和校驗和）
    let address = Address::from_str(addr_str)?;

    // 驗證網路
    if !address.is_valid_for_network(expected_network) {
        anyhow::bail!("地址網路不匹配");
    }

    // assume_checked 表示我們已經驗證過了
    Ok(address.assume_checked())
}

3. 理解 UTXO 模型

3.1 UTXO vs 帳戶模型

Bitcoin 使用 UTXO（Unspent Transaction Output，未花費交易輸出）模型，這與以太坊使用的帳戶模型有本質區別。

在帳戶模型中，每個地址有一個餘額，交易就是從一個帳戶減少餘額、向另一個帳戶增加餘額。這類似於傳統銀行帳戶的運作方式。

在 UTXO 模型中，沒有「餘額」的概念。取而代之的是一組獨立的「硬幣」——每個 UTXO 是之前某筆交易創建的一個輸出，它有特定的金額和花費條件。你的「餘額」是所有屬於你的 UTXO 的金額總和。

當你發送 Bitcoin 時，你必須選擇一個或多個 UTXO 作為輸入，完全消耗它們，然後創建新的輸出。如果輸入總額超過你想發送的金額，你需要創建一個「找零」輸出，將多餘的資金發回給自己。

這個模型有幾個重要的含義。首先，每個 UTXO 只能被花費一次——這是 Bitcoin 如何防止雙重支付的。其次，交易的隱私性受到 UTXO 選擇的影響——如果你合併多個 UTXO，觀察者可以推斷它們可能屬於同一個人。第三，UTXO 的數量會影響未來交易的費用——更多的輸入意味著更大的交易和更高的費用。

3.2 選幣策略

當構建交易時，選擇使用哪些 UTXO 是一個重要的決策。不同的選幣策略有不同的權衡。

最簡單的策略是「最大優先」——優先選擇金額最大的 UTXO。這通常能最小化所需的輸入數量，從而減少交易費用。但它也有缺點：小額 UTXO 可能永遠不會被使用，隨著時間推移，你會累積大量「粉塵」。

「先進先出」（FIFO）策略按 UTXO 的年齡排序，優先使用最老的。這有助於維持 UTXO 集的「健康」，避免碎片化。

更複雜的策略會考慮隱私因素，避免合併來自不同來源的 UTXO，或者使用「隨機」選擇來增加觀察者的分析難度。

struct UTXOSelector;

impl UTXOSelector {
    fn select_largest_first(
        utxos: &[UTXO],
        target: u64,
        fee_rate: u64,
    ) -> Option<Vec<UTXO>> {
        let mut sorted: Vec<_> = utxos.to_vec();
        sorted.sort_by(|a, b| b.amount.cmp(&a.amount));

        let mut selected = Vec::new();
        let mut total = 0u64;

        for utxo in sorted {
            // 估算這個輸入的費用
            let input_fee = Self::estimate_input_fee(fee_rate);

            // 跳過粉塵 UTXO
            if utxo.amount < input_fee {
                continue;
            }

            selected.push(utxo);
            total += utxo.amount;

            // 檢查是否已經夠了
            let required = target + Self::estimate_total_fee(&selected, fee_rate);
            if total >= required {
                return Some(selected);
            }
        }

        None
    }

    fn estimate_input_fee(fee_rate: u64) -> u64 {
        68 * fee_rate  // P2WPKH 輸入約 68 vbytes
    }

    fn estimate_total_fee(inputs: &[UTXO], fee_rate: u64) -> u64 {
        let base = 10 * fee_rate;  // 基礎開銷
        let outputs = 31 * 2 * fee_rate;  // 兩個輸出
        let inputs_fee = inputs.len() as u64 * 68 * fee_rate;
        base + outputs + inputs_fee
    }
}

4. 交易結構詳解

4.1 交易的組成

一筆 Bitcoin 交易由幾個部分組成：

版本號（Version）指示交易遵循的規則。版本 2 啟用了 BIP68 定義的相對時間鎖功能。

輸入（Inputs）是這筆交易花費的 UTXO 列表。每個輸入包含：

前一筆交易的 ID（txid）和輸出索引（vout），用於識別被花費的 UTXO
簽名腳本（scriptSig），對於 SegWit 交易這裡通常是空的
序列號（sequence），用於相對時間鎖和 RBF（Replace-By-Fee）信號

輸出（Outputs）是這筆交易創建的新 UTXO。每個輸出包含：

金額（以 satoshi 為單位）
鎖定腳本（scriptPubKey），定義誰可以花費這個輸出

見證（Witness）是 SegWit 引入的新欄位，包含每個輸入的簽名和其他驗證數據。

鎖定時間（LockTime）指定這筆交易可以被包含到區塊的最早時間（區塊高度或時間戳）。

use bitcoin::{
    Transaction, TxIn, TxOut, OutPoint, Txid, Sequence, Witness,
    ScriptBuf, Amount, transaction::Version, absolute::LockTime,
};

fn create_transaction_structure() -> Transaction {
    // 創建輸入
    let input = TxIn {
        previous_output: OutPoint {
            txid: Txid::from_str("...").unwrap(),
            vout: 0,
        },
        script_sig: ScriptBuf::new(),  // SegWit 交易為空
        sequence: Sequence::ENABLE_RBF_NO_LOCKTIME,
        witness: Witness::new(),
    };

    // 創建輸出
    let output = TxOut {
        value: Amount::from_sat(50_000),
        script_pubkey: ScriptBuf::new_p2wpkh(&wpkh),
    };

    Transaction {
        version: Version::TWO,
        lock_time: LockTime::ZERO,
        input: vec![input],
        output: vec![output],
    }
}

4.2 交易大小與費用

Bitcoin 的交易費用是按交易大小計算的，但 SegWit 引入了「權重」的概念來更精確地衡量交易對區塊空間的消耗。

交易權重的計算方式是：非見證數據的位元組數乘以 4，加上見證數據的位元組數。然後將權重除以 4 得到「虛擬大小」（vsize），這是計算費用時使用的單位。

這個設計給了見證數據 75% 的「折扣」，鼓勵使用 SegWit，因為見證數據不會永久存儲在每個節點的 UTXO 集中。

struct FeeCalculator;

impl FeeCalculator {
    // P2WPKH 輸入的重量：約 271 WU（68 vbytes）
    // P2TR 輸入的重量：約 229 WU（58 vbytes）
    // P2WPKH 輸出的重量：124 WU（31 vbytes）
    // P2TR 輸出的重量：172 WU（43 vbytes）

    fn calculate_fee(tx: &Transaction, fee_rate: u64) -> u64 {
        let weight = tx.weight();
        let vsize = weight.to_vbytes_ceil();
        vsize * fee_rate
    }
}

4.3 RBF（Replace-By-Fee）

RBF 是一種允許未確認交易被替換的機制。當一筆交易的確認時間比預期長（因為費用設得太低），發送者可以廣播一個新版本，支付更高的費用。

要啟用 RBF，至少一個輸入的序列號必須小於 0xFFFFFFFE。rust-bitcoin 提供了便利的常量來設置這個值。

use bitcoin::Sequence;

// 啟用 RBF，不使用鎖定時間
let sequence = Sequence::ENABLE_RBF_NO_LOCKTIME;

// 最大序列號（禁用 RBF）
let no_rbf = Sequence::MAX;

5. 構建並簽名交易

5.1 簽名過程

簽名一筆 Bitcoin 交易涉及多個步驟。首先需要計算「簽名哈希」（sighash），這是對交易數據的一個特定摘要，簽名者需要對這個摘要簽名。

對於 SegWit 交易，簽名哈希的計算遵循 BIP143 的規定，這與傳統交易不同。主要區別是 BIP143 的 sighash 包含每個輸入被花費的 UTXO 的金額，這消除了某些類型的攻擊。

簽名類型（sighash type）指定了簽名涵蓋交易的哪些部分：

SIGHASH_ALL（最常見）：簽名涵蓋所有輸入和輸出
SIGHASH_NONE：只簽名輸入，允許任何人修改輸出
SIGHASH_SINGLE：簽名一個輸入和對應的輸出
可以與 ANYONECANPAY 組合，只簽名當前輸入，允許添加更多輸入

use bitcoin::sighash::{SighashCache, EcdsaSighashType};
use bitcoin::secp256k1::{Secp256k1, Message};

fn sign_p2wpkh_input(
    tx: &mut Transaction,
    input_index: usize,
    utxo_amount: Amount,
    private_key: &PrivateKey,
) -> anyhow::Result<()> {
    let secp = Secp256k1::new();
    let public_key = private_key.public_key(&secp);

    // P2WPKH 的 scriptCode 是對應 P2PKH 的 scriptPubKey
    let script_code = ScriptBuf::new_p2pkh(&public_key.pubkey_hash());

    // 計算簽名哈希
    let mut sighash_cache = SighashCache::new(&*tx);
    let sighash = sighash_cache.p2wpkh_signature_hash(
        input_index,
        &script_code,
        utxo_amount,
        EcdsaSighashType::All,
    )?;

    // 創建簽名
    let message = Message::from_digest_slice(sighash.as_byte_array())?;
    let signature = secp.sign_ecdsa(&message, &private_key.inner);

    // 組裝 witness：[signature, pubkey]
    let mut sig_bytes = signature.serialize_der().to_vec();
    sig_bytes.push(EcdsaSighashType::All.to_u32() as u8);

    tx.input[input_index].witness.push(sig_bytes);
    tx.input[input_index].witness.push(public_key.to_bytes());

    Ok(())
}

5.2 PSBT（部分簽名交易）

PSBT（Partially Signed Bitcoin Transaction）是 BIP174 定義的標準格式，用於在多方之間傳遞待簽名的交易。它對於多重簽名、硬體錢包和其他需要多步驟簽名的場景非常有用。

PSBT 包含了簽名者需要的所有資訊：未簽名的交易、每個輸入被花費的 UTXO 資訊、派生路徑等。簽名者可以添加自己的簽名，然後將 PSBT 傳遞給下一個簽名者或組合者。

一個典型的 PSBT 工作流程是：

創建者創建一個基礎的 PSBT，包含未簽名交易
更新者添加 UTXO 資訊、派生路徑等元數據
簽名者為他們控制的輸入添加簽名
組合者將多個部分簽名的 PSBT 合併
最終化者完成所有輸入的腳本，生成可廣播的交易
廣播者將交易廣播到網路

use bitcoin::psbt::Psbt;

fn psbt_workflow() -> anyhow::Result<()> {
    // 創建未簽名交易
    let unsigned_tx = create_unsigned_transaction()?;

    // 創建 PSBT
    let mut psbt = Psbt::from_unsigned_tx(unsigned_tx)?;

    // 添加 UTXO 資訊（簽名者需要這些）
    psbt.inputs[0].witness_utxo = Some(TxOut {
        value: Amount::from_sat(100_000),
        script_pubkey: sender_script,
    });

    // 序列化為 Base64（用於傳輸）
    let psbt_base64 = psbt.to_string();

    // 簽名者解析並簽名
    let mut psbt = Psbt::from_str(&psbt_base64)?;
    // ... 添加簽名 ...

    // 最終化並提取交易
    psbt.finalize_mut(&secp).expect("最終化失敗");
    let signed_tx = psbt.extract_tx()?;

    Ok(())
}

6. 實戰：完整的錢包實現

下面是一個簡單但完整的錢包實現，展示了從地址生成到交易廣播的整個流程。

use bitcoin::{
    Network, Address, PrivateKey, PublicKey,
    Transaction, TxIn, TxOut, OutPoint, Txid, Sequence, Witness,
    ScriptBuf, Amount,
    sighash::{SighashCache, EcdsaSighashType},
    transaction::Version,
    absolute::LockTime,
    secp256k1::Secp256k1,
};

pub struct Wallet {
    private_key: PrivateKey,
    public_key: PublicKey,
    address: Address,
    network: Network,
    secp: Secp256k1<secp256k1::All>,
}

pub struct UTXO {
    pub txid: Txid,
    pub vout: u32,
    pub amount: Amount,
}

impl Wallet {
    pub fn new(wif: &str) -> anyhow::Result<Self> {
        let secp = Secp256k1::new();
        let private_key = PrivateKey::from_wif(wif)?;
        let public_key = private_key.public_key(&secp);
        let network = private_key.network;
        let address = Address::p2wpkh(&public_key, network);

        Ok(Self {
            private_key,
            public_key,
            address,
            network,
            secp,
        })
    }

    pub fn create_and_sign_transaction(
        &self,
        utxos: Vec<UTXO>,
        recipient: &Address,
        amount: Amount,
        fee_rate: u64,
    ) -> anyhow::Result<Transaction> {
        // 計算總輸入金額
        let total_input: Amount = utxos.iter().map(|u| u.amount).sum();

        // 估算費用
        let estimated_size = 10 + 68 * utxos.len() + 31 * 2;
        let fee = Amount::from_sat(estimated_size as u64 * fee_rate);

        // 計算找零
        let change = total_input.checked_sub(amount + fee)
            .ok_or_else(|| anyhow::anyhow!("餘額不足"))?;

        // 構建輸入
        let inputs: Vec<TxIn> = utxos.iter().map(|utxo| TxIn {
            previous_output: OutPoint {
                txid: utxo.txid,
                vout: utxo.vout,
            },
            script_sig: ScriptBuf::new(),
            sequence: Sequence::ENABLE_RBF_NO_LOCKTIME,
            witness: Witness::new(),
        }).collect();

        // 構建輸出
        let mut outputs = vec![TxOut {
            value: amount,
            script_pubkey: recipient.script_pubkey(),
        }];

        // 只有當找零超過粉塵限制時才添加找零輸出
        if change > Amount::from_sat(546) {
            outputs.push(TxOut {
                value: change,
                script_pubkey: self.address.script_pubkey(),
            });
        }

        // 創建交易
        let mut tx = Transaction {
            version: Version::TWO,
            lock_time: LockTime::ZERO,
            input: inputs,
            output: outputs,
        };

        // 簽名每個輸入
        let script_code = ScriptBuf::new_p2pkh(&self.public_key.pubkey_hash());

        for (i, utxo) in utxos.iter().enumerate() {
            let mut sighash_cache = SighashCache::new(&tx);
            let sighash = sighash_cache.p2wpkh_signature_hash(
                i,
                &script_code,
                utxo.amount,
                EcdsaSighashType::All,
            )?;

            let message = secp256k1::Message::from_digest_slice(
                sighash.as_byte_array()
            )?;
            let signature = self.secp.sign_ecdsa(&message, &self.private_key.inner);

            let mut sig_bytes = signature.serialize_der().to_vec();
            sig_bytes.push(EcdsaSighashType::All.to_u32() as u8);

            tx.input[i].witness.push(sig_bytes);
            tx.input[i].witness.push(self.public_key.to_bytes());
        }

        Ok(tx)
    }
}

這個實現展示了 Bitcoin 交易的核心概念：UTXO 選擇、費用計算、輸出創建和簽名生成。在生產環境中，你還需要添加錯誤處理、UTXO 查詢（通過節點 RPC 或區塊瀏覽器 API）、以及交易廣播功能。

7. 練習題

練習 1：實現地址間隔掃描

創建一個函數，使用「地址間隔」策略生成 HD 錢包地址。這是錢包恢復的標準方法：連續檢查地址直到遇到一定數量的未使用地址。

練習 2：交易解析器

實現一個函數，解析原始交易的十六進制表示，提取並顯示所有欄位：版本、輸入、輸出、見證數據和鎖定時間。

練習 3：UTXO 合併

創建一個函數，將多個小額 UTXO 合併成一個大額 UTXO。這在費率低的時候做可以節省未來交易的費用。考慮何時合併是經濟的（費用節省超過合併成本）。

8. 總結

本篇深入探討了 Bitcoin 地址和交易的技術細節。我們了解了 HD 錢包如何讓單一種子衍生出無限地址，不同地址類型的特性和用途，UTXO 模型如何運作，以及如何構建和簽名真實的交易。

關鍵要點：

HD 錢包（BIP32/39/44/84）是現代錢包的標準
不同地址類型有不同的費用和功能特性
UTXO 選擇策略影響交易費用和隱私
SegWit 和 Taproot 提供更低的費用和更好的隱私
PSBT 是多方簽名工作流程的標準格式

下一篇將深入探討 Bitcoin Script 編程和各種簽名機制。

參考資源

BIP 文檔

工具

Rust Bitcoin 開發入門（一）：環境設置與基礎概念

2025-03-22T00:00:00+00:00

這是 Rust Bitcoin 開發入門系列的第一篇。本系列將帶你從零開始使用 Rust 語言開發 Bitcoin 應用，從基礎設置到進階應用。

系列文章導航：

1. 為什麼選擇 Rust？

1.1 Rust 在 Bitcoin 開發中的優勢

當我們思考 Bitcoin 開發的語言選擇時，必須考慮這個領域的特殊需求。Bitcoin 是一個處理真實價值的系統，任何程式錯誤都可能導致不可逆的財務損失。與普通的網頁應用不同，Bitcoin 程式碼沒有「修復後重新部署」的奢侈——一旦交易廣播到網路並被確認，就永遠無法撤銷。

Rust 語言的設計理念與 Bitcoin 開發的需求高度契合。首先是記憶體安全。傳統的 C/C++ 程式經常遭受緩衝區溢位（buffer overflow）、使用後釋放（use-after-free）等漏洞的困擾。這些漏洞在金融軟體中可能是災難性的。Rust 的所有權系統在編譯時就能捕捉這些問題，而不是等到程式在生產環境中崩潰。

其次是執行緒安全。現代 Bitcoin 應用常常需要同時處理多個操作——監聽新區塊、處理用戶請求、簽署交易等。Rust 的借用檢查器能在編譯時防止資料競爭（data races），這意味著多執行緒程式的正確性有編譯器的保證。

效能方面，Rust 提供了「零成本抽象」。你可以使用高階的程式設計概念（泛型、迭代器、閉包等），而編譯器會將其優化成與手寫底層程式碼相當的機器碼。這對於需要處理大量密碼學運算的 Bitcoin 應用非常重要。

最後，Rust 沒有垃圾收集器（GC）。這意味著程式的執行時機是可預測的，不會突然暫停來回收記憶體。對於需要快速回應的交易簽署或區塊處理來說，這種可預測性是必要的。

1.2 Rust Bitcoin 生態系統

Rust 的 Bitcoin 生態系統已經相當成熟，形成了層次分明的函式庫架構。

在最底層，我們有 bitcoin_hashes 和 secp256k1。bitcoin_hashes 提供了 Bitcoin 使用的所有哈希函數——SHA256、RIPEMD160、HASH160 等。secp256k1 則是 Bitcoin 使用的橢圓曲線密碼學函式庫的 Rust 綁定，用於私鑰/公鑰運算和數位簽名。

在其上是 rust-bitcoin，這是核心的協議函式庫。它定義了 Bitcoin 的所有資料結構——交易、區塊、地址、腳本等——以及它們的序列化和解析邏輯。幾乎所有 Rust Bitcoin 專案都會依賴這個函式庫。

更高層次的函式庫建立在 rust-bitcoin 之上。BDK（Bitcoin Development Kit）是一個完整的錢包開發框架，處理了 UTXO 管理、交易構建、硬體錢包整合等複雜問題。LDK（Lightning Development Kit）則提供了 Lightning Network 的實現，讓開發者可以將閃電網路功能整合到自己的應用中。

這種分層架構的好處是，你可以根據需求選擇適當的抽象層次。需要完全控制？直接使用 rust-bitcoin。想要快速開發錢包？使用 BDK。

2. 環境設置

2.1 安裝 Rust

Rust 的安裝透過官方工具 rustup 進行，這是一個版本管理器，可以輕鬆切換 Rust 版本和安裝額外組件。

# 安裝 Rustup（Rust 版本管理器）
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# 按照提示完成安裝後，重新載入環境變數
source $HOME/.cargo/env

# 驗證安裝
rustc --version
cargo --version

安裝完成後，建議安裝兩個實用工具：clippy 是一個 lint 工具，能指出程式碼中的常見問題和改進建議；rustfmt 則自動格式化程式碼，保持風格一致。

rustup component add clippy
rustup component add rustfmt

2.2 創建專案

Rust 使用 Cargo 作為建構工具和套件管理器。創建新專案非常簡單：

cargo new bitcoin-tutorial
cd bitcoin-tutorial

這會創建一個標準的 Rust 專案結構。Cargo.toml 是專案的設定檔，定義了專案名稱、版本和依賴關係。src/main.rs 是主程式檔案。

2.3 配置依賴

在 Cargo.toml 中添加 Bitcoin 開發所需的依賴。每個依賴都有其特定用途：

[package]
name = "bitcoin-tutorial"
version = "0.1.0"
edition = "2021"

[dependencies]
# Bitcoin 核心庫 - 提供所有 Bitcoin 資料結構和協議邏輯
bitcoin = { version = "0.32", features = ["serde", "rand-std"] }

# 橢圓曲線密碼學 - 用於簽名和金鑰操作
secp256k1 = { version = "0.29", features = ["rand-std", "global-context"] }

# 序列化框架 - 用於 JSON 處理
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"

# 十六進制編碼 - Bitcoin 資料常用十六進制表示
hex = "0.4"

# 錯誤處理 - 簡化錯誤傳播
anyhow = "1.0"
thiserror = "1.0"

# BIP39 助記詞 - 人類可讀的種子格式
bip39 = "2.0"

bitcoin 函式庫的 serde feature 啟用了序列化支援，rand-std 則允許使用標準函式庫的隨機數生成器。secp256k1 的 global-context feature 提供了一個全域的上下文物件，避免在每次運算時都創建新的上下文。

3. rust-bitcoin 基礎

3.1 理解金額（Amount）

在 Bitcoin 內部，所有金額都以「聰」（satoshi）計算。一個 Bitcoin 等於一億聰（100,000,000 satoshi）。這種設計避免了浮點數運算的精度問題——在處理金錢時，這種精度至關重要。

use bitcoin::Amount;

fn amount_examples() {
    // 從聰創建金額
    let amount_sat = Amount::from_sat(100_000_000);  // 1 BTC

    // 從 BTC 創建金額（注意：可能失敗，因此返回 Result）
    let amount_btc = Amount::from_btc(1.0).unwrap();

    // 兩者相等
    assert_eq!(amount_sat, amount_btc);

    // 金額運算
    let fee = Amount::from_sat(1000);
    let total = amount_btc + fee;

    // 使用 checked_sub 避免溢位（金額不能為負）
    let remaining = amount_btc.checked_sub(fee)
        .expect("金額不足");
}

Amount 類型防止了一個常見錯誤：混淆 BTC 和 satoshi 單位。編譯器會確保你在運算時使用相同的單位。

3.2 網路類型（Network）

Bitcoin 有多個網路，每個網路使用不同的地址前綴和協議參數：

use bitcoin::Network;

fn network_examples() {
    let mainnet = Network::Bitcoin;   // 正式網路，使用真實的 BTC
    let testnet = Network::Testnet;   // 測試網路，使用無價值的測試幣
    let signet = Network::Signet;     // 簽名測試網路，更穩定的測試環境
    let regtest = Network::Regtest;   // 本地回歸測試網路
}

在開發過程中，應該始終使用測試網路（testnet 或 signet），直到程式碼經過充分測試。在測試網路上犯錯不會有任何財務損失，但在主網上的錯誤可能是災難性的。

3.3 哈希函數

Bitcoin 大量使用哈希函數，每種函數都有特定用途：

SHA256 是基礎的哈希函數，輸出 32 bytes。

Double SHA256（SHA256d） 是對資料進行兩次 SHA256。Bitcoin 在許多地方使用這種雙重哈希，包括交易 ID、區塊雜湊等。這可能是為了防止某些理論上的攻擊（長度擴展攻擊），雖然對 SHA256 來說這可能是過度謹慎。

RIPEMD160 是一個輸出 20 bytes 的哈希函數。

HASH160 是 SHA256 後接 RIPEMD160，用於生成公鑰的雜湊值，進而生成地址。使用這個組合而不是單純的 SHA256 是為了得到更短的輸出（20 bytes vs 32 bytes），減少地址長度。

use bitcoin::hashes::{sha256, sha256d, ripemd160, hash160, Hash};

fn hash_examples() {
    let data = b"Hello, Bitcoin!";

    // SHA256
    let sha256_hash = sha256::Hash::hash(data);

    // Double SHA256（Bitcoin 標準）
    let sha256d_hash = sha256d::Hash::hash(data);

    // HASH160（用於地址生成）
    let hash160_result = hash160::Hash::hash(data);
}

3.4 secp256k1 橢圓曲線

Bitcoin 使用 secp256k1 橢圓曲線進行公鑰密碼學。理解這個曲線的基本概念對於 Bitcoin 開發很重要。

私鑰本質上是一個 256 位的隨機數。這個數字必須在 1 到曲線的階（一個非常大的質數）之間。任何在這個範圍內的數字都是有效的私鑰。

公鑰是橢圓曲線上的一個點，由私鑰乘以曲線的生成點 G 得到：P = k * G，其中 k 是私鑰，P 是公鑰。這個運算是單向的——從公鑰無法推導出私鑰（這就是橢圓曲線離散對數問題）。

use secp256k1::{Secp256k1, SecretKey, PublicKey};

fn key_generation() {
    // 創建 secp256k1 上下文
    let secp = Secp256k1::new();

    // 生成隨機私鑰
    let mut rng = rand::thread_rng();
    let secret_key = SecretKey::new(&mut rng);

    // 從私鑰導出公鑰
    let public_key = PublicKey::from_secret_key(&secp, &secret_key);

    // 公鑰有兩種序列化格式
    let compressed = public_key.serialize();      // 33 bytes
    let uncompressed = public_key.serialize_uncompressed();  // 65 bytes
}

壓縮公鑰只包含 x 座標和一個表示 y 座標正負的位元（因為給定 x，y 只有兩個可能值）。未壓縮公鑰包含完整的 x 和 y 座標。現代 Bitcoin 幾乎總是使用壓縮公鑰，因為它更短且同樣安全。

4. 編碼與序列化

4.1 十六進制編碼

Bitcoin 資料在顯示時幾乎總是使用十六進制（hex）格式。這是因為二進位資料不方便閱讀或複製，而十六進制提供了一個緊湊的文字表示。

fn hex_examples() {
    let data = vec![0xde, 0xad, 0xbe, 0xef];

    // 編碼為十六進制字串
    let hex_string = hex::encode(&data);  // "deadbeef"

    // 從十六進制解碼
    let decoded: Vec<u8> = hex::decode("deadbeef").unwrap();
}

4.2 Base58Check 編碼

傳統的 Bitcoin 地址使用 Base58Check 編碼。Base58 是 Base64 的變體，移除了容易混淆的字元（0、O、I、l），避免人工抄寫時的錯誤。

Base58Check 在 Base58 的基礎上增加了版本前綴和校驗和。版本前綴指示地址類型（P2PKH、P2SH 等）和網路（mainnet、testnet）。校驗和是資料的 double SHA256 的前 4 bytes，用於檢測輸入錯誤。

use bitcoin::hashes::{sha256d, Hash};
use bs58;

fn base58check_encode(version: u8, payload: &[u8]) -> String {
    let mut data = vec![version];
    data.extend_from_slice(payload);

    // 計算校驗和
    let checksum = sha256d::Hash::hash(&data);
    data.extend_from_slice(&checksum[..4]);

    bs58::encode(data).into_string()
}

版本位元組決定了地址的前綴：mainnet P2PKH 地址以 ‘1’ 開頭（版本 0x00），P2SH 地址以 ‘3’ 開頭（版本 0x05）。

4.3 Bech32 編碼

SegWit 引入了新的地址格式 Bech32（BIP 173），Taproot 則使用改進版的 Bech32m（BIP 350）。這些格式有幾個優點：

首先，它們只使用小寫字母和數字，避免了大小寫混淆。其次，錯誤檢測能力更強，可以檢測到更多類型的輸入錯誤。第三，它們自帶人類可讀的前綴（HRP），使網路識別更容易——mainnet 地址以 “bc1” 開頭，testnet 以 “tb1” 開頭。

use bitcoin::Address;

fn bech32_address_info() {
    // bc1q... 是 SegWit v0 地址（P2WPKH 或 P2WSH）
    // bc1p... 是 SegWit v1 地址（P2TR，Taproot）

    // Bech32 用於 v0，Bech32m 用於 v1+
    // 這個改變修復了 Bech32 的一個極端情況問題
}

4.4 Bitcoin 共識編碼

Bitcoin 協議使用特定的二進位編碼格式，稱為「共識編碼」。理解這個格式對於解析和創建原始交易很重要。

Bitcoin 使用小端序（Little Endian）來編碼多位元組整數。這與網路協議常用的大端序不同。

變長整數（VarInt）是一種空間優化的編碼方式。小於 253 的數字只用 1 byte，較大的數字則根據大小使用 3、5 或 9 bytes。這種編碼在交易中大量使用（例如表示輸入/輸出數量）。

fn encode_varint(n: u64) -> Vec<u8> {
    if n < 0xFD {
        vec![n as u8]
    } else if n <= 0xFFFF {
        let mut v = vec![0xFD];
        v.extend(&(n as u16).to_le_bytes());
        v
    } else if n <= 0xFFFFFFFF {
        let mut v = vec![0xFE];
        v.extend(&(n as u32).to_le_bytes());
        v
    } else {
        let mut v = vec![0xFF];
        v.extend(&n.to_le_bytes());
        v
    }
}

5. 錯誤處理

5.1 Rust 的錯誤處理哲學

Rust 的錯誤處理與許多語言不同。它不使用例外（exceptions），而是透過類型系統明確表示可能失敗的操作。這迫使程式設計師在編譯時就考慮錯誤情況。

Result 類型表示一個可能成功（返回 T）或失敗（返回 E）的操作。Option 則表示一個可能存在（Some(T)）或不存在（None）的值。

use anyhow::{Context, Result};
use thiserror::Error;

// 使用 thiserror 定義自訂錯誤類型
#[derive(Error, Debug)]
pub enum BitcoinError {
    #[error("無效的私鑰: {0}")]
    InvalidPrivateKey(String),

    #[error("金額不足: 需要 {required} sat, 只有 {available} sat")]
    InsufficientFunds { required: u64, available: u64 },
}

thiserror 庫幫助你定義結構化的錯誤類型，適合函式庫使用。anyhow 則提供了一個通用的錯誤類型，適合應用程式——它可以包裝任何錯誤並附加上下文資訊。

5.2 實用的錯誤處理模式

在 Bitcoin 開發中，錯誤處理特別重要。一個常見的模式是使用 ? 運算符傳播錯誤，並用 context() 添加有意義的錯誤訊息：

fn process_transaction(tx_hex: &str) -> Result<()> {
    let tx_bytes = hex::decode(tx_hex)
        .context("無法解析交易十六進制")?;

    let tx: Transaction = consensus::deserialize(&tx_bytes)
        .context("無效的交易格式")?;

    // 處理交易...

    Ok(())
}

當這個函數失敗時，錯誤訊息會包含完整的上下文鏈，幫助診斷問題：「無法解析交易十六進制: invalid character ‘g’ at position 10」。

6. 第一個程式：生成地址

6.1 從隨機數生成地址

現在讓我們把所有概念結合起來，寫一個完整的地址生成程式。這個程式展示了從隨機私鑰到 Bitcoin 地址的完整流程：

use bitcoin::{
    Network, Address, PublicKey, PrivateKey,
    secp256k1::Secp256k1,
};
use rand::thread_rng;

fn generate_random_address() -> anyhow::Result<()> {
    let secp = Secp256k1::new();
    let mut rng = thread_rng();

    // 生成隨機私鑰
    let secret_key = secp256k1::SecretKey::new(&mut rng);
    let private_key = PrivateKey::new(secret_key, Network::Bitcoin);

    // 導出公鑰
    let public_key = private_key.public_key(&secp);

    // 生成不同類型的地址
    let p2pkh = Address::p2pkh(&public_key, Network::Bitcoin);
    let p2wpkh = Address::p2wpkh(&public_key, Network::Bitcoin);
    let p2shwpkh = Address::p2shwpkh(&public_key, Network::Bitcoin);

    println!("私鑰 (WIF): {}", private_key.to_wif());
    println!("P2PKH 地址:    {}", p2pkh);
    println!("P2WPKH 地址:   {}", p2wpkh);
    println!("P2SH-P2WPKH:   {}", p2shwpkh);

    Ok(())
}

這裡展示了三種地址類型：

P2PKH（Pay-to-Public-Key-Hash）是最傳統的地址類型，以 ‘1’ 開頭。它直接鎖定到公鑰的雜湊值。

P2WPKH（Pay-to-Witness-Public-Key-Hash）是原生 SegWit 地址，以 ‘bc1q’ 開頭。它提供較低的交易費用和更好的安全性。

P2SH-P2WPKH 是包裝在 P2SH 中的 SegWit，以 ‘3’ 開頭。它提供了與舊錢包的兼容性。

6.2 從助記詞生成地址

在實際應用中，我們通常不會直接生成隨機私鑰，而是使用助記詞（BIP39）和分層確定性派生（BIP32）。這種方法有幾個優點：用戶只需備份一組助記詞就能恢復所有地址；從同一個種子可以派生出無限多個地址；不同的派生路徑可以用於不同目的。

use bip39::{Mnemonic, Language};
use bitcoin::bip32::{Xpriv, Xpub, DerivationPath};
use std::str::FromStr;

fn generate_from_mnemonic() -> anyhow::Result<()> {
    let secp = Secp256k1::new();

    // 生成 12 字助記詞
    let mnemonic = Mnemonic::generate_in(Language::English, 12)?;
    println!("助記詞: {}", mnemonic);

    // 從助記詞生成種子（可選的密碼短語）
    let seed = mnemonic.to_seed("");

    // 生成主私鑰
    let master_xpriv = Xpriv::new_master(Network::Bitcoin, &seed)?;

    // 使用 BIP84 路徑派生原生 SegWit 地址
    // m/84'/0'/0'/0/0
    let path = DerivationPath::from_str("m/84'/0'/0'/0/0")?;
    let derived_xpriv = master_xpriv.derive_priv(&secp, &path)?;
    let derived_xpub = Xpub::from_priv(&secp, &derived_xpriv);

    let public_key = PublicKey::new(derived_xpub.public_key);
    let address = Address::p2wpkh(&public_key, Network::Bitcoin);

    println!("派生地址: {}", address);

    Ok(())
}

派生路徑 m/84'/0'/0'/0/0 遵循 BIP84 標準：

84' 表示這是 BIP84（原生 SegWit）路徑
第一個 0' 是 coin type（Bitcoin）
第二個 0' 是帳戶索引
0 是外部鏈（接收地址，vs 1 是找零地址）
最後的 0 是地址索引

撇號（’）表示「硬化」派生，這種派生方式即使公開了子公鑰，也無法推導出父私鑰。

7. 練習題

練習 1：批量地址生成器

創建一個程式，從同一個助記詞批量生成 10 個地址。使用 BIP84 派生路徑（m/84’/0’/0’/0/i），其中 i 從 0 到 9。這個練習幫助你理解 HD 錢包的工作原理。

練習 2：地址驗證器

創建一個函數，接受一個字串並驗證它是否是有效的 Bitcoin 地址。你的函數應該：

識別地址類型（P2PKH、P2SH、P2WPKH、P2WSH、P2TR）
驗證校驗和（對於 Base58 和 Bech32）
判斷網路（mainnet vs testnet）

練習 3：哈希計算器

創建一個命令列工具，計算輸入的各種 Bitcoin 相關雜湊值。支援 SHA256、SHA256d、RIPEMD160 和 HASH160，並能處理十六進制和 UTF-8 輸入。

8. 總結

本篇介紹了使用 Rust 進行 Bitcoin 開發的基礎知識。我們討論了為什麼 Rust 是 Bitcoin 開發的理想選擇——它的記憶體安全、效能和豐富的生態系統。我們設置了開發環境，了解了 rust-bitcoin 函式庫的基本類型，學習了 Bitcoin 使用的各種編碼格式，並寫出了第一個地址生成程式。

關鍵要點：

Bitcoin 內部使用 satoshi 作為金額單位
secp256k1 橢圓曲線是 Bitcoin 密碼學的基礎
不同的地址類型有不同的用途和特性
HD 錢包讓一組助記詞可以派生出無限地址

下一篇將深入探討地址生成的細節和交易構建的基礎。我們將學習如何創建、簽名和廣播真正的 Bitcoin 交易。

參考資源

官方文檔

學習資源

BIPs

Bitcoin Script 實戰教學（六）：進階應用與未來展望

2025-03-20T00:00:00+00:00

系列導言

這是「Bitcoin Script 實戰教學」系列的最後一篇。經過前五篇的學習，你已經掌握了比特幣腳本的基礎知識、各種標準腳本類型、SegWit 和 Taproot 的技術細節、多重簽名實現，以及時間鎖機制。在這一篇中，我們將探索比特幣腳本的前沿應用，包括 DLC（Discreet Log Contracts）、Vault 設計模式、Covenant 提案，以及未來可能的發展方向。

系列文章：

一、Discreet Log Contracts（DLC）

1.1 什麼是 DLC？

DLC（謹慎日誌合約）是一種創新的比特幣智能合約形式，允許兩方基於現實世界的事件結果進行條件支付。它由 Tadge Dryja（閃電網路的共同發明者）在 2018 年提出，解決了一個長期存在的問題：如何在不信任任何中心化實體的情況下，在比特幣上執行依賴外部數據的合約。

考慮這樣的場景：Alice 和 Bob 想要對 2025 年底比特幣的價格進行賭注。Alice 賭價格會超過 10 萬美元，Bob 賭不會。在傳統系統中，他們需要一個可信的第三方來判定結果並執行支付。DLC 則允許他們創建一個合約，由一個獨立的「神諭」（Oracle）來證明結果，但這個神諭甚至不需要知道合約的存在。

這裡的「謹慎」（Discreet）有雙重含義。首先，神諭發布的是通用數據（如「2025-12-31 BTC/USD = 102,345」），而不是針對特定合約的裁決，這意味著神諭不知道誰在使用它的數據。其次，DLC 交易在鏈上看起來就像普通的多簽名交易，觀察者無法判斷這是一個 DLC 結算。

1.2 Adaptor Signatures：DLC 的密碼學基礎

DLC 的核心技術是 Adaptor Signatures（適配器簽名），這是一種密碼學構造，允許創建「不完整」的簽名，只有在獲得某個秘密值後才能變成有效簽名。

在標準的 Schnorr 簽名中，簽名者用私鑰 d、隨機數 k、和訊息 m 計算簽名 (R, s)，其中 R = k × G，s = k + H(R, P, m) × d。驗證者可以用公式 s × G = R + H(R, P, m) × P 來驗證。

適配器簽名引入了一個「適配點」T = t × G，其中 t 是適配秘密。簽名者創建一個「不完整」簽名 (R’, s’)，其中 R’ = R + T。這個簽名單獨無法通過驗證，但如果有人知道 t，他們可以計算 s = s’ + t，得到相對於 R’ 的有效簽名。

這個機制的妙處在於：給定 (R’, s’) 和完成的簽名 (R’, s)，任何人都可以計算出 t = s - s’。這意味著使用適配器簽名會「揭示」適配秘密。

1.3 DLC 的工作流程

讓我們詳細看看 DLC 是如何工作的。

首先是設置階段。Alice 和 Bob 協商合約條款，包括：事件（如「2025-12-31 的 BTC/USD 價格」）、可能的結果（如價格區間）、每種結果對應的支付分配。然後他們找到一個或多個可信的神諭，獲取神諭的公鑰和對這個事件的「承諾點」。承諾點代表神諭將為每個可能結果發布的簽名對應的公鑰。

接下來是資金鎖定。雙方創建一筆「Funding Transaction」，將各自的資金鎖定到一個 2-of-2 多簽輸出。這筆交易上鏈後，資金就無法被任何一方單獨移動。

然後是預簽 CET（Contract Execution Transaction）。這是 DLC 的核心。對於每個可能的結果，雙方創建一筆 CET，表示該結果發生時的資金分配。例如，如果有 100 個可能的價格區間，就會有 100 筆不同的 CET。

關鍵在於：這些 CET 不是用普通簽名，而是用適配器簽名。每筆 CET 的適配點是神諭對該結果的簽名對應的公鑰。這意味著只有當神諭發布特定結果的簽名時，對應的 CET 才能被完成並廣播。

最後是結算。當事件發生時，神諭發布結果和對應的簽名 s。獲勝方使用這個簽名作為適配秘密，完成對應 CET 的適配器簽名，得到有效簽名，然後廣播 CET 獲取資金。

這個機制的優美之處在於：神諭只發布一次數據，完全不知道誰在使用它；雙方在設置階段就交換了所有需要的信息，結算時不需要額外互動；整個過程在鏈上看起來只是普通的多簽名操作。

1.4 DLC 的應用場景

DLC 開啟了比特幣上許多之前不可能實現的應用。

金融衍生品是最直接的應用。期貨、期權、差價合約都可以用 DLC 實現。例如，一個比特幣礦工可以使用 DLC 對沖未來的價格風險，而不需要依賴任何中心化交易所。

合成資產允許用戶獲得對其他資產（如股票、黃金、其他加密貨幣）的價格敞口，而只使用比特幣作為抵押品。這在傳統金融受限或不信任中心化服務的地區特別有價值。

保險合約也可以用 DLC 實現。航班延誤保險可以基於航班數據神諭自動結算；農業保險可以基於天氣數據；甚至健康保險的某些類型也可以這樣設計。

預測市場讓用戶可以對任何有明確結果的事件進行預測和投注。體育賽事、選舉結果、科學發現——只要有可靠的神諭能證明結果，就可以建立 DLC。

二、Vault 設計模式

2.1 為什麼需要 Vault？

比特幣的安全模型建立在私鑰控制上：誰擁有私鑰，誰就能花費對應的比特幣。這種模型簡單直接，但也意味著一旦私鑰洩露，資金立即面臨風險，而且通常無法追回。

Vault（金庫）是一種設計模式，旨在為這個問題提供一層額外的保護。它的核心思想是：即使熱密鑰（用於日常操作的密鑰）被盜，攻擊者也無法立即獲得資金。相反，任何提款嘗試都需要經過一段等待期，在此期間，真正的擁有者可以發現攻擊並採取行動——使用一個更安全的「恢復密鑰」將資金轉移到安全地址。

這個概念類似於傳統銀行的大額轉帳延遲或企業的多級審批流程。它創造了一個時間窗口，讓安全監控和人為干預成為可能。

2.2 使用預簽交易實現 Vault

在目前的比特幣腳本限制下，實現 Vault 的主要方法是使用預簽交易。這種方法有其局限性，但已經可以提供有價值的保護。

Vault 的結構包含兩種密鑰。熱密鑰用於發起提款，可能存儲在連接網路的設備上，面臨被盜的風險。恢復密鑰是高安全級別的密鑰，可能是多簽、分散在多個地理位置、或存儲在硬體錢包中，用於在緊急情況下恢復資金。

Vault 輸出的腳本設計有兩條路徑。第一條是正常提款路徑：使用熱密鑰簽名，將資金轉移到一個「Unvault」狀態，這個狀態有 CSV 時間鎖（例如一週）。第二條是緊急恢復路徑：使用恢復密鑰簽名，可以立即將資金轉移到預設的冷存儲地址。

Unvault 狀態同樣有兩條路徑。第一條是完成提款：等待 CSV 延遲期結束後，用熱密鑰簽名提取資金到目標地址。第二條是取消提款：使用恢復密鑰，立即將資金轉回冷存儲。

2.3 預簽交易的工作流程

設置 Vault 時，用戶需要預先簽署一系列交易。

首先是 Unvault 交易：從 Vault 輸出到 Unvault 狀態的轉換。然後是 Withdrawal 交易：從 Unvault 狀態到最終目的地的轉換，帶有 CSV 延遲。接著是 Recovery 交易：從 Vault 直接到冷存儲的緊急轉移。最後是 Cancel 交易：從 Unvault 狀態回到冷存儲的取消操作。

這些交易需要在存入資金之前就簽署好，而且必須安全存儲。特別是 Withdrawal 交易需要為每個可能的目的地預先準備，這限制了靈活性。

正常提款流程是：廣播 Unvault 交易，等待 CSV 延遲（例如 1008 個區塊，約一週），然後廣播 Withdrawal 交易。

緊急恢復流程是：發現異常活動（例如收到 Unvault 交易被廣播的警報），在延遲期結束之前，使用恢復密鑰廣播 Cancel 或 Recovery 交易。

2.4 當前 Vault 的限制

預簽交易方式的 Vault 有幾個顯著限制。

目的地必須預先確定：由於需要預先簽署 Withdrawal 交易，你必須在設置時就知道所有可能的提款目的地。這對於想要靈活提款的用戶來說很不方便。

金額不可分割：預簽交易鎖定了整個 Vault 的金額，無法只提取部分資金。

安全刪除問題：如果攻擊者獲得了預簽的交易副本，他們可以嘗試使用它。確保舊的預簽交易被完全銷毀是困難的。

手續費固定：預簽交易的手續費率在簽署時就確定了，無法適應未來的網路條件。

這些限制的根本原因是比特幣腳本目前無法「內省」交易本身——腳本無法檢查「這筆花費交易必須發送到特定地址」或「必須保持特定金額」。這正是 Covenant 提案試圖解決的問題。

三、Covenant：限制未來的花費方式

3.1 什麼是 Covenant？

Covenant（契約/公約）是一個密碼學和智能合約術語，指的是對 UTXO 未來如何被花費的限制。在目前的比特幣腳本中，你可以限制「誰」可以花費（透過簽名要求）和「何時」可以花費（透過時間鎖）。但你無法限制花費交易的其他屬性，如輸出的目的地、金額，或結構。

Covenant 填補了這個空白。有了 Covenant，你可以創建這樣的腳本：「這筆資金只能被轉移到以下三個地址之一」，或「提款必須分批進行，每次最多 10%」，或「這筆交易的找零必須回到同樣的 Covenant 保護下」。

這個能力看似簡單，但影響深遠。它使得許多目前不可能或需要信任的應用成為可能，同時也引發了關於審查和可替代性的擔憂。

3.2 主要的 Covenant 提案

比特幣社區正在討論幾個不同的 Covenant 實現方案，每個都有不同的功能範圍和權衡。

OP_CHECKTEMPLATEVERIFY（CTV，BIP 119）是最保守的提案。它允許腳本承諾一個精確的未來交易「模板」——包括輸出的數量、腳本、金額，以及鎖定時間。花費交易必須精確匹配這個模板。CTV 是功能最有限的 Covenant，但也因此最容易分析其安全性和影響。它已經經過多年審查，可能是最接近被激活的提案。

OP_VAULT（BIP 345）是專門為 Vault 用例設計的。它引入兩個新操作碼：OP_VAULT 和 OP_VAULT_RECOVER。OP_VAULT 創建一個可以被「觸發」進入等待狀態的輸出，然後在延遲後完成提款。OP_VAULT_RECOVER 允許在等待期間將資金恢復到安全地址。這個提案解決了預簽 Vault 的許多限制，允許靈活的目的地和部分提款。

OP_CAT（BIP 347）是一個被「復活」的提案。OP_CAT 在比特幣早期存在，但因為擔心記憶體攻擊而被禁用。現在提議在 Tapscript 中重新啟用它，並設置 520 位元組的輸出限制。OP_CAT 本身只是串接兩個堆疊元素，但它可以與其他現有操作碼組合，實現相當強大的 Covenant。透過在腳本中重建交易結構並驗證其雜湊，可以間接檢查交易的屬性。

更激進的提案如 OP_TXHASH 允許將交易的任何欄位的雜湊推入堆疊，提供完全的交易內省能力。這功能最強但也最有爭議，因為它可能對比特幣的審查抵抗性和可替代性產生影響。

3.3 CTV 的具體應用

讓我們看看 CTV 可以實現的一些具體應用。

擁塞控制（Congestion Control）是 CTV 最引人注目的用例。想像一個交易所需要同時處理 10,000 個用戶提款。在目前的系統中，這需要一筆巨大的交易（或多筆較大的交易），在網路擁塞時成本極高。

使用 CTV，交易所可以創建一棵「展開樹」。根交易只有一個輸出，承諾到特定的展開結構。這個輸出可以被展開成 100 個子輸出，每個子輸出又承諾到進一步的展開。最終，10,000 個用戶中的每一個都可以領取自己的資金。

優雅的是，這個展開可以是「惰性的」。根交易可以在費用便宜時上鏈，承諾了所有用戶的餘額。之後，每個用戶可以在任何時候展開自己的路徑來領取資金，而不需要其他用戶的配合。如果費用降低，可以一次展開更大的部分；如果費用上升，可以只展開自己關心的路徑。

另一個應用是改進的 Vault。有了 CTV，Vault 可以不需要預簽所有可能的提款交易。相反，Vault 輸出可以承諾一個模板，這個模板指定必須有一個回到同類型 Vault 的找零輸出，而提款金額可以是任意的。這解決了預簽 Vault 的金額不可分割問題。

3.4 Covenant 的擔憂

Covenant 的引入不是沒有爭議的。主要擔憂包括以下幾個方面。

審查向量：如果可以創建「只能轉移到特定地址」的比特幣，監管機構可能會要求交易所只接受「合規」的 Covenant 代幣。這可能導致不同等級的比特幣，損害可替代性。

複雜性增加：更強大的腳本功能意味著更多的攻擊面和更難審計的合約。已經有一些簡單的 bug 導致了資金損失，更複雜的系統可能會有更多這類問題。

遞迴 Covenant：某些 Covenant 設計（不包括 CTV）允許創建「永久」的限制，資金可能被永久困在某種結構中。這引發了關於比特幣長期可用性的擔憂。

支持者認為這些擔憂被誇大了。Covenant 是選擇加入的——如果你不想使用有限制的比特幣，你可以不接受它們。而其提供的功能——更好的自我託管安全、更高效的交易——對生態系統的價值超過了假設的風險。這個辯論仍在進行中。

四、BitVM：在比特幣上驗證任意計算

4.1 突破腳本限制的思路

比特幣腳本是有意設計為受限的——它不是圖靈完備的，沒有循環，操作碼有限。這是為了安全和可預測性。但如果我們想在比特幣上執行更複雜的邏輯怎麼辦？

BitVM 是 2023 年提出的一個突破性想法：不在鏈上執行計算，而是在鏈上驗證計算。這種模式稱為「樂觀執行」（Optimistic Execution），借鑑了以太坊 Optimistic Rollup 的概念。

核心思想是：如果雙方對計算結果有共識，就不需要任何鏈上驗證。只有當有人聲稱錯誤結果時，才需要在鏈上證明誰對誰錯。而且這個證明可以被設計得非常小，即使原始計算非常複雜。

4.2 挑戰-回應協議

BitVM 使用二分搜尋的挑戰-回應協議來定位錯誤。

假設 Operator 聲稱 f(x) = y，但 Verifier 認為正確答案應該是 y’。雙方的資金鎖定在一個需要正確結算的合約中。

協議開始時，Operator 發布整個計算軌跡的 Merkle 樹根。這個軌跡記錄了從輸入 x 到輸出 y 的每一步中間狀態。

然後進入二分搜尋。Verifier 選擇軌跡的前半部分或後半部分，要求 Operator 打開。Operator 提供所選部分的 Merkle 證明。如果這部分是正確的，Verifier 將搜尋範圍縮小到另一半；如果這部分已經有錯誤，繼續在這半部分搜尋。

經過 log(N) 輪互動（N 是計算步驟數），雙方定位到單個錯誤步驟。這一步可以在鏈上驗證——執行單個 NAND 門或類似的基本操作是比特幣腳本可以做到的。

如果 Operator 在這一步無法提供有效證明，Verifier 獲得 Operator 的質押金。如果 Operator 是誠實的，Verifier 無法找到錯誤步驟，Operator 保留資金。

4.3 BitVM 的應用

BitVM 最引人注目的應用是去信任的跨鏈橋。

目前的比特幣跨鏈橋大多依賴聯邦多簽：一組操作者控制比特幣端的資金，用戶需要信任他們不會共謀盜取資金。歷史上確實發生過多起橋被攻擊或內部作弊的事件。

使用 BitVM，橋可以這樣運作：用戶在比特幣上鎖定資金，在目標鏈（如以太坊）上收到等值代幣。當用戶想要贖回時，在目標鏈上銷毀代幣，然後 Operator 在比特幣上釋放資金給用戶。

如果 Operator 誠實，流程順利進行。如果 Operator 不釋放資金或嘗試欺詐，用戶（或任何觀察者）可以發起 BitVM 挑戰，證明 Operator 的聲明是錯誤的，從而獲得 Operator 的質押金並恢復資金。

這創造了一個「1-of-N」的信任模型：只要有一個誠實的 Verifier 在監控，欺詐就會被發現和懲罰。這比「M-of-N」的多簽模型安全得多，因為後者需要大多數參與者誠實。

其他應用包括 ZK 證明驗證（在比特幣上驗證零知識證明的正確性）、複雜的 DeFi 邏輯（借貸、自動做市商等，雖然互動性有限制）、以及計算密集型的合約（任何可以編譯成電路的程式）。

4.4 BitVM 的限制

BitVM 不是萬能的，它有顯著的限制。

互動性要求：挑戰協議需要雙方多輪互動。如果一方離線，協議可能超時。這使得 BitVM 更適合有明確交易對手的場景，而不是開放式的智能合約。

延遲：挑戰期（通常一到兩週）是必要的，以確保有足夠時間發現和證明欺詐。這意味著 BitVM 不適合需要即時結算的應用。

複雜性：實現一個安全的 BitVM 系統需要大量的工程努力。預簽交易的數量可能非常龐大，存儲和管理是挑戰。

有限的表達能力：雖然理論上可以驗證任意計算，但實際上受到電路大小和挑戰輪數的限制。

儘管有這些限制，BitVM 代表了在比特幣上實現更複雜邏輯的重要一步，而且不需要任何協議變更。

五、腳本優化實踐

5.1 大小與費用的關係

在比特幣中，交易費用主要由交易的「虛擬大小」（vbytes）決定。虛擬大小的計算考慮了 SegWit 的權重折扣：非 witness 數據每位元組計 4 個權重單位，witness 數據每位元組計 1 個權重單位。虛擬大小 = (總權重 + 3) / 4。

這意味著優化腳本大小可以直接節省費用。對於多簽名、複雜條件等場景，精心設計的腳本可能比樸素實現節省 20-30% 的費用。

5.2 實用優化技巧

利用隱式操作碼。OP_CHECKSIG 在失敗時會使整個腳本失敗，所以不需要額外的 OP_VERIFY。類似地，OP_EQUALVERIFY、OP_CHECKSIGVERIFY 等合併操作碼比分開的操作更緊湊。

重用堆疊元素。如果同一個值需要使用多次，用 OP_DUP 複製比再次推入堆疊更節省空間。

使用最短編碼。OP_1 到 OP_16 各只需 1 個位元組，而推入對應的數字需要 2 個位元組。負數和大數字的編碼也要注意使用最小表示。

優化 Taproot 腳本樹。將最可能使用的腳本放在樹的淺層（接近根部），這樣花費時需要揭示的 Merkle 路徑更短。對於多條件腳本，仔細分析每條路徑的使用概率。

考慮聚合。對於 n-of-n 多簽，使用 MuSig2 將所有簽名聚合成一個，這比 n 個獨立簽名節省大量空間。即使對於 m-of-n，有時候也可以設計備用的聚合路徑。

5.3 安全與效率的權衡

優化不能以犧牲安全為代價。一些需要注意的陷阱包括以下幾點。

不要跳過必要的驗證。例如，確保所有分支都正確終止，即使看起來「不可達」的分支也可能因為意外輸入而被執行。

注意簽名雜湊類型。SIGHASH_NONE 和 SIGHASH_SINGLE 可能意外地允許修改輸出，只有在完全理解其影響時才使用。

時間鎖需要安全邊際。區塊時間有波動，MTP 與實際時間可能有偏差。設計時間鎖時要留有餘裕。

測試所有路徑。使用腳本調試工具（如 btcdeb）測試腳本的每條可能執行路徑，包括失敗情況。

六、未來展望

6.1 當前腳本能力總結

讓我們總結一下比特幣腳本目前能做什麼和不能做什麼。

可以做到的包括：各種簽名驗證（單簽、多簽、聚合簽名）、絕對和相對時間鎖、雜湊鎖和 HTLC、複雜的條件邏輯、Taproot 的隱藏腳本樹、預簽交易實現的 Vault、依賴神諭的 DLC、透過樂觀執行的任意計算驗證（BitVM）。

無法直接做到（需要協議升級）的包括：檢查花費交易的輸出目的地、檢查花費交易的輸出金額、循環和遞迴計算、原生的零知識證明驗證、完全靈活的 Covenant。

6.2 可能的協議升級

比特幣的升級過程謹慎而緩慢，但社區正在積極討論幾個可能的改進。

短期可能實現的包括：OP_CTV 已經過多年審查，有可能在未來幾年內透過軟分叉激活。它將啟用擁塞控制和改進的 Vault，同時風險相對較低。

OP_CAT 的復活也在討論中。雖然它單獨功能有限，但與現有操作碼組合可以實現許多 Covenant 用例。由於 Tapscript 有堆疊元素大小限制，早期的安全擔憂已大大減輕。

中期可能探索的包括：OP_VAULT 提供了專門的 Vault 功能，比通用 Covenant 更容易分析影響。SIGHASH_ANYPREVOUT 允許更好的閃電網路協議（如 Eltoo），可能與其他升級一起打包。

長期研究方向包括：原生 ZK 驗證將允許在比特幣上直接驗證零知識證明，這對可擴展性和隱私有深遠影響。更強大的 Covenant 和腳本能力也在研究中，但需要在功能和風險之間找到平衡。

6.3 生態系統的發展

除了協議層面的變化，比特幣腳本的應用生態也在快速發展。

工具鏈在改進。Miniscript 提供了一種更安全的方式來編寫和分析腳本，許多錢包和服務正在採用。腳本調試、形式驗證、自動測試工具都在進步。

標準化在推進。描述符（Descriptors）成為錢包備份和恢復的標準格式。PSBT 使多方協作更加容易。MuSig2 的廣泛採用提升了多簽的效率和隱私。

應用在擴展。閃電網路持續增長，DLC 平台開始上線，Vault 解決方案進入生產環境。這些應用驗證了比特幣腳本的實用性，也推動了進一步的創新。

七、實作練習

練習 1：設計 DLC 結構

選擇一個簡單的二元事件（如「明天會下雨嗎？」），設計完整的 DLC 結構。考慮：如何找到可靠的神諭？如何處理神諭不發布結果的情況？計算需要多少個 CET。

練習 2：預簽 Vault 實現

使用你熟悉的比特幣程式庫，實現一個簡化的預簽 Vault。包括：創建 Vault 輸出、預簽 Unvault 和 Withdrawal 交易、模擬正常提款和緊急恢復流程。思考在生產環境中需要解決的額外問題。

練習 3：CTV 擁塞控制模擬

假設 CTV 已經激活，設計一個擁塞控制樹來處理 1000 個接收者的批量支付。計算不同樹結構（深度、分支因子）的權衡，比較與傳統大交易的費用差異。

八、總結

這一系列文章帶你從比特幣腳本的基礎走到了最前沿的應用。讓我們回顧關鍵要點。

比特幣腳本是一個有意設計為受限的系統，它不是為了與以太坊競爭「智能合約平台」的地位，而是為了提供安全、可驗證、可預測的價值轉移能力。在這個設計空間內，我們仍然可以構建令人印象深刻的應用。

多簽和時間鎖是兩個最基本的構建塊。多簽將控制權從單點分散到多點，時間鎖在時間維度上增加條件。這兩者的組合（加上哈希鎖）使得 HTLC 成為可能，而 HTLC 是閃電網路和原子交換的基礎。

Taproot 是腳本能力的一次重大飛躍。透過 MAST 結構，複雜的條件邏輯可以保持隱藏；透過 Schnorr 簽名，多方協作可以看起來像單方操作。這對隱私和效率都有深遠影響。

DLC、Vault、BitVM 代表了在現有能力下的極限探索。它們展示了創意和密碼學如何突破表面的限制，實現之前認為不可能的功能。

Covenant 的討論反映了比特幣社區在功能擴展和風險控制之間的持續權衡。這不是一個簡單的技術問題，而是涉及經濟激勵、審查抵抗、長期可持續性的複雜考量。

無論未來如何發展，理解比特幣腳本的當前能力和限制對於任何比特幣開發者都是必要的。希望這個系列給你提供了一個堅實的基礎。

參考資料

DLC 規範 - DLC 的正式規格
BIP 119: OP_CHECKTEMPLATEVERIFY - CTV 提案
BIP 345: OP_VAULT - Vault 專用操作碼提案
BIP 347: OP_CAT - OP_CAT 復活提案
BitVM 白皮書 - BitVM 的原始論文
Covenant 資訊集合 - 各種 Covenant 提案的比較
Bitcoin Optech - 比特幣技術的最新發展
Miniscript - 更安全的腳本編寫方式

Bitcoin Script 實戰教學（五）：時間鎖機制完全指南

2025-03-19T00:00:00+00:00

系列導言

這是「Bitcoin Script 實戰教學」系列的第五篇。本篇將深入探討時間鎖機制——比特幣腳本中控制「何時」可以花費資金的強大工具。時間鎖是構建支付通道、閃電網路、原子交換等進階應用的基礎技術，理解它對於掌握比特幣智能合約至關重要。

系列文章：

基礎概念與操作碼
標準腳本類型詳解
SegWit 與 Taproot
多重簽名完全指南
時間鎖機制完全指南（本篇）
進階應用與智能合約

一、理解時間鎖

1.1 什麼是時間鎖？

在日常生活中，我們經常遇到時間相關的限制：銀行定存有到期日、支票可以開立遠期支票、遺囑在當事人去世前無效。時間鎖（Timelock）在比特幣中實現了類似的概念：它允許我們設定條件，使得資金只能在特定時間之後才能被花費。

這個看似簡單的功能，實際上是構建複雜金融應用的基石。想像一下：如果沒有時間鎖，就無法實現「如果三天內交易沒有完成，資金自動退回」這樣的條件。而這恰恰是跨鏈原子交換和閃電網路的核心需求。

比特幣支援兩種基本類型的時間鎖：絕對時間鎖指定一個具體的時間點或區塊高度，資金在此之前無法花費；相對時間鎖則指定一個時間長度，從 UTXO 被創建（確認）後開始計算，經過這段時間後資金才能花費。

1.2 時間的表示方式

比特幣的時間鎖使用一個巧妙的機制來區分區塊高度和 Unix 時間戳：如果數值小於 5 億（500,000,000），它被解釋為區塊高度；如果大於或等於 5 億，它被解釋為 Unix 時間戳。

選擇 5 億作為分界點是經過深思熟慮的。比特幣大約每 10 分鐘產生一個區塊，按此速度計算，達到 5 億區塊需要大約 9,500 年。而 5 億秒作為 Unix 時間戳，對應的是 1985 年 11 月——這顯然已經過去了。因此，這個分界點在可預見的未來都不會造成歧義。

區塊高度作為時間度量有其獨特優勢：它不受時區影響，且與比特幣網路的實際進展直接相關。但區塊產生時間有波動（可能 5 分鐘也可能 20 分鐘），所以對於需要精確時間的場景，時間戳可能更合適。

值得注意的是，比特幣的時間戳驗證不使用當前時間，而是使用「中位時間過去」（Median Time Past，MTP）——過去 11 個區塊時間戳的中位數。這個設計防止了礦工通過操縱單個區塊的時間戳來影響時間鎖。

1.3 四種時間鎖機制

比特幣實現了四種不同層級的時間鎖機制，可以按照兩個維度進行分類。

按時間類型分：nLocktime 和 CLTV 是絕對時間鎖，指定具體的時間點或區塊高度；nSequence 和 CSV 是相對時間鎖，指定從 UTXO 確認後經過的時間。

按實現層級分：nLocktime 和 nSequence 是交易層級的機制，它們影響整個交易何時可以被打包進區塊；CLTV 和 CSV 是腳本層級的機制，它們作為腳本中的操作碼，在花費時驗證時間條件。

這四種機制各有其設計目的和適用場景，接下來我們將逐一深入探討。

二、nLocktime：交易層級絕對時間鎖

2.1 設計與歷史

nLocktime 是比特幣最早的時間鎖機制，從創世區塊就存在。它是交易結構的一部分，佔據交易末尾的 4 個位元組。這個欄位的設計初衷是實現一種稱為「高頻交易通道」的功能——允許雙方在鏈下快速更新交易，但這個機制從未完整實現。

nLocktime 的工作原理相當直接：如果設置了一個非零的 nLocktime 值，這筆交易在指定的時間或區塊高度之前，不會被礦工打包進區塊，也不會被節點接受進記憶池。

2.2 啟用條件

nLocktime 的啟用需要一個額外條件：交易中至少有一個輸入的 sequence 欄位不等於 0xFFFFFFFF（最大值）。這個設計源於 sequence 欄位的原始用途——允許透過遞增 sequence 來更新未確認交易。當所有輸入的 sequence 都是最大值時，表示交易是「最終的」，nLocktime 將被忽略。

這個機制在實踐中造成了一些混淆。許多錢包軟體在不需要時間鎖時會將 sequence 設為 0xFFFFFFFF，此時即使設置了 nLocktime 也不會生效。如果你要使用 nLocktime，確保至少一個輸入的 sequence 小於最大值——通常使用 0xFFFFFFFE。

2.3 實際應用與限制

nLocktime 最常見的應用是創建「延遲支付」——一筆在未來某個時間點才生效的交易。例如，你可以創建一筆 nLocktime 設為一週後的交易，作為對某人的承諾，但保留在此之前取消的能力。

然而，nLocktime 有一個根本性的限制：它只是「紳士協定」。持有私鑰的人可以隨時創建一筆新交易（沒有時間鎖），花費相同的輸入。nLocktime 交易要等到解鎖時間才能廣播，而在此之前，發送者完全可以反悔。

這個限制意味著 nLocktime 不適合需要強制執行的場景。接收者無法確信資金真的會在未來到達——發送者可能在到期前花掉這些幣。對於這些場景，我們需要腳本層級的時間鎖。

2.4 記憶池行為

另一個實用性問題是記憶池的處理方式。目前的比特幣節點不會接受 nLocktime 尚未解鎖的交易進入記憶池。這意味著你不能提前將交易發送到網路上「等待」——你需要自己保管這筆交易，直到時間到了再廣播。

這對用戶體驗有明顯影響：你必須確保在正確的時間上線並廣播交易，或者依賴第三方服務來代為執行。

三、OP_CHECKLOCKTIMEVERIFY（CLTV）

3.1 從交易層級到腳本層級

CLTV（Check Lock Time Verify）透過 BIP 65 在 2015 年底引入，填補了 nLocktime 留下的空白。與 nLocktime 不同，CLTV 是一個腳本操作碼，在腳本執行時強制檢查時間條件。

CLTV 的設計非常精巧：它讀取堆疊頂端的值作為時間鎖，然後驗證花費這筆輸出的交易的 nLocktime 是否滿足條件。注意，CLTV 本身不消耗堆疊上的值——這是為了兼容性考慮。因此，使用 CLTV 後通常需要 OP_DROP 來清理堆疊。

3.2 執行規則

CLTV 的驗證邏輯檢查幾個條件。首先，堆疊頂端的值必須是非負數。其次，堆疊頂端的值和交易的 nLocktime 必須使用相同的時間類型——兩者都小於 5 億（區塊高度）或都大於等於 5 億（時間戳）。混合使用會導致腳本失敗。

最關鍵的檢查是：交易的 nLocktime 必須大於或等於腳本中指定的值。這確保了交易至少要等到腳本規定的時間才能被確認。

此外，CLTV 還要求花費這個輸出的輸入的 sequence 不能是 0xFFFFFFFF，因為那會禁用 nLocktime 機制。

3.3 為什麼 CLTV 無法繞過

CLTV 解決了 nLocktime 的「可繞過」問題。一旦資金被發送到包含 CLTV 的腳本地址，就沒有任何方法可以在指定時間之前花費它——即使所有相關私鑰的持有者都同意也不行。

這是因為 CLTV 條件被編碼在腳本中，而腳本是輸出的一部分。花費這個輸出的任何交易都必須滿足腳本條件，沒有例外。唯一的方法是等待時間到期。

3.4 應用場景：遺產規劃

CLTV 的經典應用之一是遺產規劃。考慮這樣的場景：Alice 想要確保如果她發生意外，她的比特幣可以被她的女兒 Carol 繼承。但她不想現在就把控制權交給 Carol。

使用 CLTV，Alice 可以創建一個這樣的腳本：正常情況下 Alice 可以用自己的簽名花費；但如果腳本中的時間條件滿足（比如五年後），Carol 也可以用她的簽名花費。Alice 可以每隔幾年將資金轉移到新的腳本（更新時間鎖），只要她仍然健在。

這個方案不需要任何信任的第三方，不需要律師或託管服務。時間鎖由比特幣協議本身強制執行。

3.5 應用場景：分期解鎖

另一個常見應用是分期解鎖，用於員工股權激勵或投資者鎖倉。假設公司承諾給員工分四年發放比特幣獎勵，每年解鎖 25%。

公司可以創建四個獨立的 UTXO，每個包含總獎勵的 25%，並設置不同的 CLTV 時間鎖：第一個一年後解鎖，第二個兩年後，依此類推。這樣員工可以確信公司無法撤銷承諾（除非員工把私鑰給了公司），而公司也知道員工不能提前取走資金。

四、nSequence：相對時間鎖基礎

4.1 從失敗的設計到重獲新生

nSequence 欄位的歷史頗為曲折。在比特幣最初的設計中，中本聰構想了一種機制：未確認交易可以透過提高 sequence 數字來「更新」。較高 sequence 的交易會取代較低的版本，而礦工會優先打包 sequence 最大的交易。

這個設計從未正確實現，原因是它存在嚴重的激勵問題。礦工沒有義務遵守這個規則——他們可以打包任何有效交易，包括低 sequence 但高手續費的版本。這讓整個機制變得不可靠。

多年來，sequence 欄位基本上被忽略，大多數錢包將其設為最大值。直到 2016 年，BIP 68 重新定義了這個欄位的語義，賦予它相對時間鎖的新功能。

4.2 BIP 68 的語義定義

BIP 68 對 sequence 欄位進行了精確的位元定義。最高位（bit 31）是禁用標誌：如果設置，這個輸入不受相對時間鎖限制。第 22 位是類型標誌：如果設置，時間鎖以 512 秒為單位計算；否則以區塊數計算。最低 16 位（bits 0-15）是實際的鎖定值。

這個設計允許的最大相對時間鎖是 65,535 個區塊（約 455 天）或 65,535 × 512 秒（約 388 天）。對於大多數應用場景，這已經足夠了。

選擇 512 秒（約 8.5 分鐘）作為時間單位而不是秒，是為了匹配比特幣的區塊時間粒度。這也意味著時間鎖的精度大約是 8 分鐘，對於大多數場景來說足夠精確。

4.3 相對時間鎖的含義

與絕對時間鎖不同，相對時間鎖的起點是 UTXO 被確認的時間，而不是某個固定時間點。這有重要的實際意義：你不需要預先知道 UTXO 何時會被創建，只需要指定「創建後需要等待多久」。

考慮一個支付通道的關閉場景：當一方單方面廣播關閉交易時，另一方需要時間來檢測和回應。相對時間鎖確保無論通道何時關閉，都有固定的「挑戰期」。如果使用絕對時間鎖，你需要在通道開設時就預測可能的關閉時間，這是不切實際的。

4.4 與 nLocktime 的交互

nSequence 的相對時間鎖與 nLocktime 的絕對時間鎖可以同時使用。規則是：一個交易要被接受，必須同時滿足 nLocktime 條件和所有輸入的 nSequence 條件。

這創造了一些有趣的可能性。例如，一個交易可以被設計成「在 2025 年 1 月 1 日之後，且在輸入被創建一週後」才能被確認。兩個條件都必須滿足。

五、OP_CHECKSEQUENCEVERIFY（CSV）

5.1 將相對時間鎖帶入腳本

CSV（Check Sequence Verify）透過 BIP 112 引入，是相對時間鎖在腳本層級的實現。與 CLTV 類似，CSV 讀取堆疊頂端的值，並驗證花費交易的對應輸入的 sequence 是否滿足條件。

CSV 需要交易版本至少為 2。這是因為 BIP 68 的 sequence 語義只適用於版本 2 及以上的交易，舊版本交易的 sequence 欄位沒有時間鎖含義。

5.2 執行規則

CSV 的驗證邏輯首先檢查堆疊值的禁用位（bit 31）。如果設置了禁用位，CSV 成為無操作——直接成功，不做任何檢查。這允許腳本在某些條件下「跳過」時間鎖。

如果禁用位未設置，CSV 驗證：交易版本至少為 2；輸入的 sequence 禁用位未設置；堆疊值和 sequence 使用相同的時間類型（都是區塊或都是時間）；sequence 的鎖定值大於或等於堆疊值的鎖定值。

5.3 支付通道中的核心作用

CSV 在支付通道和閃電網路中扮演著核心角色。讓我們看看為什麼。

在雙向支付通道中，雙方可以離線更新通道狀態（餘額分配）。但這創造了一個問題：任何一方都可以廣播舊的狀態，試圖獲取比應得更多的資金。這被稱為「通道關閉欺詐」。

解決方案是使用 CSV 創建「挑戰期」。當一方廣播關閉交易時，他們的資金不能立即提取，必須等待一段時間（例如一週）。在這段時間內，另一方可以提交證據證明這是舊狀態，並取走所有資金作為懲罰。

這個「撤銷」機制的關鍵在於相對時間鎖：無論何時關閉通道，都有固定的挑戰期。如果使用絕對時間鎖，長期運行的通道將面臨時間鎖過期的問題。

5.4 可撤銷輸出腳本

閃電網路的承諾交易使用一種稱為「可撤銷輸出」的模式。當通道更新時，雙方交換前一狀態的「撤銷密鑰」。如果任何一方廣播舊狀態，對方可以使用撤銷密鑰立即取走所有資金。

這個腳本通常這樣設計：有兩條花費路徑。第一條是撤銷路徑——對方可以用撤銷密鑰簽名，立即花費。第二條是延遲路徑——擁有者需要等待 CSV 延遲期，然後用自己的簽名花費。

如果廣播的是最新狀態，對方沒有撤銷密鑰，只能等待延遲期結束後資金被正當領取。如果廣播的是舊狀態，對方持有撤銷密鑰，可以在延遲期內取走所有資金。這創造了強大的不作弊激勵。

六、HTLC：時間鎖與哈希鎖的結合

6.1 核心概念

HTLC（Hash Time Locked Contract，哈希時間鎖定合約）是時間鎖最重要的應用之一，結合了哈希鎖和時間鎖，創造出一種條件支付機制：收款人必須在限定時間內提供一個秘密（原像），否則資金會退回給付款人。

HTLC 的結構包含兩條路徑。成功路徑要求收款人提供一個值 preimage，使得 HASH160(preimage) 等於預設的 payment_hash，同時提供有效簽名。退款路徑允許付款人在時間鎖過期後，用自己的簽名取回資金。

這個機制的精妙之處在於：付款人創建 HTLC 時並不知道原像，只有收款人知道。收款人透過揭示原像來「領取」支付，而這個揭示動作是公開的——任何看到原像的人都可以用它來解鎖其他使用相同 payment_hash 的 HTLC。

6.2 原子交換

HTLC 最早的應用之一是跨鏈原子交換。假設 Alice 有 BTC 想要換取 Bob 的 LTC。傳統方法需要信任：誰先發送誰就面臨對方不履約的風險。HTLC 消除了這種信任需求。

流程如下：Alice 首先生成一個隨機的 preimage 並計算 payment_hash。她在比特幣鏈上創建一個 HTLC，將 BTC 鎖定給 Bob，條件是 Bob 需要提供這個 preimage。Alice 設置較長的超時時間，比如 48 小時。

Bob 看到 Alice 的 HTLC 後，在萊特幣鏈上創建對應的 HTLC，將 LTC 鎖定給 Alice，使用相同的 payment_hash。Bob 設置較短的超時時間，比如 24 小時。

現在 Alice 可以安全地領取 LTC：她用 preimage 解鎖 Bob 在萊特幣鏈上的 HTLC。這個動作會將 preimage 公開在萊特幣鏈上。

Bob 從萊特幣鏈上看到 preimage，用它來解鎖 Alice 在比特幣鏈上的 HTLC，獲取 BTC。

如果 Alice 不領取 LTC（可能她改變主意了），兩個 HTLC 都會超時：Bob 取回 LTC，Alice 取回 BTC。沒有人損失資金。

超時時間的差異很重要：Alice 必須有足夠時間在 Bob 取回 LTC 之前領取它。如果兩個超時相同，Bob 可能在 Alice 領取 LTC 的同時取回它，造成 Alice 揭示了 preimage 卻沒有拿到 LTC，而 Bob 用這個 preimage 拿走 BTC。

6.3 閃電網路支付

閃電網路將 HTLC 的原理發揮到極致。在閃電網路中，支付可以透過多個節點中繼，每一跳都使用 HTLC 來保證原子性——要麼整條路徑上的所有 HTLC 都被解鎖，要麼都超時退回。

假設 Alice 要透過 Bob（路由節點）支付給 Carol。首先，Carol 生成 preimage 和 payment_hash，將 payment_hash 告訴 Alice。Alice 在她和 Bob 的通道中創建一個 HTLC（支付給 Bob，條件是 Bob 提供 preimage）。Bob 在他和 Carol 的通道中創建對應的 HTLC（支付給 Carol，同樣的 payment_hash）。Carol 用 preimage 領取 Bob 的 HTLC。Bob 從 Carol 那裡獲得 preimage，用它領取 Alice 的 HTLC。

整個過程中，只有最終收款人 Carol 知道 preimage。當她揭示它時，支付沿著路徑回溯結算。每個節點都有足夠的時間完成自己的部分，因為超時時間沿著路徑遞減。

6.4 超時差與安全性

HTLC 路由中的超時差（cltv_expiry_delta）是關鍵的安全參數。每個路由節點需要確保自己有足夠時間：在上游 HTLC 超時之前，有時間發現下游 HTLC 被領取（或超時），並相應地處理上游 HTLC。

如果超時差太小，可能發生這樣的情況：上游 HTLC 即將超時，付款人廣播退款交易。同時，下游收款人廣播領取交易。中間節點可能既無法領取上游（因為超時了）也無法阻止下游（因為已經成功），導致損失。

閃電網路的 BOLT 規範建議每跳至少 40 個區塊（約 6.7 小時）的超時差，以確保在各種網路延遲和區塊重組情況下的安全性。

七、時間鎖的安全考量

7.1 時間戳操縱

礦工對區塊時間戳有一定的調整空間。規則允許時間戳比前一區塊向前最多 2 小時，且必須大於 MTP。這意味著單個礦工可以將時間戳設得比真實時間略早或略晚。

對於使用時間戳的時間鎖來說，這創造了一些不確定性。一個設定在特定時間解鎖的 HTLC，實際解鎖時間可能比預期早或晚幾個小時。對於高價值或時間敏感的應用，使用區塊高度通常更可預測。

MTP 機制減輕了這個問題的嚴重性。操縱 MTP 需要控制連續多個區塊的時間戳，這對於沒有大量算力的攻擊者來說是不切實際的。

7.2 費用炒作攻擊

在時間鎖即將到期時，可能出現費用競爭的情況。考慮一個 HTLC：收款人想要領取，而付款人想要退款。如果兩個交易在接近超時時同時廣播，誰的交易被打包取決於手續費。

這可能導致「費用炒作」——雙方不斷提高手續費試圖讓自己的交易被優先打包。在極端情況下，手續費可能接近甚至超過 HTLC 的價值。

解決方案是設計合理的超時差，確保一方有明確的時間窗口來行動。此外，一些協議使用「預簽名」交易，在 HTLC 創建時就鎖定手續費率，避免後續競價。

7.3 區塊鏈重組風險

區塊鏈重組可能影響時間鎖的行為。如果一個 HTLC 被領取的交易所在區塊被重組掉，preimage 的揭示可能被「逆轉」。對於跨鏈原子交換，這創造了風險：一條鏈上的支付被確認（多次），而另一條鏈發生重組。

緩解措施包括：等待足夠多的確認（特別是對於高價值交易）；設計超時時間時考慮可能的重組；在關鍵操作前檢查對手方鏈的確認深度。

八、Taproot 時代的時間鎖

8.1 隱私提升

Taproot 為時間鎖應用帶來了顯著的隱私改進。傳統的 HTLC 在花費時會揭示整個腳本結構，觀察者可以清楚看到這是一個條件支付。而在 Taproot 中，時間鎖條件可以隱藏在腳本樹中。

如果大多數情況下雙方合作（例如閃電網路通道正常關閉），他們可以使用 key path 花費——在鏈上看起來就像普通的單簽名交易。時間鎖路徑只有在需要時才會揭示，而且只揭示使用的那個分支，其他備用路徑保持完全隱藏。

這意味著大多數閃電網路交易在鏈上將無法與普通交易區分，大幅提升整個網路的隱私性。

8.2 效率優化

除了隱私，Taproot 還帶來效率提升。傳統 HTLC 需要在每次花費時揭示完整腳本，包括所有公鑰、哈希值、時間鎖等。Taproot 的 key path 只需要一個 64 位元組的簽名，是可能的最小見證大小。

即使使用 script path，也只需要揭示實際使用的腳本分支和 Merkle 證明，而不是整個腳本。對於有多個條件分支的複雜合約，這可以節省大量空間。

8.3 PTLCs：超越 HTLC

Taproot 還使得 PTLC（Point Time Locked Contract）成為可能，這是 HTLC 的進化版本。PTLC 使用「adaptor signatures」代替哈希鎖，提供了幾個重要優勢。

首先是隱私。HTLC 的 payment_hash 在整條支付路徑上是相同的，這創造了關聯性——知道入口和出口 payment_hash 相同的觀察者可以追蹤支付。PTLC 在每一跳使用不同的密碼學「謎題」，打斷了這種關聯。

其次是多路徑支付的原子性。將大額支付分成多條路徑時，HTLC 方案中的 preimage 一旦在任何路徑上揭示，就可能被用來領取其他路徑。PTLC 可以設計成真正原子的多路徑支付。

PTLC 的廣泛採用需要閃電網路生態的升級，這正在逐步進行中。

九、實作練習

練習 1：CLTV 遺產腳本

設計一個遺產規劃腳本：擁有者可以隨時花費，繼承人在指定日期後可以花費。計算正確的 CLTV 值（使用 Unix 時間戳），構建完整的 witness script，生成 P2WSH 地址。

練習 2：CSV 支付通道

設計一個簡化版的支付通道關閉腳本：雙方可以合作即時關閉（2-of-2 多簽），發起者需要等待 1008 區塊後才能單方面關閉。思考為什麼發起者需要延遲而接收者不需要。

練習 3：完整 HTLC 生命週期

模擬一個 HTLC 的完整生命週期：生成 preimage 和 payment_hash，構建 HTLC 腳本，模擬成功領取路徑的見證構造，模擬超時退款路徑的見證構造。比較兩種路徑的不同要求。

十、小結

本篇我們深入探討了比特幣的時間鎖機制：

nLocktime 是最早的時間鎖，在交易層級工作，但可以被持有私鑰者繞過。它主要用於「延遲」交易廣播，而非強制執行時間條件。

CLTV 將絕對時間鎖帶入腳本層級，透過共識規則強制執行，無法繞過。它適用於需要指定具體日期或區塊高度的場景，如遺產規劃、分期解鎖等。

nSequence 經過 BIP 68 重新定義，實現了交易層級的相對時間鎖。它指定從 UTXO 確認開始必須等待的時間，是支付通道的基礎。

CSV 是相對時間鎖的腳本版本，同樣透過共識強制執行。它是閃電網路中「挑戰期」機制的核心，確保欺詐行為有時間被發現和懲罰。

HTLC 結合了哈希鎖和時間鎖，創造了條件支付的能力。它是原子交換和閃電網路多跳支付的基礎，確保「要麼全部成功，要麼全部退款」的原子性。

時間鎖從單純的「延遲」功能，演進成構建複雜金融協議的核心原語。理解這些機制如何工作，是掌握比特幣智能合約的關鍵一步。

下一篇預告

在本系列的最後一篇文章中，我們將探討 Bitcoin Script 的進階應用，包括 Vault 設計模式、Discreet Log Contracts（DLC）的基礎概念、以及腳本優化技巧。我們還會展望比特幣腳本未來可能的發展方向，如 OP_CAT、OP_CTV 等提案。

參考資料

BIP 65: OP_CHECKLOCKTIMEVERIFY - CLTV 的原始規格
BIP 68: Relative Lock-time - nSequence 相對時間鎖語義
BIP 112: OP_CHECKSEQUENCEVERIFY - CSV 的原始規格
BIP 113: Median Time-past - MTP 時間計算規則
BOLT #3: Transactions - 閃電網路交易格式
BOLT #5: On-chain Handling - 閃電網路鏈上處理建議
Bitcoin Optech: Timelocks - 時間鎖主題深入解析

Bitcoin Script 實戰教學（四）：多重簽名完全指南

2025-03-18T00:00:00+00:00

系列導言

這是「Bitcoin Script 實戰教學」系列的第四篇。本篇將全面探討多重簽名的各種實現方式，從傳統的 OP_CHECKMULTISIG 到現代的 MuSig2。多重簽名是比特幣腳本系統最重要的應用之一，它將比特幣的安全性從單一密鑰提升到分散式信任模型，為個人資產保護、企業財務管理、以及複雜的智能合約奠定了基礎。

系列文章：

基礎概念與操作碼
標準腳本類型詳解
SegWit 與 Taproot
多重簽名完全指南（本篇）
時間鎖機制
進階應用與智能合約

一、理解多重簽名

1.1 從單簽名到多重簽名

在傳統的比特幣交易中，一個私鑰對應一個地址，擁有私鑰就能完全控制該地址下的所有資金。這種模型簡單直接，但也有明顯的風險：私鑰一旦丟失或被盜，資金就永久無法恢復或被竊取。

多重簽名（Multisignature，簡稱 Multisig）是一種需要多個私鑰授權才能花費資金的機制。它通常用 m-of-n 的形式表示，其中 n 是參與的公鑰總數，m 是需要的最少簽名數量。例如，2-of-3 多重簽名意味著有三個人各持有一把私鑰，但只需要其中任意兩人簽名就能花費資金。

這個看似簡單的概念帶來了深遠的影響。它讓我們能夠設計出容錯性更強的資產保管方案，建立需要多方同意的企業財務系統，甚至構建去中心化的協議層應用。

1.2 為什麼需要多重簽名？

多重簽名解決了加密貨幣管理中的幾個核心問題。

首先是安全性問題。即使你的一把私鑰被盜，攻擊者也無法動用資金，因為他們還需要獲取其他密鑰。這種「冗餘安全」的概念與傳統銀行保險箱需要兩把鑰匙的原理類似，但在數位領域實現得更加優雅。

其次是可恢復性問題。在 2-of-3 配置中，即使你丟失了一把私鑰，仍然可以使用剩餘的兩把密鑰恢復對資金的控制。這大大降低了「因為忘記密碼而永久失去比特幣」這類悲劇發生的可能性。

第三是治理問題。對於企業或組織來說，重大財務決策不應該由單一個人控制。多重簽名可以確保資金的動用需要多個授權人的同意，這與傳統公司治理中的多人簽核流程相呼應。

最後是信任最小化。在涉及多方的交易場景中，例如託管服務或去中心化交易，多重簽名可以設計出不需要完全信任任何單一方的解決方案。經典的 2-of-3 託管就是一個例子：買家、賣家、仲裁者各持一把密鑰，正常情況下買賣雙方完成交易，只有發生爭議時才需要仲裁者介入。

1.3 多重簽名的歷史演進

比特幣的多重簽名經歷了三個主要的發展階段，每個階段都帶來了效率和隱私的顯著提升。

第一階段是 2012 年隨 BIP 16 引入的 P2SH 多重簽名。這是最早被廣泛採用的標準化多簽方案，使用 OP_CHECKMULTISIG 操作碼在腳本層面驗證多個簽名。雖然這種方法功能完善，但它需要在鏈上暴露所有公鑰和所需的所有簽名，導致較大的交易體積和較高的費用。

第二階段是 2017 年 SegWit 帶來的 P2WSH 多重簽名。這種方式在功能上與 P2SH 類似，但由於簽名數據被放入 witness 區域並享受費用折扣，實際成本下降了約 35%。同時，使用 SHA256 替代 HASH160 也提升了密碼學安全性。

第三階段是 2021 年 Taproot 啟動後帶來的革命性變化。透過 Schnorr 簽名的線性特性，多個簽名現在可以被聚合成一個單一簽名，在鏈上看起來與普通的單簽名交易完全相同。這不僅大幅降低了費用，更重要的是提供了前所未有的隱私保護——外部觀察者無法判斷一筆交易是單人控制還是需要多方授權。

二、傳統多重簽名詳解

2.1 OP_CHECKMULTISIG 的工作原理

OP_CHECKMULTISIG 是比特幣最早支援多重簽名的操作碼。它的設計相當直接：從堆疊中取出一組公鑰和一組簽名，然後驗證是否有足夠數量的有效簽名。

一個 2-of-3 多重簽名的贖回腳本（Redeem Script）看起來像這樣：

OP_2    OP_3 OP_CHECKMULTISIG

這個腳本的含義是：這裡有三個公鑰，需要其中兩個對應的有效簽名才能花費這筆資金。OP_2 指定需要的簽名數量，OP_3 指定公鑰的總數，而 OP_CHECKMULTISIG 執行實際的驗證邏輯。

當花費這筆資金時，ScriptSig（解鎖腳本）需要提供簽名和原始的贖回腳本：

OP_0   

這裡的 OP_0 是一個看起來奇怪但必需的元素，稍後我們會解釋它的存在原因。

2.2 臭名昭著的 off-by-one Bug

OP_CHECKMULTISIG 有一個從比特幣誕生之初就存在的程式錯誤：它會從堆疊中多彈出一個元素。這個被稱為「off-by-one bug」的問題源於原始程式碼中的一個索引錯誤。

具體來說，在驗證完所有簽名之後，操作碼會嘗試彈出一個額外的元素。如果堆疊中沒有這個元素，腳本就會失敗。更糟糕的是，彈出的這個元素被完全忽略——它不參與任何驗證邏輯。

為了讓腳本正確執行，使用者必須在簽名之前放置一個「啞」元素。這個元素可以是任何值，因為它反正會被忽略。慣例上使用 OP_0（空位元組），這就是為什麼你會在所有多簽 ScriptSig 的開頭看到這個看似莫名其妙的零值。

為什麼這個 bug 沒有被修復？因為比特幣的共識規則是神聖不可侵犯的。任何改變腳本驗證行為的修改都可能導致原本有效的交易變得無效，從而引發網路分裂。這個 bug 作為「歷史遺產」被永久保留了下來。

不過，BIP 147 引入了一個軟分叉規則（NULLDUMMY），要求這個啞元素必須是空位元組 OP_0。這防止了一類潛在的交易延展性攻擊，因為在此之前，這個被忽略的元素可以被第三方任意修改而不影響交易有效性。

2.3 簽名順序的限制

OP_CHECKMULTISIG 還有一個重要的限制：簽名必須按照公鑰在腳本中出現的順序排列。這意味著如果你有公鑰 A、B、C，而且只有 A 和 C 簽名了，你不能提供簽名順序為 C、A——必須是 A、C。

這個設計選擇是為了簡化驗證邏輯。操作碼按順序遍歷公鑰，對每個簽名嘗試用下一個未匹配的公鑰驗證。一旦匹配成功就移動到下一個簽名，如果到達公鑰列表末尾而還有未驗證的簽名，則整個驗證失敗。

這個約束給實際應用帶來了一些不便。在收集簽名時，你需要知道每個簽名者對應哪個公鑰，並按正確順序排列。這也是為什麼後來的 Tapscript 採用了不同的設計。

2.4 建立 P2SH 多重簽名地址

讓我們看一個完整的建立 2-of-3 P2SH 多重簽名地址的過程。

首先，需要收集所有參與者的公鑰。在實踐中，這通常意味著每個參與者用自己的錢包軟體或硬體錢包生成一個公鑰並分享給協調者。重要的是只分享公鑰，絕不分享私鑰。

接下來，按照字典序對公鑰進行排序。這一步確保無論誰來建立地址，使用相同的公鑰集合都會得到相同的地址。沒有這個標準化步驟，不同的排序會產生不同的地址，造成混亂。

然後，構建贖回腳本並計算其 HASH160 雜湊值。這個 20 位元組的雜湊值就是 P2SH 地址的核心部分。最後，加上版本前綴（主網為 0x05）並進行 Base58Check 編碼，就得到了一個以「3」開頭的 P2SH 地址。

每個參與者都需要保存完整的贖回腳本，因為花費時需要揭示它。實際上，大多數多簽錢包會同時記錄所有公鑰，並在需要時重新生成腳本，以確保一致性。

三、SegWit 多重簽名

3.1 P2WSH 的優勢

SegWit 為多重簽名帶來了實質性的改進，主要體現在三個方面。

費用節省是最直觀的好處。在 SegWit 中，witness 數據（包括簽名）只計算四分之一的區塊權重。對於簽名佔據大部分體積的多簽交易來說，這意味著顯著的成本下降。一個 2-of-3 的 P2WSH 交易相比等價的 P2SH 交易，可以節省約 35% 的費用。隨著簽名數量增加，節省的比例還會更高。

安全性也得到了提升。P2SH 使用 HASH160（RIPEMD160(SHA256(x))），產生 20 位元組的雜湊值，提供約 80 位元的碰撞抵抗。P2WSH 則直接使用 SHA256，產生 32 位元組的雜湊值，提供 128 位元的碰撞抵抗。雖然 80 位元在目前看來已經足夠安全，但對於可能存在數十年的大額資產來說，更高的安全邊際是值得的。

此外，SegWit 重新設計的簽名雜湊演算法（BIP 143）解決了傳統交易的二次雜湊問題，使得驗證大型多簽交易的計算成本更加可控。

3.2 P2WSH 的結構

P2WSH 多重簽名在概念上與 P2SH 類似，但結構有所不同。

ScriptPubKey 變成了標準的 SegWit v0 格式：

OP_0 <32-byte-SHA256-of-witnessScript>

ScriptSig 現在是空的——所有解鎖數據都移到了 witness 區域。

witness 結構與 P2SH 的 ScriptSig 類似：

witnessScript 的內容與傳統的 redeemScript 完全相同：

OP_2    OP_3 OP_CHECKMULTISIG

這種設計讓從 P2SH 遷移到 P2WSH 變得相對簡單：核心邏輯不變，只是封裝方式改變了。

3.3 巢狀 SegWit（P2SH-P2WSH）

在 SegWit 早期採用階段，許多交易所和服務商尚未支援原生 SegWit 地址。為了兼容這些服務，出現了一種過渡方案：將 P2WSH 包裝在 P2SH 內部。

這種巢狀結構的 ScriptPubKey 是標準的 P2SH 格式（地址以「3」開頭），但 redeemScript 只包含一個 SegWit witness program：

OP_0 <32-byte-SHA256-of-witnessScript>

花費時，ScriptSig 只包含這個 redeemScript，而實際的簽名數據仍然放在 witness 區域。

這種方案提供了部分 SegWit 的費用優惠（因為簽名仍在 witness 中），同時保持了與舊系統的兼容性。隨著原生 SegWit 支援越來越普及，這種過渡格式的使用正在減少。

四、Taproot 革新多重簽名

4.1 兩種路徑的設計哲學

Taproot 為多重簽名提供了兩種截然不同的實現方式，每種都有其獨特的優勢和適用場景。

Key Path 使用 Schnorr 簽名的聚合特性，將多個簽名者的公鑰和簽名合併成一個。在鏈上，這看起來就像普通的單簽名交易——只有 64 位元組的簽名，沒有公鑰列表，沒有任何多簽的痕跡。這提供了最佳的效率和隱私，但要求所有簽名者都必須參與（n-of-n）。

Script Path 使用 Tapscript 中的 OP_CHECKSIGADD 操作碼，允許 m-of-n 的任意閾值配置。雖然這種方式需要揭示腳本並在鏈上可見多個公鑰和簽名，但它提供了更大的靈活性——不需要所有人都在線，只需要達到閾值即可。

在實踐中，這兩種方式通常會結合使用。Key Path 設置為所有參與者的聚合公鑰，作為最常見情況（共識達成）的高效路徑。Script Path 中包含各種備用方案，例如子集閾值簽名、時間鎖保護的緊急恢復等，作為異常情況的處理機制。

4.2 MuSig2：聚合簽名的實現

MuSig2 是目前比特幣採用的 Schnorr 多簽聚合協議，由 BIP 327 標準化。它允許 n 個參與者共同產生一個看起來像單簽名的聚合簽名。

協議分為兩個主要階段。第一階段是密鑰聚合：每個參與者提供自己的公鑰，這些公鑰通過特定的演算法組合成一個聚合公鑰。這個聚合公鑰就是 Taproot 輸出的內部公鑰（或經過調整後的輸出公鑰）。

密鑰聚合不是簡單的相加。為了防止一類稱為「流氓密鑰攻擊」的安全問題，每個公鑰在相加前會乘以一個基於所有公鑰的係數。這確保了沒有任何一方可以惡意選擇自己的公鑰來操控聚合結果。

第二階段是簽名生成。MuSig2 需要兩輪通訊。在第一輪，每個簽名者生成一對隨機 nonce 並分享公開部分。在第二輪，每個簽名者計算自己的部分簽名並分享。最終，這些部分簽名被聚合成一個完整的 Schnorr 簽名。

MuSig2 相比其前身 MuSig 的主要改進是將互動輪次從三輪減少到兩輪，並且允許 nonce 預生成，這大大提升了實用性，特別是對於硬體錢包等離線簽名設備。

4.3 Nonce 安全性的關鍵性

MuSig2 實現中最需要謹慎處理的是 nonce（隨機數）的管理。nonce 重用可以導致私鑰洩露，這不是理論上的威脅——歷史上確實發生過因為 nonce 問題而損失大量比特幣的事件。

每次簽名必須使用全新的隨機 nonce。為了在這個要求和離線簽名的便利性之間取得平衡，MuSig2 允許預先生成一批 nonce 並安全存儲。但這帶來了狀態管理的複雜性：系統必須確保每個 nonce 只使用一次，即使在崩潰恢復的情況下也是如此。

對於硬體錢包這類安全敏感的環境，通常會採用確定性 nonce 生成方案，基於私鑰和訊息派生 nonce，從而避免狀態管理的問題。但這需要謹慎的密碼學設計，不正確的實現可能引入新的漏洞。

4.4 Tapscript 中的 OP_CHECKSIGADD

當 n-of-n 聚合不適用時（比如只需要 m-of-n 的子集），Taproot 提供了 Script Path 作為替代方案。Tapscript 引入了 OP_CHECKSIGADD 操作碼，這是傳統 OP_CHECKMULTISIG 的現代化替代品。

OP_CHECKSIGADD 的設計更加簡潔和靈活。它從堆疊取三個元素：一個簽名、一個累加器值、和一個公鑰。如果簽名有效，累加器加一；如果簽名為空（表示該簽名者沒有簽名），累加器不變。最後，累加器被推回堆疊。

一個 2-of-3 的 Tapscript 看起來像這樣：

 OP_CHECKSIG
 OP_CHECKSIGADD
 OP_CHECKSIGADD
2 OP_NUMEQUAL

執行時，堆疊上會累積有效簽名的數量，最後與所需閾值比較。

這種設計有幾個優點。首先，它沒有 off-by-one bug，不需要那個莫名其妙的啞元素。其次，簽名順序是靈活的——不需要按公鑰順序排列，未簽名的位置只需提供空值。第三，它支援高效的批量驗證，因為所有簽名可以被收集起來一次性驗證。

五、閾值簽名：更進一步

5.1 從多重簽名到閾值簽名

多重簽名和閾值簽名都解決「需要多方授權」的問題，但它們在技術實現上有根本區別。

傳統多重簽名（包括 OP_CHECKMULTISIG 和 OP_CHECKSIGADD）在腳本層面工作：每個參與者獨立產生自己的簽名，腳本驗證時檢查是否有足夠數量的有效簽名。這意味著每個簽名都是獨立存在的，鏈上可以看到有多少人參與、需要多少人簽名。

閾值簽名則在密碼學層面工作：多個參與者協作產生一個單一的聚合簽名，這個簽名與普通的單人簽名無法區分。沒有人（包括區塊鏈分析者）能夠知道這筆交易實際上需要多方授權。

MuSig2 可以看作是 n-of-n 的閾值簽名——所有人都必須參與才能產生有效簽名。但對於 m-of-n（其中 m < n）的情況，需要更複雜的協議。

5.2 FROST 協議

FROST（Flexible Round-Optimized Schnorr Threshold signatures）是目前最有前景的閾值簽名方案之一。它允許任意 t-of-n 配置，同時保持只需兩輪通訊的效率。

FROST 的工作分為兩個階段。密鑰生成階段（DKG，Distributed Key Generation）中，參與者協作生成一個共享的公鑰和各自的私鑰份額。這個過程使用密碼學技術（如 Feldman’s VSS）確保沒有任何人知道完整的私鑰，私鑰只存在於數學上的「虛擬」形式。

簽名階段中，任意 t 個參與者可以合作產生有效簽名。他們各自用私鑰份額計算簽名份額，這些份額被聚合成最終簽名。只需要 t 個人在線，其他人可以完全離線或甚至暫時失聯。

FROST 的優勢在於其靈活性。考慮一個 3-of-5 的企業金庫：五位高管各持有一份私鑰份額，任意三人可以授權支出。即使兩人長期出差或離職，公司仍然可以正常運營。而在鏈上，這與個人錢包的交易看起來完全一樣。

5.3 實際應用考量

閾值簽名雖然強大，但在實際部署中需要考慮幾個問題。

首先是密鑰生成的複雜性。DKG 協議需要參與者之間的同步通訊，這在跨時區、跨網路環境的場景中可能成為挑戰。一些實現選擇使用可信第三方來簡化這個過程，但這犧牲了部分去中心化特性。

其次是門檻的選擇。門檻過低會降低安全性（攻擊者只需控制較少的份額），門檻過高會降低可用性（需要更多人同時在線）。不同場景需要根據具體的安全和可用性需求做出權衡。

最後是實現成熟度。相比經過十多年生產驗證的 OP_CHECKMULTISIG，閾值簽名協議相對較新。雖然密碼學原理已經被充分研究，但實現中的細節問題可能需要時間來發現和解決。

六、PSBT：多方協作的橋樑

6.1 為什麼需要 PSBT

在多重簽名的工作流程中，一個核心挑戰是如何在不同的簽名者之間傳遞交易資訊。每個簽名者可能使用不同的錢包軟體或硬體設備，可能處於離線狀態，甚至可能位於世界的不同角落。

PSBT（Partially Signed Bitcoin Transaction，部分簽名比特幣交易）是 BIP 174 定義的標準格式，專門解決這個問題。它是一種可以攜帶交易所有相關資訊的容器格式，包括未簽名的交易本身、每個輸入的詳細資訊（如 UTXO 數據、腳本、已收集的簽名等）、以及輸出資訊。

PSBT 的設計理念是讓不同的軟體和設備可以各自完成自己能做的部分，然後傳遞給下一個參與者。一個創建者可以構建基本交易結構，更新者可以添加輸入輸出的詳細資訊，多個簽名者可以獨立添加自己的簽名，組合者可以將不同來源的簽名合併，完成者可以構建最終的交易格式，提取者可以得到可廣播的原始交易。

6.2 PSBT 的結構

PSBT 使用鍵值對格式存儲資料，這種格式具有良好的擴展性——新的欄位類型可以被添加而不破壞舊實現的兼容性。

全局數據包含交易本身（未簽名形式）和 PSBT 版本資訊。每個輸入的數據可能包含：非 witness UTXO（完整的前序交易）、witness UTXO（只有相關輸出的資訊）、贖回腳本、witness 腳本、各種衍生路徑資訊、以及部分簽名的集合。每個輸出的數據通常包含金額和腳本資訊。

這種豐富的資訊結構讓簽名設備（特別是硬體錢包）可以驗證交易的所有關鍵方面：輸入是否存在、輸出是否正確、找零是否合理、費用是否過高。這些驗證對於防止簽名者被欺騙至關重要。

6.3 多簽工作流程

讓我們看一個使用 PSBT 的 2-of-3 多簽完整工作流程。

協調者首先創建一個 PSBT，包含要花費的 UTXO 和目標輸出。這個初始 PSBT 還沒有任何簽名，但包含了足夠的資訊讓簽名者理解這筆交易在做什麼。

PSBT 被發送給第一個簽名者（可能通過電子郵件、即時通訊、或任何檔案傳輸方式）。簽名者的錢包軟體或硬體解析 PSBT，顯示交易詳情供用戶確認，然後用自己的私鑰簽名並將部分簽名添加到 PSBT 中。

第一個簽名者返回更新後的 PSBT，然後發送給第二個簽名者。第二個簽名者重複同樣的過程，添加自己的簽名。

現在 PSBT 包含了足夠的簽名（2 個）。組合者（可能是協調者本人）驗證所有簽名的有效性，然後「完成」PSBT——將簽名和腳本組合成最終的 scriptSig 或 witness 格式。

最後，從完成的 PSBT 中提取原始交易並廣播到比特幣網路。

這個流程的優雅之處在於它的模組化：每個參與者只需要關心自己的步驟，不需要了解其他人使用什麼軟體或在哪裡簽名。

七、安全最佳實踐

7.1 密鑰分散原則

多重簽名的安全性建立在密鑰分散的基礎上。如果所有密鑰都存儲在同一個地方，那麼多簽就失去了意義——攻擊者只需要入侵一個位置就能獲得所有密鑰。

地理分散是第一道防線。不同的密鑰應該存儲在不同的物理位置，這樣即使一個位置被入侵、被沒收、或者遭受自然災害，其他密鑰仍然安全。

設備多樣化是另一個重要考量。使用不同品牌、不同型號的硬體錢包可以防止某個特定設備的漏洞影響整個系統的安全。如果所有密鑰都存儲在同一品牌的硬體錢包上，那麼該品牌的安全漏洞就可能成為致命弱點。

人員分離在企業場景中尤為重要。不同的密鑰應該由不同的人控制，這樣可以防止單個人的背叛或失職影響整體安全。同時，這也為組織提供了職責分離的保障。

7.2 備份策略

多簽錢包的備份比單簽錢包更複雜，因為需要考慮多個組成部分。

每個私鑰（或助記詞）需要獨立備份，並且備份應該與原始存儲位置分開。備份的安全級別應該與原始密鑰相當——如果原始密鑰在硬體錢包中受到保護，備份也應該被妥善加密或物理保護。

除了私鑰本身，還需要備份多簽配置資訊：所有公鑰的列表、閾值設置（m-of-n）、腳本類型（P2SH/P2WSH/P2TR）、衍生路徑等。沒有這些資訊，即使擁有所有私鑰也無法重建錢包。

一個常見的做法是創建一個「設置描述符」，這是一種標準化格式，完整描述了多簽錢包的結構。這個描述符不包含私鑰資訊，可以相對安全地存儲在多個位置。

7.3 測試恢復流程

備份的價值只有在恢復時才能體現。因此，定期測試恢復流程是安全實踐的重要組成部分。

在小額測試資金的情況下，嘗試完整的恢復過程：使用備份恢復每個密鑰、重建多簽錢包配置、創建並簽名測試交易。這個過程可以發現備份中的問題，也讓相關人員熟悉緊急情況下的操作流程。

對於大額資產，應該定期（例如每年一次）驗證所有備份的完整性和可訪問性，但不需要每次都實際恢復——只需確認備份存在、可讀、且內容正確即可。

八、實作練習

練習 1：建立 2-of-3 P2WSH 多簽地址

給定三個公鑰，手動計算 2-of-3 P2WSH 多簽地址。步驟包括：按字典序對公鑰排序、構建 witness script、計算 SHA256 雜湊、用 Bech32 編碼生成地址。嘗試用你熟悉的程式語言實現這個過程。

練習 2：模擬 PSBT 工作流程

設計一個簡單的多簽交易場景，包括：創建初始 PSBT、第一個簽名者添加簽名、第二個簽名者添加簽名、組合並完成 PSBT、提取最終交易。可以使用 Bitcoin Core 的 RPC 命令或任何支援 PSBT 的程式庫。

練習 3：比較不同多簽方案的效率

計算相同 2-of-3 配置在不同方案下的交易大小：P2SH、P2WSH、Taproot Script Path、Taproot Key Path（假設使用 MuSig2）。分析每種方案的空間效率和隱私特性。

九、小結

本篇我們深入探討了比特幣多重簽名的各個層面：

傳統多簽使用 OP_CHECKMULTISIG，是最早的標準化方案。雖然有 off-by-one bug 和簽名順序限制等歷史包袱，但它經過了十多年的生產驗證，仍然是可靠的選擇。

SegWit 多簽（P2WSH）提供了約 35% 的費用節省和更強的雜湊安全性，是目前企業應用的主流選擇。

Taproot 多簽帶來了革命性的改進。透過 MuSig2 的 Key Path，n-of-n 多簽可以達到與單簽名相同的效率和隱私；透過 Tapscript 的 OP_CHECKSIGADD，m-of-n 配置獲得了更好的靈活性和批量驗證支援。

閾值簽名如 FROST 代表了下一代多方安全技術，可以在密碼學層面實現對外完全隱藏的多方授權。

PSBT 作為多簽工作流程的標準化格式，解決了不同軟體和設備之間的互操作性問題。

選擇哪種多簽方案取決於具體需求：需要最高隱私和效率，選擇 Taproot Key Path；需要靈活的閾值配置，選擇 Taproot Script Path 或傳統方案；需要與舊系統兼容，選擇 P2WSH 或 P2SH。

下一篇預告

在下一篇文章中，我們將探討時間鎖機制——比特幣腳本中控制「何時」可以花費資金的強大工具。我們會深入了解絕對時間鎖（nLocktime、OP_CHECKLOCKTIMEVERIFY）和相對時間鎖（nSequence、OP_CHECKSEQUENCEVERIFY），並探討它們在閃電網路、原子交換、遺產規劃等場景中的應用。

參考資料

BIP 11: M-of-N 標準交易 - 最早的多簽標準
BIP 16: P2SH - Pay to Script Hash 規範
BIP 147: NULLDUMMY - 修復多簽延展性
BIP 174: PSBT - 部分簽名交易格式
BIP 327: MuSig2 - Schnorr 多簽聚合協議
Bitcoin Optech: Multisig - 多簽主題深入解析
FROST 論文 - 閾值簽名的學術基礎

Bitcoin Script 實戰教學（三）：SegWit 與 Taproot 深入解析

2025-03-17T00:00:00+00:00

系列導言

這是「Bitcoin Script 實戰教學」系列的第三篇。本篇將深入探討 SegWit 和 Taproot 這兩個重要升級如何改變了比特幣腳本的執行方式。這兩個升級代表了比特幣協議歷史上最重要的技術革新，不僅解決了長期存在的技術問題，更為比特幣的未來發展奠定了基礎。

系列文章：

基礎概念與操作碼
標準腳本類型詳解
SegWit 與 Taproot 深入解析（本篇）
多重簽名實現
時間鎖機制
進階應用與智能合約

一、SegWit 深入解析

1.1 什麼是 SegWit？

SegWit 是 Segregated Witness（隔離見證）的縮寫，於 2017 年 8 月透過軟分叉方式在比特幣主網啟動。這個升級的核心思想非常簡單但影響深遠：將交易的簽名數據（witness）從交易主體中分離出來。

「見證」在密碼學和法律用語中都指的是「證明某事為真的證據」。在比特幣交易中，見證就是數位簽名——它證明交易發起者確實擁有花費這些比特幣的權限。在 SegWit 之前，這些簽名數據和交易的其他部分混合在一起；SegWit 則將它們「隔離」到一個獨立的區域。

這個看似簡單的架構改變，解決了困擾比特幣多年的幾個關鍵問題。

1.2 交易延展性問題

交易延展性（Transaction Malleability）是 SegWit 解決的最重要問題之一。要理解這個問題，我們需要先了解比特幣如何識別交易。

每筆比特幣交易都有一個唯一識別碼，稱為交易 ID（txid）。這個 ID 是透過對整個交易進行雙重 SHA-256 雜湊運算得到的。問題在於，在傳統交易格式中，簽名數據也包含在這個雜湊計算中。

ECDSA 簽名有一個數學特性：對於同一個訊息，存在多個數學上等價的有效簽名。具體來說，如果 (r, s) 是一個有效簽名，那麼 (r, -s mod n) 也是有效的。這意味著任何人（不需要私鑰）都可以修改交易中的簽名，產生一個不同的 txid，但交易仍然有效。

這個問題對於一般的單筆交易影響不大，但對於依賴未確認交易 txid 的應用來說是災難性的。最典型的例子是閃電網路：它需要建立一連串相互依賴的交易，如果其中一筆交易的 txid 被修改，整個交易鏈就會斷裂。2014 年，Mt. Gox 交易所的部分損失就與交易延展性攻擊有關。

SegWit 的解決方案非常優雅：既然問題出在簽名會影響 txid，那就把簽名移到 txid 計算範圍之外。交易的核心數據（發送者、接收者、金額）用來計算 txid，而簽名則存放在獨立的 witness 區域。這樣，無論簽名如何被修改，txid 都保持不變。

1.3 區塊容量提升

比特幣區塊大小限制為 1MB，這個限制源自中本聰早期為防止垃圾交易攻擊所設置的參數。隨著比特幣使用量增加，這個限制開始制約交易處理能力，導致交易費用上升和確認時間延長。

直接增加區塊大小需要硬分叉，這意味著所有節點必須同時升級，否則網路會分裂。這在社區中引發了激烈爭論，最終導致了 2017 年的分叉事件。

SegWit 採用了一個巧妙的方法：引入「區塊權重」的概念來代替固定的區塊大小限制。新的規則規定區塊的最大權重為 4,000,000 權重單位（WU）。傳統交易數據的每個位元組計算為 4 WU，而 witness 數據的每個位元組只計算為 1 WU。

這個設計有幾個重要含義。首先，舊節點只看到傳統區塊數據，對它們來說區塊仍然在 1MB 限制內，保持了向後相容性。其次，由於 witness 數據佔用權重較少，使用 SegWit 的用戶可以享受較低的交易費用。實際上，這創造了一個經濟誘因，鼓勵用戶和錢包採用 SegWit。

在實踐中，完全使用 SegWit 交易的區塊可以達到約 2MB 到 2.3MB 的實際大小，有效地將區塊容量提升了一倍以上。

1.4 二次雜湊問題

在傳統比特幣交易中，簽名雜湊的計算方式存在一個效能問題。對於一筆有 n 個輸入的交易，每個輸入的簽名都需要對整個交易進行雜湊，這導致總的計算量與 n² 成正比——這就是所謂的二次雜湊問題。

對於普通交易來說，這個問題不太明顯。但對於輸入數量很多的大型交易，計算成本會急劇上升。惡意攻擊者可以構造特殊的交易，讓節點花費大量時間驗證，這被稱為「交易驗證拒絕服務攻擊」。

SegWit 透過 BIP 143 重新設計了簽名雜湊演算法。新演算法預先計算可複用的中間值，使得簽名驗證的複雜度從 O(n²) 降低到 O(n)。這不僅提高了效能，也消除了一類潛在的攻擊向量。

1.5 Witness 程式結構

SegWit 引入了一種新的輸出類型，稱為 witness program（見證程式）。這種輸出的 ScriptPubKey 格式非常簡潔：

版本位元組表示 witness 程式的類型。版本 0 是目前最常用的，支援兩種標準腳本。當 witness program 的長度為 20 位元組時，它被解釋為 P2WPKH（Pay to Witness Public Key Hash），這是 SegWit 版本的 P2PKH。當長度為 32 位元組時，則是 P2WSH（Pay to Witness Script Hash），這是 SegWit 版本的 P2SH。

版本 1 是為 Taproot 保留的，使用 32 位元組的 witness program。版本 2 到 16 保留給未來的升級使用。這種版本化的設計確保了比特幣可以持續演進，同時保持向後相容性。

1.6 SegWit 交易結構

傳統比特幣交易的結構相對簡單：版本號、輸入列表（包含 ScriptSig）、輸出列表、鎖定時間。SegWit 交易則在此基礎上增加了標記位元組和 witness 區域。

SegWit 交易在版本號之後插入兩個特殊位元組：標記（marker，值為 0x00）和旗標（flag，值為 0x01）。這兩個位元組告訴支援 SegWit 的節點，這是一筆 SegWit 交易。對於不支援 SegWit 的舊節點，這些位元組會被誤解為空的輸入列表，導致交易被視為無效而忽略——這正是軟分叉的巧妙之處。

witness 區域位於輸出列表和鎖定時間之間。每個輸入都有對應的 witness 堆疊，包含簽名和其他必要的驗證數據。這些數據不參與 txid 的計算，但會被驗證節點用來確認交易的有效性。

二、Taproot 升級概述

2.1 Taproot 的歷史背景

Taproot 於 2021 年 11 月在區塊高度 709,632 啟動，是自 SegWit 以來比特幣最重要的協議升級。這個升級由三個相互關聯的 BIP 組成：BIP 340 定義了 Schnorr 簽名方案，BIP 341 定義了 Taproot 的輸出和花費規則，BIP 342 定義了 Tapscript——一個改進版的腳本語言。

Taproot 的設計理念可以追溯到 2018 年，由比特幣核心開發者 Greg Maxwell 提出。他的洞見在於：大多數複雜的比特幣合約最終都會以所有參與方達成共識的方式結算，只有在出現爭議時才需要執行複雜的腳本邏輯。因此，如果我們能讓共識結算看起來像普通的單簽名交易，就能大幅提升隱私性和效率。

這個觀察引導了 Taproot 的核心設計：每個 Taproot 輸出都有兩種花費方式。Key path（密鑰路徑）允許透過一個聚合簽名直接花費，就像普通的單簽名交易一樣。Script path（腳本路徑）則允許揭示並執行預先承諾的腳本，用於處理非共識情況。

2.2 為什麼選擇 Schnorr 簽名？

在深入 Taproot 之前，我們需要理解 Schnorr 簽名為什麼是這個升級的基石。比特幣從創始之初就使用 ECDSA（橢圓曲線數位簽名演算法），這是一個成熟且廣泛使用的簽名方案。然而，ECDSA 有一些固有的限制。

Schnorr 簽名由德國密碼學家 Claus Schnorr 在 1989 年發明，實際上比 ECDSA 更早。它沒有被比特幣最初採用的原因很簡單：當時 Schnorr 簽名受專利保護，而 ECDSA 是自由使用的。Schnorr 專利在 2008 年過期，但比特幣已經在 2009 年初以 ECDSA 的形式誕生了。

Schnorr 簽名相比 ECDSA 有幾個重要優勢。首先是數學結構的簡潔性。ECDSA 的安全性證明相當複雜，而 Schnorr 簽名有著優雅的數學證明，基於離散對數問題的困難性。這種簡潔性不僅便於分析，也使得實現更不容易出錯。

其次是線性特性。Schnorr 簽名具有加法同態性，這意味著多個簽名可以數學上相加成一個聚合簽名。對於多重簽名場景，這帶來了革命性的改進：n-of-n 多簽只需要一個 64 位元組的簽名，而不是 n 個獨立簽名。

第三是批量驗證效率。當需要驗證多個 Schnorr 簽名時，可以將它們合併成一個運算，大幅減少計算量。這對於區塊驗證特別有價值，因為每個區塊可能包含數千個簽名。

三、Schnorr 簽名詳解

3.1 數學基礎

要理解 Schnorr 簽名的工作原理，我們需要一些橢圓曲線密碼學的基礎知識。比特幣使用的是 secp256k1 曲線，這是一個定義在有限域上的橢圓曲線。曲線上有一個特殊的點 G，稱為生成點，任何私鑰 d 對應的公鑰都是 P = d × G（這裡的乘法是橢圓曲線上的純量乘法）。

Schnorr 簽名的安全性基於離散對數問題的困難性：給定 P 和 G，在計算上不可能推導出 d。這與 ECDSA 使用相同的數學難題，但 Schnorr 的構造方式更為直接。

簽名過程如下。簽名者首先選擇一個隨機數 k（稱為 nonce），計算 R = k × G。然後計算 e = H(R

m)，其中 H 是雜湊函數，m 是要簽名的訊息，

表示連接。最後計算 s = k + e × d。簽名就是 (R, s) 這對值。

驗證同樣簡潔：檢查 s × G 是否等於 R + e × P。這個等式成立的原因可以這樣理解：s × G = (k + e × d) × G = k × G + e × d × G = R + e × P。只有知道私鑰 d 的人才能計算出正確的 s 值。

3.2 與 ECDSA 的具體差異

在比特幣的實際應用中，Schnorr 和 ECDSA 簽名有幾個具體的差異。

首先是簽名格式。ECDSA 簽名使用 DER 編碼，長度通常在 71 到 72 位元組之間（取決於 r 和 s 值的具體位元數）。Schnorr 簽名固定為 64 位元組：R 點的 x 座標佔 32 位元組，s 值佔 32 位元組。

其次是公鑰格式。傳統比特幣使用壓縮公鑰（33 位元組，包含一個前綴位元組表示 y 座標的奇偶性）或非壓縮公鑰（65 位元組）。BIP 340 引入了「x-only」公鑰——只有 32 位元組的 x 座標。這種格式是可行的，因為對於任何 x 座標，最多只有兩個有效的 y 座標，而 BIP 340 規定永遠選擇「偶數」的那個。

這種簡化節省了空間，但也意味著私鑰可能需要「翻轉」。如果計算出的公鑰 y 座標是奇數，就需要用曲線的階減去私鑰，使得對應的公鑰 y 座標變為偶數。這是 Taproot 實現中的一個微妙細節。

3.3 多重簽名聚合

Schnorr 簽名最引人注目的特性是支援簽名聚合。考慮一個 2-of-2 多簽場景，Alice 和 Bob 共同控制一筆資金。

在 ECDSA 世界中，這需要一個 P2SH 腳本，包含兩個公鑰和 OP_CHECKMULTISIG。花費時需要提供兩個完整的簽名，總共約 144 位元組的簽名數據。

使用 Schnorr 簽名的 MuSig2 協議，Alice 和 Bob 首先各自選擇隨機數並交換 R 值的承諾，然後交換實際的 R 值並計算聚合 R = R_A + R_B。接著，雙方獨立計算各自的部分簽名 s_A 和 s_B，最終聚合簽名就是 (R, s_A + s_B)。

這個聚合簽名只有 64 位元組，與單一簽名完全相同。更重要的是，從鏈上觀察者的角度來看，這與普通的單簽名交易沒有任何區別。沒有人知道這筆交易實際上需要兩個人的授權。

MuSig2 是 MuSig 協議的改進版本，將互動輪次從三輪減少到兩輪，大幅提升了實用性。然而，它的實現仍然比普通簽名複雜得多，特別是在確保 nonce 安全性方面需要特別小心。

四、P2TR（Pay to Taproot）詳解

4.1 Taproot 輸出的結構

Taproot 輸出的 ScriptPubKey 格式非常簡潔：

OP_1 <32-byte x-only pubkey>

這裡的 OP_1（0x51）表示 witness 版本 1，後面跟著 32 位元組的 x-only 公鑰。這個公鑰不是普通的公鑰，而是經過「調整」（tweaked）的輸出公鑰，蘊含著豐富的資訊。

Taproot 地址使用 Bech32m 編碼（BIP 350 定義），主網地址以 bc1p 開頭，測試網地址以 tb1p 開頭。這裡的 p 代表版本 1（版本 0 使用 q，因為在 Bech32 編碼中 0 對應 q，1 對應 p）。

4.2 公鑰調整機制

Taproot 的核心創新在於公鑰調整（key tweaking）機制。假設我們有一個內部公鑰 P（可能是單一公鑰，也可能是多方聚合公鑰），以及一個可選的腳本樹。我們需要構造一個輸出公鑰 Q。

如果沒有腳本樹，調整值 t 計算為：t = H_TapTweak(P)。如果有腳本樹，則先計算樹的 Merkle 根 m，調整值為：t = H_TapTweak(P

m)。這裡的 H_TapTweak 是一個標籤雜湊函數，其定義確保了不同用途的雜湊不會碰撞。

輸出公鑰 Q = P + t × G。這個 Q 就是存放在 ScriptPubKey 中的值。

這個設計的巧妙之處在於承諾方式。如果 Q = P + t × G，那麼知道 P 和 t 的人可以驗證 Q 確實是由 P 調整而來的。而 t 本身包含了腳本樹的 Merkle 根（如果有的話），所以 Q 實際上承諾了整個腳本樹的內容，但除非需要使用腳本路徑，否則這些腳本永遠不會暴露。

4.3 Key Path 花費

Key path 是 Taproot 輸出最常見的花費方式，也是最高效的方式。要透過 key path 花費，簽名者需要知道內部私鑰 d，然後計算調整後的私鑰 d’ = d + t。使用 d’ 對交易進行 Schnorr 簽名，這個簽名就可以通過 Q 的驗證。

witness 只包含一個元素：64 位元組的 Schnorr 簽名。沒有腳本，沒有公鑰揭示，沒有任何其他數據。這意味著無論背後的腳本有多複雜，只要所有參與方達成共識，花費的方式就和最簡單的單簽名交易一樣。

這對隱私有巨大的意義。一個複雜的多方合約——比如閃電網路通道的開設和關閉——在鏈上看起來與普通的個人轉帳沒有區別。觀察者無法知道這筆交易背後是一個人還是一百個人，是否有任何備用腳本存在。

4.4 Script Path 花費

當需要使用備用腳本時，就需要透過 script path 花費。這種情況下，witness 需要包含三部分：腳本的輸入數據（如簽名）、要執行的腳本本身，以及控制區塊（control block）。

控制區塊的結構包含：一個版本位元組（其中包含葉子版本和 Q 的 y 座標奇偶性）、32 位元組的內部公鑰 P，以及 Merkle 證明路徑（每個節點 32 位元組）。

Merkle 證明路徑允許驗證者確認所揭示的腳本確實是輸出承諾的腳本樹的一部分。驗證過程是：首先用腳本和葉子版本計算葉子雜湊，然後沿著證明路徑向上計算直到得到 Merkle 根，最後驗證 Q = P + H_TapTweak(P

root) × G。

這個機制的優美之處在於，只需要揭示你實際使用的腳本和它的證明路徑，而不需要揭示整個腳本樹。如果樹中有 128 個腳本，使用其中一個只需要 7 層的證明（log₂(128) = 7），其他 127 個腳本保持完全保密。

4.5 MAST 的實現

Taproot 實際上實現了一個叫做 MAST（Merkle Abstract Syntax Tree，默克爾抽象語法樹）的概念。這個概念在比特幣社區討論多年，而 Taproot 終於將它變成了現實。

傳統的 P2SH 需要在花費時揭示整個贖回腳本，無論其中有多少分支。如果你有一個「Alice 可以隨時花費，或者 Bob 在一年後可以花費」的腳本，即使 Alice 花費，也需要揭示 Bob 的備用條件存在。

使用 Taproot，Alice 和 Bob 可以構建一個腳本樹：根節點下有兩個葉子，分別是 Alice 的條件和 Bob 的時間鎖條件。更好的是，他們可以用聚合公鑰作為 key path——如果雙方合作，完全不需要揭示任何腳本。只有當他們無法合作（比如 Alice 失聯）時，Bob 才需要使用 script path，此時只揭示自己的分支，Alice 的腳本保持私密。

這種架構對於閃電網路等複雜協議特別有價值。閃電網路通道的承諾交易包含多個可能的花費路徑，使用 Taproot 可以大幅簡化這些交易的結構並提升隱私性。

五、Tapscript 新規則

5.1 Tapscript 的設計目標

Tapscript 是 Taproot 腳本路徑中使用的腳本規則，由 BIP 342 定義。它基於 SegWit 的腳本規則，但做了幾個重要的修改和改進。

設計 Tapscript 的主要目標是：適配 Schnorr 簽名、改進多簽效率、放寬某些限制、以及為未來升級預留空間。

5.2 OP_CHECKSIGADD

Tapscript 最重要的新操作碼是 OP_CHECKSIGADD（0xba）。這個操作碼專門為 Schnorr 簽名的批量驗證優化設計，用來取代傳統的 OP_CHECKMULTISIG。

OP_CHECKMULTISIG 有一個著名的「off-by-one」bug：它會多從堆疊中彈出一個未使用的元素。這個 bug 從比特幣誕生之初就存在，由於共識規則無法輕易修改，一直保留至今。OP_CHECKSIGADD 避免了這個問題。

OP_CHECKSIGADD 的語義很簡單：它從堆疊取三個元素——簽名、計數器 n、公鑰。如果簽名有效，將 n+1 推回堆疊；如果簽名無效（空簽名），將 n 推回堆疊。這允許用簡單的累加邏輯實現 k-of-n 多簽：

 OP_CHECKSIG
 OP_CHECKSIGADD
 OP_CHECKSIGADD
2 OP_NUMEQUAL

這個腳本檢查三個公鑰中是否至少有兩個對應有效簽名。與 OP_CHECKMULTISIG 不同，簽名的順序不需要與公鑰順序匹配——未簽名的公鑰對應空簽名即可。

更重要的是，這種結構允許有效的批量驗證。驗證者可以收集所有的 (公鑰, 訊息, 簽名) 三元組，使用 Schnorr 的批量驗證演算法一次性驗證所有簽名，這比逐個驗證快得多。

5.3 放寬的限制

Tapscript 移除了幾個傳統腳本的限制。

腳本大小限制：傳統腳本限制為 10,000 位元組，Tapscript 沒有這個限制（但仍受區塊權重限制）。這對於某些需要大量公鑰或複雜邏輯的應用來說是重要的改進。

操作碼數量限制：傳統腳本限制每個腳本最多 201 個操作碼，Tapscript 移除了這個限制。這對於需要大量條件分支的複雜腳本很有用。

堆疊元素大小：傳統腳本限制單個堆疊元素最大 520 位元組。Tapscript 仍然有這個限制，但由於 OP_SUCCESS 的存在，未來可以透過軟分叉放寬。

5.4 OP_SUCCESS 與未來升級

Tapscript 引入了一個創新的升級機制：OP_SUCCESS 操作碼。這些是一組目前未定義的操作碼（包括 0x50, 0x62, 0x89-0x8a 等），在 Tapscript 中被解釋為「立即成功」——遇到這些操作碼時，腳本驗證立即成功，不管其他條件。

這看起來像是一個安全漏洞——使用這些操作碼的腳本不就可以無條件被任何人花費嗎？確實如此。但關鍵在於，這允許未來透過軟分叉賦予這些操作碼實際意義。一旦一個 OP_SUCCESS 被重新定義，使用它的腳本就需要滿足新的條件才能被花費。

這種「先開放再收緊」的升級策略比傳統的「先禁用再啟用」更加靈活。傳統腳本中的禁用操作碼（如 OP_CAT）一旦被執行就會使腳本失敗，這意味著啟用它們需要複雜的版本控制機制。而 OP_SUCCESS 可以被簡單地重新定義，只要新的規則比「無條件成功」更嚴格，就是向後相容的軟分叉。

六、Bech32m 地址編碼

6.1 從 Bech32 到 Bech32m

SegWit v0 引入了 Bech32 地址編碼，這是一種專為人類可讀性設計的編碼格式，使用 32 個字元（qpzry9x8gf2tvdw0s3jn54khce6mua7l）來表示數據，並包含強大的錯誤檢測能力。

然而，Bech32 被發現存在一個弱點：在某些情況下，地址末尾的 q 字元可以被添加或刪除而不改變校驗和。這個問題對於 SegWit v0 地址影響較小（因為長度是固定的），但對於未來可能有不同長度的 witness 版本來說是個問題。

BIP 350 定義了 Bech32m 來解決這個問題。它使用了不同的校驗和常數，使得添加或刪除字元會被檢測到。規則是：SegWit v0 地址繼續使用原始 Bech32 編碼，而 SegWit v1 及更高版本使用 Bech32m。

這就是為什麼 P2WPKH 和 P2WSH 地址以 bc1q 開頭（q 是版本 0 在 Bech32 中的表示），而 P2TR 地址以 bc1p 開頭（p 是版本 1 在 Bech32 中的表示）。

6.2 地址類型識別

作為開發者，了解如何識別不同的比特幣地址類型很有用：

以 1 開頭的是傳統 P2PKH 地址，使用 Base58Check 編碼。以 3 開頭的是 P2SH 地址，可能包裝任何類型的腳本，包括 SegWit（P2SH-wrapped SegWit）。以 bc1q 開頭的是原生 SegWit v0 地址（P2WPKH 或 P2WSH）。以 bc1p 開頭的是 Taproot（P2TR）地址。

測試網使用不同的前綴：m 或 n 開頭是測試網 P2PKH，2 開頭是測試網 P2SH，tb1q 是測試網 SegWit v0，tb1p 是測試網 Taproot。

七、實際應用案例

7.1 閃電網路通道

閃電網路是 Taproot 最重要的受益者之一。傳統的閃電網路通道開設交易使用 2-of-2 P2WSH 多簽，在鏈上清晰可見。使用 Taproot，通道開設只需要一個普通的 P2TR 輸出，無法與普通支付區分。

通道承諾交易包含多個可能的花費路徑：合作關閉、單方面關閉、懲罰交易等。使用 MAST 結構，這些複雜的邏輯可以被隱藏在腳本樹中，只在必要時揭示。

7.2 多簽錢包

對於需要多方授權的企業或高價值錢包，Taproot 提供了顯著的隱私和成本優勢。一個 3-of-5 的多簽設置，使用 Schnorr 聚合可以讓所有簽名者共同產生一個單一簽名。在鏈上，這與個人錢包的交易看起來完全一樣。

如果某些簽名者無法參與，可以透過 script path 使用備用的閾值方案，只需要揭示需要的那個分支。

7.3 遺產規劃

Taproot 對於加密貨幣遺產規劃也很有用。假設 Alice 想設置一個輸出：正常情況下她自己可以花費，但如果她失聯超過一年，她的繼承人可以透過 2-of-3 多簽來花費。

使用 Taproot，Alice 的公鑰可以作為 key path——日常使用時就像普通錢包一樣。腳本樹中包含一個帶時間鎖的繼承人多簽腳本。只有當 Alice 真的無法使用 key path 時，繼承人才需要揭示這個腳本。

八、實作練習

練習 1：創建 Taproot 地址

嘗試用你熟悉的程式語言創建一個簡單的 Taproot 地址。步驟包括：生成一個隨機私鑰，計算對應的公鑰（注意轉換為 x-only 格式），計算無腳本的 tap tweak，調整公鑰，使用 Bech32m 編碼生成地址。

練習 2：設計腳本樹

設計一個 Taproot 輸出，支援以下場景：Alice 和 Bob 可以隨時共同簽名（key path），Alice 可以在 30 天後單獨花費，Carol 可以在 180 天後作為緊急恢復。畫出腳本樹結構，並考慮如何優化樹的深度以最小化未來可能的見證大小。

練習 3：比較效率

計算以下場景的 witness 大小：2-of-3 多簽使用傳統 P2SH、使用 P2WSH、使用 Taproot key path（假設 MuSig2 聚合）、使用 Taproot script path。分析不同方案的權衡。

九、小結

本篇我們深入探討了比特幣兩個最重要的升級：

SegWit 的貢獻包括：解決了交易延展性問題，使閃電網路等二層協議成為可能；提升了有效區塊容量；優化了簽名雜湊計算的效率；引入了版本化的 witness 程式，為未來升級奠定基礎。

Taproot 的創新包括：引入 Schnorr 簽名，提供更高效的簽名和批量驗證；實現 MAST，允許複雜腳本保持私密；透過 key path/script path 雙路徑設計，讓大多數交易看起來像簡單的單簽名；Tapscript 改進了腳本語言並為未來升級預留空間。

這些技術不僅提升了比特幣的效率和可擴展性，更重要的是大幅增強了隱私性——讓複雜的智能合約在鏈上看起來與普通交易無異。

下一篇預告

在下一篇文章中，我們將探討多重簽名的各種實現方式，包括傳統的 OP_CHECKMULTISIG、Tapscript 的 OP_CHECKSIGADD、以及 MuSig2 協議的細節。

參考資料

BIP 141: SegWit - SegWit 的原始規格
BIP 143: SegWit 簽名哈希 - 新的簽名雜湊演算法
BIP 340: Schnorr 簽名 - Schnorr 簽名的比特幣標準
BIP 341: Taproot - Taproot 的完整規格
BIP 342: Tapscript - Tapscript 腳本規則
BIP 350: Bech32m - 改進的地址編碼
Bitcoin Optech: Taproot - 深入的技術解說