What makes an unconfirmed tx 'suspicious'? (likely to be replaced or never confi

[RocketNutz]

When looking at Bitcoin unconfirmed transactions, I'm trying to distinguish between txs that are likely to confirm (whether that be in the first next block or in 2 hours) versus txs that are likely to be replaced, or never to confirm at all.

Obviously, txs with the opt-in RBF flag fall in the latter category. But I guess there are other criteria, such as:

• Having an extremely low fee, or even zero fee.
• Having lots of dust outputs.
• Depending on unconfirmed inputs.

   
Anything else I should take into consideration? What other factors could make a tx less likely to end up confirmed? I guess criteria that cause a tx to be considered "spam" are closely related to this.

For example, besides dust output, do dust (i.e. many small) inputs make a tx less sure to confirm? (other than more inputs causing larger tx data, thus resulting in a lower fee when measured in satoshis per KB)

P.S. I realize there's no single way of doing this, and there's never certainty about this anyway. I'm just looking for some indicators that give a reasonable estimate.

[achow101]

You should check if the sequence number is not 0xffffffff, if the fee is to low, if the transaction depends on any unconfirmed inputs, and if it has dust outputs. These are pretty much the only things that will prevent transactions from confirming

[merelcoin]

I'm no expert, but i think you've covered most of the cases correctly.

Altough, if i understand it correctly, it's only the ammount of satoshi's per byte that is important when it comes to fees. If you have a huge amount of dust inputs, but the amount of satoshi's per byte is still high enough, the confirmationtime will probably be OK.
You can always check how long the estimated confirmation time for your fee will be by looking at this page: https://bitcoinfees.21.co/

btw: i don't know what project you're working on, but i'd never accept zero-confirmation in any project of mine. Even with big fees you run the risk of double-spending if you don't wait at least for 1 (or more) confirmations. If you need at least 1 confirmation, it's the sender's problem. If he doesn't include a high enough fee, he'll get his product/subscription/balance later than when he adds sufficient fees.

[achow101]

Altough, if i understand it correctly, it's only the ammount of satoshi's per byte that is important. If you have a huge amount of dust inputs, but the amount of satoshi's per byte is high enough, the confirmationtime will probably be OK.

No, it is not only just the fee. Dust outputs will slow down confirmations because dust outputs are considered nonstandard. This means that the transaction is less likely to be relayed and accepted by nodes, which will make confirmations slower.

[merelcoin]

Altough, if i understand it correctly, it's only the ammount of satoshi's per byte that is important. If you have a huge amount of dust inputs, but the amount of satoshi's per byte is high enough, the confirmationtime will probably be OK.

No, it is not only just the fee. Dust outputs will slow down confirmations because dust outputs are considered nonstandard. This means that the transaction is less likely to be relayed and accepted by nodes, which will make confirmations slower.

Thanks! I actually didn't know this... I always thought it was just the amount of satoshi's per byte, but apparently i was wrong 

[alani123]

Zero fees would now have your transaction rejected, not just stuck.

[cr1776]

Zero fees would now have your transaction rejected, not just stuck.

That is inaccurate.  It *could* have it rejected, but it would depend on the priority.

See e.g.
https://github.com/bitcoin/bitcoin/blob/master/src/policy/fees.cpp

[alani123]

Zero fees would now have your transaction rejected, not just stuck.

That is inaccurate.  It *could* have it rejected, but it would depend on the priority.

See e.g.
https://github.com/bitcoin/bitcoin/blob/master/src/policy/fees.cpp

I said now for a reason... 

[RocketNutz]

Thanks for all your feedback.

Is there some generally agreed upon boundary for "enough" or "too low" fees? (in satoshis per byte, I know it's not about the total fee amount)

Similarly, is there a standard limit for dust? When I mentioned dust outputs I was just referring to outputs with very small amounts, but is there universally accepted threshold for when to consider something dust?

Also, do these dust and fee criteria depend on the current network congestion (size of memory pool or total number of unconfirmed txs)? And does the Bitcoin days destroyed measurement play a role in this?

[achow101]

Thanks for all your feedback.

Is there some generally agreed upon boundary for "enough" or "too low" fees? (in satoshis per byte, I know it's not about the total fee amount)

It depends on the network. I use http://bitcoinfees.21.co/. Right now "too low" is about 30 satoshis per byte.

Similarly, is there a standard limit for dust? When I mentioned dust outputs I was just referring to outputs with very small amounts, but is there universally accepted threshold for when to consider something dust?

A dust output is 2730 satoshis. It is defined by a node's minimum relay fee, which right now is 1000 satoshis by default. The dust amount is any output where you would have to pay more than 1/3 of the amount in fees. It's definition is at https://github.com/bitcoin/bitcoin/blob/28ad4d9fc2be102786a8c6c32ebecb466b2a03dd/src/primitives/transaction.h#L161.

Also, do these dust and fee criteria depend on the current network congestion (size of memory pool or total number of unconfirmed txs)?

They do depend on network congestion, especially fees

And does the Bitcoin days destroyed measurement play a role in this?

Not really. There is/was space in blocks for "priority" transactions which involved Bitcoin days destroyed, but I think that is being removed from Bitcoin Core. Of course, it is up to the miner to choose the transactions they want to include and the miners may have different criteria.

[DannyHamilton]

The advice you've received so far is pretty thorough for the easy to accomplish "suspicious" transactions.

There are a few more conditions that might be possible depending on your particular situation.

For example, if you were looking at accepting bitcoin as payment in a physical location (such as a coffee shop), it may be possible for an attacker to connect to your wallet on your local in store network, while interrupting your access to the internet at the same time.  If he can do that, then he can send you a transaction that meets all the criteria that you've been discussing so far (high fees, no dust, only uses confirmed inputs, proper sequence number, etc) while simultaneously broadcasting a competing transaction to the rest of the network.  A few seconds later, he could drop his connection to your wallet and stop his interruption of your access to the internet.  The bitcoin network won't know about the transaction that you received. Also, you won't know about the transaction that the rest of the bitcoin network received until that transaction eventually gets confirmed.

Additionally, if you were looking at accepting bitcoin as payment for an internet based service, it may be possible for a mining farm or mining pool to broadcast a transaction paying you, and then start trying to secretly include a competing transaction in the block they are working on.  If they succeed in winning a block before any other miner (or pool) confirms the broadcast transaction, then they can broadcast their block and your unconfirmed transaction will vanish.

[cr1776]

Zero fees would now have your transaction rejected, not just stuck.

That is inaccurate.  It *could* have it rejected, but it would depend on the priority.

See e.g.
https://github.com/bitcoin/bitcoin/blob/master/src/policy/fees.cpp

I said now for a reason... 

And it still is not accurate.  I can send a high priority transaction with no fees now and have it confirm pretty quickly.

[alani123]

Zero fees would now have your transaction rejected, not just stuck.

That is inaccurate.  It *could* have it rejected, but it would depend on the priority.

See e.g.
https://github.com/bitcoin/bitcoin/blob/master/src/policy/fees.cpp

I said now for a reason... 

And it still is not accurate.  I can send a high priority transaction with no fees now and have it confirm pretty quickly.

Ah, I see what you're saying now. Yeah, that's a possible scenario. Although it's mostly depended on inputs other than anything else.

[cr1776]

Zero fees would now have your transaction rejected, not just stuck.

That is inaccurate.  It *could* have it rejected, but it would depend on the priority.

See e.g.
https://github.com/bitcoin/bitcoin/blob/master/src/policy/fees.cpp

I said now for a reason...  

And it still is not accurate.  I can send a high priority transaction with no fees now and have it confirm pretty quickly.

Ah, I see what you're saying now. Yeah, that's a possible scenario. Although it's mostly depended on inputs other than anything else.

Agreed.  ;-)

Low priority transactions at the current time are often problematic.

And to follow up on what Danny said, if you are selling something that is expensive waiting for a few confirms is probably a good move.

[danda]

zero confirmations make it suspicious.  period.

solution:  wait for at least 1 confirmation.  more if high value.

otherwise if you feel you must accept zero conf, then I would think the most cost effective manner would be to (a) put a limit on the highest value tx you will receive with 0 conf, and (b) track the number of double-spends you encounter along with the avg amount lost and factor those into your business model.

or just:  wait for lightning network to mature.

[RocketNutz]

zero confirmations make it suspicious.  period.

Sure, but I'm trying to measure HOW suspicious. Or making a distinction between risky and not-so-risky txs.

A tx without opt-in RBF flag, one confirmed input, two non-dust outputs, and a fee of 100 satoshis per byte, is way less suspicious (or perhaps I should say: way less likely to be replaced or never confirm) than a tx WITH opt-in RBF, spending lots of unconfirmed UTXOs from multiple transactions, lots of dust outputs, and a fee of 2 satoshis per byte.

It all depends on the amount of money we're talking about, but I would feel quite safe accepting the first kind of tx for typical retail purchases up to a few hundred dollars.

[Syke]

Consider time. A 1 minute old tx is far less risky than a fresh tx (assuming the rest of the tx is clean) if no double-spends on the tx show up.

Also, you want your node to be well connected. If you only have a single peer, you are at risk.

[johoe]

You should also check that the unconfirmed transaction is standard.  See
https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L56

In particular you need to check that the script is a standard P2PKH or P2SH or multisig, that the signature is well-formed, that there are no unnecessary 0s in the encoding, etc.

[bob123]

Consider time. A 1 minute old tx is far less risky than a fresh tx (assuming the rest of the tx is clean) if no double-spends on the tx show up.

Also, you want your node to be well connected. If you only have a single peer, you are at risk.

This is something people mostly dont think of.
The more Connections you establish the safer you are.