比特幣交易在序列化之後，位元組流緊接在版本號（version）後面的就是 4 個位元組的無符號整數（uint32）——鎖定時間nLockTime欄位，取值範圍從 0 到 4,294,967,295。這個欄位從中本聰 2009 年發布最初客戶端時就已存在，經歷隔離見證（SegWit）與 Taproot 等多次重大升級，其核心結構與物理位置始終保持不變。
該欄位的核心邏輯建立在一條清晰的數值分界線上：當數值小於 500,000,000 時，節點將其解讀為區塊高度；等於或大於 500,000,000 時，則被當作 Unix 時間戳（單位為秒）。五億這個分水嶺經過精密計算——比特幣以平均十分鐘產生一個區塊的速度推進，高度要達到五億需要約九千五百年。在當前九十多萬區塊高度的量級下，高度數值與 Unix 時間戳相差五百多倍，兩者在現實時間維度內永遠不會產生歧義。
當 鎖定時間nLockTime欄位 數值為 0 時，共識節點直接判定為「不設定時間鎖」，並將交易視為 final。因此，任何常規未加鎖的標準轉帳交易通常直接寫入 0，這也是鏈上多數歷史交易該欄位為零的原因。
final 與 non-final 的判定邏輯
節點檢驗交易是否達到解鎖標準，依靠的是內核中的 IsFinalTx 函式。其判定流程嚴格遵循兩步驗證：
- 檢查輸入序列號：只有當交易中所有輸入的 nSequence 都等於 0xFFFFFFFF（SEQUENCE_FINAL）時，nLockTime 才會被完全忽略，交易直接判定為 final。反之，只要有任何一個輸入的 nSequence 不等於 0xFFFFFFFF，時間鎖就會正式生效。
- 比對區塊標準：在時間鎖生效的前提下，若欄位解讀為高度，則需嚴格小於當前驗證的區塊高度；若解讀為時間戳，則需嚴格小於當前區塊的計算時間基準。滿足條件即為 final，具備打包資格；若大於或等於該基準，則屬於 non-final，禁止進入區塊。
nSequence 才是真正的觸發開關
在比特幣底層架構中，輸入項中的 nSequence 欄位扮演著開關角色。早期設計曾構想利用 nSequence 進行未確認交易的替換，但機制並未完善。隨後 BIP125 推出了選擇性手續費替換（opt-in RBF）標準：只要交易中任一輸入的 nSequence 小於 0xFFFFFFFE，該交易即被節點標記為允許被加價替換。
這在實務上誕生了一個精巧的平衡值：0xFFFFFFFE。該數值不等於 0xFFFFFFFF，因此能成功觸發 鎖定時間nLockTime欄位 的約束；同時它又不低於 0xFFFFFFFE，在遵循 BIP125 的規則下不會主動向網絡發出 RBF 替換信號。
防費用狙擊（Fee Sniping）機制
主流錢包並未將日常轉帳的 鎖定時間nLockTime欄位 閒置。Bitcoin Core 在組裝常規交易時，預設會將該欄位填入當前鏈尖高度，並將所有輸入的 nSequence 設為 0xFFFFFFFE。此舉專門用於防禦費用狙擊（Fee Sniping）：
若大型礦工企圖發動微型區塊重組，回溯打包累積大量手續費的前一個區塊，這筆鎖定在當前高度的交易將無法被塞入過去的高度的區塊中。這項安全防護在交易簽名產生的那一刻就已經處於 final 狀態，因此普通使用者在廣播轉帳時完全不會察覺到任何延遲。
Full-RBF 政策環境下的轉變
隨著全節點廣泛支援並將 full-RBF 納入記憶池中繼政策，節點在面對更高手續費的雙花替換時，已逐步淡化 nSequence 是否小於 0xFFFFFFFE 的信號限制。在現代網絡環境中，0xFFFFFFFE 依舊是各類錢包啟用時間鎖並保持腳本簡潔的標準做法，但它已不再構成交易「絕對無法被節點替換」的共識防禦，各開發者與節點服務應建立清晰的認知邊界。
廣播階段：未到期交易無法進入記憶池
交易從客戶端推送到 P2P 網絡時，面臨的第一道關卡是節點的記憶池（Mempool）檢驗。全節點在接納交易前會調用判定程序，依據本地校正時間與當前區塊高度進行驗證。尚未解鎖的 non-final 交易將被節點直接拒絕，並拋出錯誤代碼 non-final。
- 無法提前委託網絡排隊：比特幣節點不具備「替未到期交易暫存並自動定時廣播」的託管義務。提前推播 non-final 交易只會被對等節點丟棄，甚至可能觸發節點對異常流量的防護攔截。
- 離線保管才是標準操作：設定了未來時間點生效的交易，發送方必須在本地環境妥善保存簽名後的原始交易位元組（Raw Transaction），等待鏈上條件滿足後再向網絡發起廣播。
- 時鐘同步偏差的影響：在時間戳模式下，記憶池入池依賴節點本機時鐘與對等節點計算出的調整時間（Adjusted Time）。若節點本地 NTP 時間偏差較大，可能導致不同節點對同一筆交易的入池標準產生數分鐘甚至更長時間的分歧。
礦工打包：共識層強制驗證
部分使用者誤以為時間鎖僅僅是記憶池層面的中繼過濾規則，但它實際上是不可妥協的底層共識規則。礦工在構造區塊模板時，共識代碼會對區塊內包含的每一筆交易重新運行驗證。
bad-txns-nonfinal 錯誤）。該區塊會被全網節點立即拋棄，導致礦工損失全部的區塊獎勵與高額電力成本。
解鎖時刻的到來，僅僅代表該筆交易擁有了參與記憶池排序競爭的資格。交易最終何時被確認，完全取決於解鎖當時網絡的費率競爭環境與出塊速度，解鎖時間點絕不等於最終上鏈確認的時間點。
MTP 機制讓「時間到期」更具抗操縱性
在 BIP113 軟分叉生效之前，時間戳型時間鎖採用區塊頭中的 nTime 進行比對。由於礦工在特定邊界內有權調整自己區塊的時間戳，這讓時間鎖的精確解鎖時機存在被微調操縱的空間。
BIP113 啟用後，共識層將時間比對基準全面改為過去 11 個區塊的時間戳中位數（Median Time Past，簡稱 MTP）。MTP 具備嚴格的單調遞增特性，任何單一礦工都無法讓該數值倒退或大幅突變，有效杜絕了人為操縱時間提早解鎖的漏洞。
然而，中位數演算法的引入意味著 MTP 天然滯後於現實世界的掛鐘時間。在正常的出塊節奏下，MTP 通常會比真實掛鐘時間落後約數十分鐘至一小時以上。因此，若將 鎖定時間nLockTime欄位 綁定為某個確切的日曆時間，其實際可廣播與打包的時刻必定會延後，開發者在設計系統時必須預留充足的時間緩衝。
腳本級時間鎖：CLTV 與 CSV 的協同
鎖定時間nLockTime欄位 屬於交易層級的全局屬性，由簽名發起方單向構造。為了在智能合約與花費腳本中實現更靈活的約束，比特幣引入了腳本層級的操作碼：
- OP_CHECKLOCKTIMEVERIFY（CLTV，BIP65）：用於設定絕對時間鎖。它直接檢驗花費該腳本的交易中，其 鎖定時間nLockTime欄位 是否大於或等於指定門檻，且該輸入的 nSequence 絕不能為 0xFFFFFFFF。如果輸入填入 0xFFFFFFFF，CLTV 將執行失敗並終止交易。
- OP_CHECKSEQUENCEVERIFY（CSV，BIP112 / BIP68）：用於設定相對時間鎖（以輸出被確認後經過的區塊數或秒數計算）。其編碼規範遵循 BIP68：
- 交易版本號必須 ≥ 2。
- 第 31 位（bit 31，即 1 << 31）為停用標誌（Disable Flag），必須為 0 相對鎖才生效。
- 第 22 位（bit 22，即 1 << 22）為類型標誌（Type Flag），為 0 表示以區塊數為單位，為 1 則表示以 512 秒為步長的時間單位。
- 低 16 位記錄實際的相對鎖定量值。
實務操作陷阱與防範清單
- 費率環境凍結風險：提前數月簽署並鎖定時間的交易，其手續費率被固定在過去的標準。一旦解鎖時全網手續費大幅飆升，交易可能因費率過低而無法被記憶池轉發。
- CPFP 無法在未入池前生效：子交易依賴父交易（CPFP）的前提是父交易已經進入記憶池。在父交易尚未解鎖、被全網拒絕的階段，無法透過發送子交易來加速。
- 原始交易外洩的邊界：未解鎖的原始交易外洩，持有者無需擔心資金被第三方直接憑空竊取，因為替換輸入需要合法的私鑰簽名。然而對手可以在解鎖臨界點搶先向全網廣播該交易，從而徹底打亂原發起人的時機掌控策略。
- 重複推播造成的退避：過早向公用廣播節點推播 non-final 交易，可能觸發 API 服務器的請求限制或冷卻退避，導致解鎖當下反而無法第一時間將交易送出。
各類時間鎖機制技術對照
| 機制名稱 | 所在維度 | 生效關鍵條件 | 核心比對基準 |
|---|---|---|---|
| nLockTime（高度型） | 交易層級，數值 < 500,000,000 | 任一輸入的 nSequence ≠ 0xFFFFFFFF | 當前區塊高度 |
| nLockTime（時間型） | 交易層級，數值 ≥ 500,000,000 | 任一輸入的 nSequence ≠ 0xFFFFFFFF | 過去 11 區塊時間中位數（MTP） |
| nSequence 相對鎖 | 交易輸入項（TxIn） | 交易版本 ≥ 2，且第 31 位未設置 | 前序輸出被確認的區塊或 MTP |
| OP_CLTV（BIP65） | 花費驗證腳本（Script） | 當前輸入 nSequence ≠ 0xFFFFFFFF，交易 nLockTime ≥ 堆疊要求值 | 交易本身的 nLockTime 欄位 |
| OP_CSV（BIP112） | 花費驗證腳本（Script） | 符合 BIP68 編碼規範且滿足相對鎖深度 | 交易輸入項的 nSequence 欄位 |
常見問題 FAQ
Q1：只要任一輸入的 nSequence 設為 0xFFFFFFFF，整筆交易的 nLockTime 就失效了嗎？
不是。相反地，只有當所有輸入的 nSequence 全部都是 0xFFFFFFFF 時，時間鎖才會被節點完全忽略。只要其中有任何一個輸入的數值不為 0xFFFFFFFF，整筆交易的 鎖定時間nLockTime欄位 就會正常生效並接受共識校驗。
Q2：時間戳型鎖定到達指定掛鐘時間後，交易為什麼仍然被拒絕？
因為自 BIP113 啟用後，共識層判定依賴的是過去 11 個區塊的時間戳中位數（MTP）。MTP 往往滯後於現實世界的時間數十分鐘甚至更久。只有在鏈上前 11 個區塊的中位數正式跨過設定值時，交易才會被全網承認為 final。
Q3：解鎖後發現交易因為手續費過低無法被打包，該如何處理？
如果未到期的交易此前從未被記憶池接收，最簡單且穩妥的方式是：直接使用私鑰對相同的 UTXO 重新簽署一筆具備足額手續費的新交易並發布。若原交易已被部分全節點接收但卡在隊列中，則需依賴 RBF 替換或在交易結構允許的情況下進行後續處理。
Q4：為什麼使用 Bitcoin Core 產生的普通交易，nLockTime 欄位通常不是 0？
這是 Bitcoin Core 預設啟用的「防費用狙擊」防護。錢包在組裝交易時會將該欄位預設填入當前的最新區塊高度，將輸入 nSequence 設為 0xFFFFFFFE。這讓交易在發出時即為 final 不影響即時廣播，同時杜絕了歷史區塊被重組替換時被惡意打包的隱患。
