Can an attacker flood mempool using transaction locktime?

[CoinLearn]

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

[1713534762]

1713534762

[1713534762]

1713534762

[1713534762]

1713534762

[1713534762]

1713534762

[1713534762]

1713534762

[franky1]

https://bitcoin.org/en/developer-guide#locktime-and-sequence-number[/i]

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

[Meuh6879]

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.

[Meuh6879]

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 :

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.

and ... https://github.com/bitcoin/bitcoin/pull/4570 and https://github.com/bitcoin/bitcoin/pull/2340#issuecomment-23233615

[ranochigo]

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,

Non-standard transactions are not relayed across the network, are not included in blocks by most miners, and will not show up in your wallet until they are included in a block.

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.

[franky1]

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

BIP65 :

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#freezing-funds

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.

    <expiry time> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> 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)
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

[CoinLearn]

https://bitcoin.org/en/developer-guide#locktime-and-sequence-number[/i]

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?

[achow101]

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.

[CoinLearn]

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.

Ok.

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, 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?

[achow101]

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.

[Coding Enthusiast]

♯♯ 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?

[achow101]

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.