比特幣交易輸入的序列號 nSequence 作用解析，涵蓋相對時間鎖、交易替換與控制條件

它在交易的哪個位置，佔多少空間

在比特幣交易的原始序列化資料結構中，每一個交易輸入（TxIn）固定由五個部分構成：前一筆輸出的交易雜湊（32 位元組）、輸出索引 Index（4 位元組）、解鎖腳本長度前綴、解鎖腳本 ScriptSig，以及位於輸入尾部的 4 位元組 nSequence。這是一個 32 位元無符號整數（Little-Endian 編碼），寫死在輸入結構尾端，沒有任何例外。

在 2009 年的最初設計中，該欄位原先規劃用於高頻交易的本地替換更新——發送方若要調整交易內容，可發送序號更高的新版本覆蓋舊版本。然而該機制缺乏防雙花激勵且容易引發記憶池阻斷服務風險，隨後被節點預設停用。此後多年間，該欄位長期作為佔位常數存在，絕大多數交易預設填入 0xFFFFFFFF。

關鍵轉折始於 2016 年啟動的軟分叉升級，包含 BIP68、BIP112 與 BIP113。其中 BIP113 將時間鎖判定依據調整為「過去 11 個區塊時間戳的中位數」（Median Time Past, MTP），防止礦工操控單一區塊時間；而 BIP68 則重新定義了 32 個位元的語意，將閒置的輸入欄位改造成具備共識強制力的 相對時間鎖 載體。

32 個位元怎麼分配：兩個旗標位與一段數值

共識規則並未將 32 個位元當作整體數值，而是拆解為旗標控制位與數值區。這種位元層級的複合設計，是正確解析該欄位的關鍵所在：

第 31 位（Bit 31）：相對時間鎖停用旗標（Disable Flag）

掩碼為 0x80000000。一旦該最高位被設為 1，共識驗證時將完全跳過該輸入的相對時間鎖檢查，低位數值不再具備時間鎖含義。這是關閉相對時間鎖的標準路徑，諸如 0xFFFFFFFD 這類高位為 1 的數值，均不會觸發漫長的鏈上鎖定。

第 22 位（Bit 22）：時間單位旗標（Type Flag）

掩碼為 0x00400000。在第 31 位為 0（啟用相對時間鎖）的前提下：當第 22 位為 1 時，低位數值以 512 秒為步長 換算時間；當第 22 位為 0 時，低位數值代表 確認區塊數量。此位元與低位數值隔開放置，旨在降低舊格式交易數值意外碰撞共識條件的機率。

第 0 至第 15 位（Bits 0-15）：有效鎖定數值

低 16 位是數值核心，範圍為 0 至 65535。以區塊為單位時，最大可鎖定 65,535 個區塊（約 455 天）；以 512 秒為單位時，最大可鎖定 33,553,920 秒（約 388 天）。

此外，相對時間鎖的起算基準是 該輸入所引用的前向 UTXO 所在區塊的中位時間（MTP）或區塊高度，而非當前交易廣播的時刻。若花費的是未確認父交易的輸出，相對時間鎖必須在父交易正式打包確認後方能啟動計時。

常見數值對照表

鏈上交易中出現的序號數值呈現明確的分佈規律。解析具體數值可直接判定該交易設定的相對鎖、絕對鎖與替換行為：

值得注意的邊界條件是：一旦輸入序號數值低於 0xFFFFFFFE，依據 BIP125 規則，該交易在記憶池中即自動帶有「允許被替換」的政策屬性。因此，若合約腳本設定了相對區塊鎖（如 6 個區塊），該交易在確認前客觀上也同時具備了可替換訊號。

它與 nLockTime 的分工關係與防手續費搶劫機制

交易級別的 nLockTime 代表 絕對時間鎖（鎖定至特定區塊高度或 Unix 時間戳），而輸入級別的 nSequence 則負責 相對時間鎖與功能開關。二者在底層共識上存在著嚴格的聯動校驗：

當一筆交易的 所有輸入 的 nSequence 皆為 0xFFFFFFFF 時，共識層會強制忽略交易頂層的 nLockTime，將其視為完全無鎖交易。只有當 至少一個輸入 的 nSequence 小於 0xFFFFFFFF 時，頂層的 nLockTime 限制才會被共識層強制驗證。

