Bitcoin Forum
December 15, 2017, 09:00:35 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Can an attacker flood mempool using transaction locktime?  (Read 714 times)
CoinLearn
Sr. Member
****
Offline Offline

Activity: 330


View Profile
December 14, 2016, 09:50:35 PM
 #1

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
1513328435
Hero Member
*
Offline Offline

Posts: 1513328435

View Profile Personal Message (Offline)

Ignore
1513328435
Reply with quote  #2

1513328435
Report to moderator
1513328435
Hero Member
*
Offline Offline

Posts: 1513328435

View Profile Personal Message (Offline)

Ignore
1513328435
Reply with quote  #2

1513328435
Report to moderator
1513328435
Hero Member
*
Offline Offline

Posts: 1513328435

View Profile Personal Message (Offline)

Ignore
1513328435
Reply with quote  #2

1513328435
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513328435
Hero Member
*
Offline Offline

Posts: 1513328435

View Profile Personal Message (Offline)

Ignore
1513328435
Reply with quote  #2

1513328435
Report to moderator
1513328435
Hero Member
*
Offline Offline

Posts: 1513328435

View Profile Personal Message (Offline)

Ignore
1513328435
Reply with quote  #2

1513328435
Report to moderator
franky1
Legendary
*
Offline Offline

Activity: 1890



View Profile
December 14, 2016, 11:09:55 PM
 #2


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

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Don't take any information given on this forum on face value. Please do your own due diligence & respect what is written here as both opinion & information gleaned from experience. If you wish to seek legal FACTUAL advice, then seek the guidance of a LEGAL specialist.
Meuh6879
Legendary
*
Offline Offline

Activity: 1456



View Profile
December 14, 2016, 11:30:33 PM
 #3

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
Legendary
*
Offline Offline

Activity: 1456



View Profile
December 15, 2016, 12:25:43 AM
 #4

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.


and ... https://github.com/bitcoin/bitcoin/pull/4570 and https://github.com/bitcoin/bitcoin/pull/2340#issuecomment-23233615
ranochigo
Legendary
*
Online Online

Activity: 1288


View Profile WWW
December 15, 2016, 03:15:10 AM
 #5

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,
Quote
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.














 

 

█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
BitBlender 

 













 















 












 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
franky1
Legendary
*
Offline Offline

Activity: 1890



View Profile
December 15, 2016, 03:29:02 AM
 #6

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
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.

    <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

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Don't take any information given on this forum on face value. Please do your own due diligence & respect what is written here as both opinion & information gleaned from experience. If you wish to seek legal FACTUAL advice, then seek the guidance of a LEGAL specialist.
CoinLearn
Sr. Member
****
Offline Offline

Activity: 330


View Profile
December 15, 2016, 03:20:34 PM
 #7


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?
achow101
Moderator
Legendary
*
Offline Offline

Activity: 1246


17kKQppUsngUiByDsce4JXoZEjjpvX9bpR


View Profile WWW
December 15, 2016, 03:26:32 PM
 #8

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
Sr. Member
****
Offline Offline

Activity: 330


View Profile
December 15, 2016, 03:56:12 PM
 #9

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
Moderator
Legendary
*
Offline Offline

Activity: 1246


17kKQppUsngUiByDsce4JXoZEjjpvX9bpR


View Profile WWW
December 15, 2016, 04:05:35 PM
 #10

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
Sr. Member
****
Offline Offline

Activity: 428


Novice C♯ Coder


View Profile WWW
December 15, 2016, 05:08:05 PM
 #11

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

Projects List+Suggestion box
Donation link using BIP21
BitcoinTransactionTool (0.9.2):  Ann - Source Code
Watch Only Bitcoin Wallet (2.3.0):  Ann - Source Code
SharpPusher-broadcast transactions (0.10.0): Ann - Source Code

achow101
Moderator
Legendary
*
Offline Offline

Activity: 1246


17kKQppUsngUiByDsce4JXoZEjjpvX9bpR


View Profile WWW
December 15, 2016, 05:30:49 PM
 #12

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.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!