比特幣可以設定「未來才能花」嗎？

銀行可以預約轉帳，保險箱也能加上定時機構。比特幣同樣能替交易或資產的花費路徑設定一道時間門檻，讓它在某個區塊高度、鏈上時間基準，或經過一定期間之前無法生效。這類規則統稱為時間鎖（timelock）。

可是，名稱很容易讓人誤會：時間到了，網路會不會自動把錢送出去？如果持有人有正確鑰匙，為什麼還可能不能花？現實中的日期與比特幣內部的時間又是否完全同步？

時間鎖只定義「最早何時可以成為有效花費」，不負責主動建立、廣播或保證收錄交易。理解它的關鍵，是把簽署權、時間條件與實際確認拆成三件事。它們必須一起成立，付款才可能寫入公開紀錄。

有正確鑰匙，仍要滿足資產的花費條件

許多人會把比特幣的控制權簡化成「錢包裡有沒有私鑰」。簽章確實是常見條件，鏈上的 UTXO 卻可以帶有更完整的支出規則。某一條路徑可能要求指定簽章立即生效，另一條路徑則可能要求簽章正確，而且時間門檻已經成熟。

這道門檻由全節點依規則檢查。交易若提早出現，即使簽章沒有問題，仍沒有資格進入有效區塊；礦工把它收進候選區塊，也會遭其他驗證者拒絕。等到條件成熟，交易只是取得被收錄的資格，真正進入區塊後才開始累積交易確認。

因此，時間鎖與把檔案藏起來、請服務商延後送出有本質差別。後兩者依賴某個設備或公司守約，鏈上時間條件則由每個驗證者按同一套規則判斷。即使原先建立安排的軟體已經關閉，提早支出的交易仍過不了驗證。

絕對時間鎖指定一個共同門檻，例如「到某個區塊高度之後」或「到某個鏈上時間基準之後」。交易層的 nLockTime 可以限制整筆交易最早何時有資格被收錄；花費條件也能使用 CHECKLOCKTIMEVERIFY，常縮寫為 CLTV，要求特定支出路徑不得早於指定門檻。

兩者的差異很重要。只替一份已簽好的交易設定較晚的 nLockTime，不一定能阻止資產持有人另外建立一筆較早生效的交易。若希望某個 UTXO 在期限前確實無法沿特定路徑花費，時間要求必須成為該輸出的花費條件，而非只存在於預先準備的一份交易檔案裡。

以區塊高度為門檻時，規則等待的是帳本再增加到某個位置。由於出塊間隔具有隨機性，某個高度何時抵達只能估計，不能當成精準鬧鐘。以時間為門檻時，網路採用近期區塊時間戳形成的中位數基準，也不直接讀取使用者手機上的當地時間。這種設計降低單一錯誤時鐘的影響，代價是鏈上時間與日常鐘錶可能有落差。

相對時間鎖以被花費輸出已經存在多久為基準，不採用全網共同日期。它可以要求某個 UTXO 獲得確認後，再經過一定數量的區塊或一段以鏈上基準衡量的時間，相關交易才有資格生效。若產生該輸出的交易尚未確認，等待期也還沒有真正開始。

這種設計適合需要「事件發生後保留反應窗口」的安排。例如兩方平時合作時可以共同簽署；若一方失聯，另一條退款路徑要等一段時間才開放。等待期跟著資產實際出現的時點起算，不必為每次新安排重新猜一個遙遠日期。

Lightning 網路的支付通道便會運用時間相關條件。某些結算路徑刻意延後，讓另一方在舊狀態被廣播時有機會提出證明並保護資金。時間鎖在這裡提供的是可驗證的反應窗口；它不能代替監看鏈上狀態，也不能保證使用者在擁塞期間一定來得及完成必要交易。

時間門檻成熟時，資產不會自己換到另一個地址，預先簽好的交易也不會憑空出現在網路上。仍要有人或某套程式保存必要資料、完成合格簽章並廣播交易。若裝置離線、交易檔遺失或鑰匙已經不在，時間鎖不會提供復原能力。

交易廣播後，還要和其他交易競爭有限區塊空間。手續費太低、輸入狀態已改變或交易本身還有其他無效條件，都可能讓它繼續等待或直接失效。時間鎖給的是最早有效界線，沒有承諾「時間一到就排在下一筆」。

同樣地，門檻成熟不會讓 UTXO 過期。只要花費條件沒有另行規定，合格路徑在此後仍可使用。把它理解成門在某刻起允許打開，比理解成倒數結束就自動移轉，更接近實際運作。

時間鎖可用於延遲備援、多方協調、退款路徑與支付通道，但它不會判斷安排是否符合人的原意。高度填錯、期限設得過長、備援鑰匙配置失誤，或繼承人看不懂支出條件，都可能使資產在很長時間內無法正常動用。鏈上規則只會忠實執行已寫入的條件，沒有客服能因情境合理而提早解鎖。

普通錢包的「預約付款」也未必使用鏈上時間鎖。它可能只是讓本機軟體等到指定時間再建立交易；程式若沒有執行，付款就不會發生。反過來，真正的時間鎖能防止過早確認，仍需要可靠的保存、簽署、廣播與費用安排才能在成熟後完成支出。

較穩健的理解方式，是把比特幣時間鎖視為驗證規則中的最早門檻。它能限制一筆交易或某條花費路徑何時開始有效，無法充當精準排程器，也不會替任何人保管鑰匙。這項能力最有價值的地方，在於互不信任的參與者可以共同驗證等待期；最現實的限制，則是等待期之外的操作責任依然存在。