在節點實作方面，自 Bitcoin Core 22.0 起，錢包預設啟用 BIP125 RBF，常規交易的輸入預設填入 0xFFFFFFFD；若使用者顯式關閉錢包替換選項（例如設定 -walletrbf=0），節點則預設寫入 0xFFFFFFFE。在此同時，錢包會預設將 nLockTime 設定為當前區塊鏈尖端高度。這種構造方式被稱為 防手續費搶劫（Anti-Fee-Sniping）——確保交易無法在更早的高度被打包，消除了自私礦工回滾前一個區塊以掠奪高手續費交易的動機。

相對時間鎖在腳本層的延伸：CHECKSEQUENCEVERIFY

BIP112 定義了腳本操作碼 OP_CHECKSEQUENCEVERIFY（簡稱 CSV）。該操作碼允許輸出腳本將花費條件與輸入中的序號進行比對驗證。它與校驗絕對時間鎖的 OP_CHECKLOCKTIMEVERIFY（CLTV）形成對稱互補。

當解鎖腳本執行到 CSV 時，節點會核驗堆疊頂部傳入的數值是否小於或等於對應輸入交易中的 nSequence 數值。執行該校驗存在幾條關鍵約束：

• 交易版本必須滿足 nVersion >= 2，否則直接觸發共識驗證失敗。
• 輸入序號的第 31 位不可為 1（即相對鎖不可處於停用狀態）。
• 堆疊數值與輸入序號的時間單位旗標（第 22 位）必須完全一致。若腳本要求區塊間隔，輸入卻採用秒級步長，驗證將被中斷。
• 若堆疊傳入的數值最高位（第 31 位）被置為 1，CSV 將直接作為無操作（NOP）通過，此設計為未來的軟分叉升級保留了向下相容路徑。

CSV 是鏈上合約的基石。在閃電網路（Lightning Network）承諾交易與懲罰機制的設計中，通道單方撤資必須等待特定長度的相對時間（如 144 個區塊），對手方才能在該窗口期內提交懲罰證明。在資產繼承方案中，多簽腳本亦廣泛使用 CSV 實現主私鑰遺失後一段時間由備援密鑰解鎖的邏輯。

交易替換：政策演進與零確認風險

依據 BIP125，當交易中至少有一個輸入的 nSequence 小於 0xFFFFFFFE，即代表發送方主動發出「可被替換」（Opt-in RBF）訊號。節點記憶池在接收到花費相同輸入但附加更高費率的新交易時，將允許覆蓋舊交易。

需要明確的是，交易替換屬於節點中繼與記憶池政策（Policy），並非共識層限制（Consensus）。礦工在底層共識規則上始終具備自由打包任何有效交易的權力。自 Bitcoin Core 25.0 起，節點預設啟用 mempoolfullrbf=1 政策（Full RBF），即便原始交易的序號為 0xFFFFFFFF，主流節點在收到更高費率的衝突交易時同樣會接納替換。

這意味著，序號為 0xFFFFFFFF 或 0xFFFFFFFE 僅代表發送方未主動標記替換，絕不構成交易無法被覆蓋的共識保證。商戶若在未獲得至少 1 個區塊確認前交付高價值實物或記賬，將承擔不可忽視的雙花風險。

手續費調整方案：RBF、CPFP 與 V3 交易策略

當比特幣手續費飆升導致交易滯留記憶池時，除發送方透過改寫序號發起 RBF 覆蓋外，接收方亦可採用 子交易資助父交易（CPFP） 機制。CPFP 透過構造一筆高費率的子交易花費滯留的父輸出，驅使礦工為獲取子交易手續費而將父子交易成批打包上鏈。

為了解決 CPFP 過程中潛在的記憶池固定釘死攻擊（Pinning Attacks），比特幣社群在 BIP431 中提出了 V3 交易中繼策略（交易封包中繼方案）：

• 交易版本要求：採用 nVersion = 3，限定拓撲結構為至多一個父交易與一個子交易。
• 序號約束規範：為避免交易依賴複雜的相對時間鎖延誤打包，V3 政策要求子交易的 nSequence 必須為啟用替換且不可依賴長延遲鎖定（通常限定為預設替換值），確保交易包能迅速在記憶池中以整體形式轉發評估。

業務場景下的檢查清單

錢包開發者與支付系統維護者在解析傳入的交易資料流時，建議遵循以下判斷邏輯：

常見問題解答（FAQ）