What if locktime was Block number (< 500000000) instead of UNIX timestamp (>= 500000000) I suppose it can no longer be mined before the specified block, right?
Right. The transaction will not be accepted to the mempool until a block at the specified height is found. 
Topic: Can an attacker flood mempool using transaction locktime? (Read 818 times)
♯♯ the transaction could be accepted earlier or later than the time specified by the locktime.
What if locktime was Block number (< 500000000) instead of UNIX timestamp (>= 500000000) I suppose it can no longer be mined before the specified block, right?
So, only Tx with nLocktime of few hour is kept in mempool? If that is the case, then there must be a check in the code that filter Tx with nLocktime higher than a few hour. No?
No. A transaction will only be accepted to the mempool if and only if the median time past or the blockheight is greater than what is specified by the nlocktime. This means that a transaction will not be accepted until after the locktime has passed. Note that nodes now use Median Time Past, which is the median time of the last 11 blocks, which means that a transaction would actually be accepted later than specified by the locktime. However, due to block time fluidity (the time stamp of a block is not absolute), the transaction could be accepted earlier or later than the time specified by the locktime. 
So, locktime has a max limit as well?
Not in the sense that you are thinking about. There is a limit of 4294967296 seconds past the epoch since the nlocktime field is only 32 bits.Could u plz point me to the relevant part of the code in Github, where it is written that Tx having locktime higher than a certain difference between block height will be rejected?
That's not how it works. Any transaction that has nLocktime set is considered non-final and thus rejected by nodes. This happens if the locktime is a few days away, or a few years.So, locktime has a max limit as well?
Not in the sense that you are thinking about. There is a limit of 4294967296 seconds past the epoch since the nlocktime field is only 32 bits.Could u plz point me to the relevant part of the code in Github, where it is written that Tx having locktime higher than a certain difference between block height will be rejected?
That's not how it works. Any transaction that has nLocktime set is considered non-final and thus rejected by nodes. This happens if the locktime is a few days away, or a few years. Quote
so a locktime transaction can be added to the block chain up to two hours before its time lock officially expires.
nlocktime is not an issue. nodes will just reject and not relay transactions if the nlocktime is a year away.
So, locktime has a max limit as well? Could u plz point me to the relevant part of the code in Github, where it is written that Tx having locktime higher than a certain difference between block height will be rejected?
though this is not addressing the OP's question. as that seems to have been answered. i must address meuh's misconceptions of other more realistic risks that malicious users can do, not to fill mempools. but to perform chargebacks
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#freezing-funds
CLTV and nlocktime are 2 separate things
nlocktime stops a tx being confirmed until a certain point(locking out). CLTV stops a confirmed output being spent until a certain point(locking in).
then added in CSV, you can add a revoke code to chargeback.
now to address the double spend offtopic part
watching out for RBF CPFP is the same as watching out for malleability.. in short wait for a confirm if unsure
BIP65 :
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#freezing-funds
Quote
Freezing Funds
In addition to using cold storage, hardware wallets, and P2SH multisig outputs to control funds, now funds can be frozen in UTXOs directly on the blockchain. With the following scriptPubKey, nobody will be able to spend the encumbered output until the provided expiry time. This ability to freeze funds reliably may be useful in scenarios where reducing duress or confiscation risk is desired.
CHECKLOCKTIMEVERIFY DROP DUP HASH160 EQUALVERIFY CHECKSIG
above is how it can add the "maturity" feature to stop people spending a confirmed output until a certain time ONCHAIN (similar concept to rreward maturity)In addition to using cold storage, hardware wallets, and P2SH multisig outputs to control funds, now funds can be frozen in UTXOs directly on the blockchain. With the following scriptPubKey, nobody will be able to spend the encumbered output until the provided expiry time. This ability to freeze funds reliably may be useful in scenarios where reducing duress or confiscation risk is desired.
CLTV and nlocktime are 2 separate things
nlocktime stops a tx being confirmed until a certain point(locking out). CLTV stops a confirmed output being spent until a certain point(locking in).
then added in CSV, you can add a revoke code to chargeback.
now to address the double spend offtopic part
watching out for RBF CPFP is the same as watching out for malleability.. in short wait for a confirm if unsure
If nlocktime is enabled and is in the future on a transaction, the transaction will be considered as non-standard. As per Bitcoin Core 0.8.2,
however, double spenders /malicious users can put transactions with 1hr 59 minutes locktime.. try to sway merchants to accept the tx while unconfirmed to prevent having to wait near 2 hours for it to confirm (or not).. and then use RBF/CPFP to then make a new transaction to swipe the finds to a different destination after the merchant has lazily and wrongly done a trade based on an unconfirmed tx.
there are other new features that can be used by malicious users to screw with merchants. but thats offtopic to your initial question
Even if there isn't nlocktime, CPFP is extremely hard with its small adoption. RBF flags can be easily detected by the merchant and they wouldn't accept it in the first place. For many merchants using Bitpay, such transaction would likely result in waiting for a confirmation. there are other new features that can be used by malicious users to screw with merchants. but thats offtopic to your initial question
however, double spenders /malicious users can put transactions with 1hr 59 minutes locktime.. try to sway merchants to accept the tx while unconfirmed to prevent having to wait near 2 hours for it to confirm (or not).. and then use RBF/CPFP to then make a new transaction to swipe the finds to a different destination after the merchant has lazily and wrongly done a trade based on an unconfirmed tx.
BIP65 :
Quote
The system implemented in its current state does not allow for transactions containing a future nLockTime to be mined into a block until the lock time passes – the transaction sits in the mempool of full nodes on the network.
[...]
When used as part of an output script the new opcode OP_CHECKLOCKTIMEVERIFY checks if the original transaction's nLockTime is larger than the most recent block, and if true the network deems the transaction invalid.
This script locks the output of a transaction, preventing them from being spent in a future transaction unless a certain duration has passed.
[...]
When used as part of an output script the new opcode OP_CHECKLOCKTIMEVERIFY checks if the original transaction's nLockTime is larger than the most recent block, and if true the network deems the transaction invalid.
This script locks the output of a transaction, preventing them from being spent in a future transaction unless a certain duration has passed.
and ... https://github.com/bitcoin/bitcoin/pull/4570 and https://github.com/bitcoin/bitcoin/pull/2340#issuecomment-23233615
b. total size of the bunch of Tx higher than mempool capacity
you run out of fees before you can reach the 1/100 of the available whole network ... mempool.
Quote
so a locktime transaction can be added to the block chain up to two hours before its time lock officially expires.
nlocktime is not an issue. nodes will just reject and not relay transactions if the nlocktime is a year away.
however, double spenders /malicious users can put transactions with 1hr 59 minutes locktime.. try to sway merchants to accept the tx while unconfirmed to prevent having to wait near 2 hours for it to confirm (or not).. and then use RBF/CPFP to then make a new transaction to swap the funds to a different destination after the merchant has lazily and wrongly done a trade based on an unconfirmed tx.
there are other new features that can be used by malicious users to screw with merchants. but thats offtopic to your initial question
If an attackers broadcast a bunch of Tx with the following criteria...
a. high Tx fee
b. total size of the bunch of Tx higher than mempool capacity
c. transaction locktime of a block, which is supposed to be mined after one year
Then which of the following will happen?
i. nodes will crash
ii. Tx fee required for new Tx to be in mempool will be higher than what is set by the attacker
iii. nodes will remove the bunch of Tx with transaction locktime of far future block
p.s. If u dont know about transaction locktime, please refer to - https://bitcoin.org/en/developer-guide#locktime-and-sequence-number
a. high Tx fee
b. total size of the bunch of Tx higher than mempool capacity
c. transaction locktime of a block, which is supposed to be mined after one year
Then which of the following will happen?
i. nodes will crash
ii. Tx fee required for new Tx to be in mempool will be higher than what is set by the attacker
iii. nodes will remove the bunch of Tx with transaction locktime of far future block
p.s. If u dont know about transaction locktime, please refer to - https://bitcoin.org/en/developer-guide#locktime-and-sequence-number
Jump to: