創建未經確認的比特幣交易
我知道這聽起來很荒謬，但我需要創建一個未經確認的比特幣交易，該交易將在 2 個多小時內未經確認。我得出的結論是，我需要創建一個 0 費用交易，但找不到解決方案，並且播送。另一個變體是設置最小值。費用（1sat/byte），但有時會在 5-10 分鐘後得到確認。如何才能達到預期的效果？
您可以廣播依賴於父交易的交易，直到 2 小時後才廣播。這將確保子交易在父交易被傳輸之前無法進入區塊。
從技術上講，這可以滿足您的要求。然而，孤兒交易不會儲存到比特幣節點的記憶體池中，而是儲存在一個小的（通常只有 100 個空間）孤兒記憶體中。所以很有可能在 2 小時後廣播父母時網路不會知道它 - 即需要再次廣播孩子。
您可以使用時間鎖來實現這一點。
比特幣維基說“時間鎖是一種智能合約原語，它限制一些比特幣的支出，直到指定的未來時間或區塊高度。”
編輯
此外，它寫道：
檢查鎖定時間驗證
2015 年底，BIP65 軟分叉[6] 將 NOP2 操作碼重新定義為 CheckLockTimeVerify (CLTV) 操作碼，允許交易輸出（而不是整個交易）受到時間鎖的阻礙。當呼叫 CLTV 操作碼時，會導致腳本失敗，除非交易上的 nLockTime 等於或大於提供給 CLTV 操作碼的時間參數。由於只有 nLockTime 是過去的交易才可能包含在有效塊中，這確保了基於 CLTV 的時間鎖在交易可能包含在有效塊中之前已經過期。
CLTV 目前用於 CLTV 式的支付渠道。
相對鎖定時間
2016 年年中，BIP68/112/113 軟分叉賦予 nSequence 欄位 [7] 中的某些值強制共識的含義，該欄位是每個交易輸入的一部分，創建“相對鎖定時間”[需要引用]。這允許輸入根據該輸入所花費的輸出包含在塊鏈上的塊中的時間長短來指定它可以添加到塊中的最早時間。
CheckSequenceVerify 也是 BIP68/112/113 軟分叉的一部分是 CheckSequenceVerify 操作碼[8]，它提供相對鎖定時間，與 CLTV 提供絕對鎖定時間相同的功能。當呼叫 CSV 操作碼時，它將導致腳本失敗，除非事務上的 nSequence 指示已通過的相對鎖定時間等於或大於提供給 CSV 操作碼的參數。由於輸入可能僅在其相對鎖定時間到期時才包含在有效塊中，因此這可確保基於 CSV 的時間鎖在事務可能包含在有效塊中之前已到期。
希望這可以幫助。