nLockTime (Timelock) is set to 0
See original GitHub issueI noticed that nLockTime (timelock) of my multisig spend transaction was set to 0. I understand that wallets should not do this. Wallets should set the timelock to the latest mined block to make fee-sniping less profitable. Example: Electrum sets it to the last block number (highest block height).
Is Specter setting this or is Bitcoin Core setting it?
https://b10c.me/mempool-observations/1-locktime-stairs/
setting the current block height as a lock-by-block-height forbids a fee-sniping miner to use transactions from the mempool his replacement block. It creates an incentive to move the chain forward to be able to include the next batch of time-locked transactions in a block. While this does not fully mitigate fee-sniping, it reduces profitability. The more transactions enforce a time lock to the current block height, the less profitable fee-sniping is.
https://en.bitcoin.it/wiki/Timelock
Although every transaction contains the nLockTime field, every wallet up until recently set nLockTime to 0, meaning the transaction was valid in any block. Starting with Bitcoin Core 0.11.0, every normal transaction automatically generated by began including an nLockTime set to a recent block height as a way to make hypothesized fee sniping less profitable[4]; other wallets are recommended to do the same. Approximately 20% of all bitcoin transactions set a nLockTime value different from zero[5] as of early-2019.
Issue Analytics
- State:
- Created 2 years ago
- Comments:7
Top GitHub Comments
@moneymanolis It should be the current block height otherwise the transaction will not be relayed to other nodes:
https://github.com/bitcoinbook/bitcoinbook/blob/2ed56a987479e23bd4cb45e627cd29af0edb2970/ch07.asciidoc#transaction-locktime-nlocktime
Transaction Locktime (nLocktime) From the beginning, bitcoin has had a transaction-level timelock feature. Transaction locktime is a transaction-level setting (a field in the transaction data structure) that defines the earliest time that a transaction is valid and can be relayed on the network or added to the blockchain. Locktime is also known as nLocktime from the variable name used in the Bitcoin Core codebase. It is set to zero in most transactions to indicate immediate propagation and execution. If nLocktime is nonzero and below 500 million, it is interpreted as a block height, meaning the transaction is not valid and is not relayed or included in the blockchain prior to the specified block height. If it is greater than or equal to 500 million, it is interpreted as a Unix Epoch timestamp (seconds since Jan-1-1970) and the transaction is not valid prior to the specified time. Transactions with nLocktime specifying a future block or time must be held by the originating system and transmitted to the bitcoin network only after they become valid. If a transaction is transmitted to the network before the specified nLocktime, the transaction will be rejected by the first node as invalid and will not be relayed to other nodes. The use of nLocktime is equivalent to postdating a paper check.
Sparrow wallet, by default, uses the current block height (example from testnet):
If you decrease the block number:
If you increase the block number:
% nLocktime != 0: https://txstats.com/dashboard/db/blocks-statistics?panelId=4&fullscreen&orgId=1&from=1298794678480&to=1630570678608
Thanks @B-396 , i guess this makes it very clear. We should set it to the current blockheight and maybe make it adjustable in the advanced-section of the send-dialog. That makes it now a good-first-issue!