Which scenario is safer than the other?

[20kevin20]

You've met some random dude to purchase BTC from him. The dude sends you a transaction with a theoretically high-enough mining fee rate, but even after 2 hours of waiting it still isn't confirmed. He's desperately waiting for the tx to be confirmed so that you can give him the cash.. but the network happens to be congested, so now things become uncertain.

Here are two scenarios:
 1. The transaction he sent you is RBF-enabled. He supposedly has an unfortunate emergency and leaves as soon as you receive the first confirmation on the blockchain
 2. The transaction he sent you is non-RBF. He supposedly has an unfortunate emergency and leaves although the transaction has 0 confirmations on the blockchain

You are quite new to the crypto space so you give him the money anyway thinking it's enough.

Which of the two scenarios are now more likely to turn into a scam?

[1714785951]

1714785951

[1714785951]

1714785951

[DaveF]

If it's "theoretically high-enough" as in when I am posting this 50 sat/B should get you into the next block and they paid 60 sat/b and then there were no blocks for 30 minutes and fees went up then there is a chance of a scam. Lets face it, there could have been 2 blocks back to back when they sent the funds and it could have had 2 conformations before they made it to the door of the coffee shop you were meeting at. So you never know. If the minimum fee to be in the next block was 45 sat/b and they paid 45 sat/b then anything could bounce it out so it's a bit more scammy looking.

There is always the "last resort" a very high fee CPFP transaction so it *will* be in the next block.
Who pays the fee would have to be discussed or you just eat the fee knowing that it's part of doing business and you got the funds.

If it's non rbf then you are 100% safe, without some massive double spend attack then it's not going to be in your wallet sooner or later.

But #1 by itself is more likely a scam.



Ignore everything I posted before. I misread the OP and did not see that there already was a conformation.
Once it's confirmed, unless they have some massive mining operations behind them to do a 51% attack, more or less you are safe.
If it's non RBF yeah, they might be able to spend some other inputs and invalidate the TX.

Was on mobile. My bad, keeping the original text for reference in case someone cares.

-Dave

[hosseinimr93]

The first scenario is more safe.

1. The transaction he sent you is RBF-enabled. He supposedly has an unfortunate emergency and leaves as soon as you receive the first confirmation on the blockchain

In this case, the person can scam you only if he can implement 51% attack or in the unlikely event we have a block reorganization (i.e another block has been mined simultaneously)
Note that once a transaction receives the first confirmation, it no longer matters if it was RBF-enabled or not.
Whether it was RBF-enabled or not, the scammer needs to implement 51% attack.

2. The transaction he sent you is non-RBF. He supposedly has an unfortunate emergency and leaves although the transaction has 0 confirmations on the blockchain

It's more risky to accept this transaction.
Even if a transaction hasn't been flagged as RBF, it's possible that a miner includes another transaction spending same inputs with much higher fee.
It's also possible that the transaction has an uncomfirmed RBF-enabled parent. Once the parent is replaced by another transaction, all children will become invalid.

So, if you are going to accept an unconfirmed transaction for any reason (even if it is paying very high fee and hasn't been flagged as RBF), you should check if it has an unconfirmed parent or not.
If there's an unconfirmed RBF-enabled parent, it's very likely that it's a scam.

[NotATether]

I just made a transaction at 30 sats/vB which sat 3MB from the tip. On the other hand, I double-spent that with a 60 sats/vB fee and that was at 1.1MB away from the tip.

Lets face it, the top 1MB of transactions will likely be included in the next block, so even if the mempool is congested as in your transaction is at 45MB from the tip or somewhere around that, you can kinda guesstimate how long it'll take to confirm by multiplying it by the average block time (10) and then waiting for 45*10 minutes. This is assuming you didn't use a ridiculously small fee like 10 sats/vB where the possibility of a rush of transactions bumping you a few megabytes down the tip becomes likely.

That being said, #1 is slightly more dangerous than #2 since because of the high-enough fee, the transaction won't stay in the mempool long enough to get dropped, and the only real danger I see in #1 (assuming you're not dealing with some random dude as LoyceV mentioned!) is a lazy scammer who double-spends on you 10 minutes after he broadcasts the transaction. Otherwise you can just tell him "wait X minutes (where X is MB from tip * 10 + some extra amount*) and it should confirm by then".

* Where the extra is something people can agree with like Celsius to Fahrenheit formula C x 9/5+ 32 = F minutes.

[hosseinimr93]

That being said, #1 is slightly more dangerous than #2 since because of the high-enough fee, the transaction won't stay in the mempool long enough to get dropped, ..........

According to OP, in the first scenario the transaction has already received the first confirmation and I don't think that's very risky.
The transaction is no longer in the mempool and has been included into a block.
It's impossible to remove the transaction from the blockchain unless someone can implement 51% attack or as I mentioned in my previous reply, another block has been mined at the same time and there will be a block reorganization.

[BrewMaster]

since you mentioned "cash" i'm assuming the trade is face to face and what you are handing over to the to her person is also considered "irreversible" which means that the only safe scenario is if the transaction is confirmed (1 confirmation for a small amount and 3+ if it is bigger) then you give up the cash.

if the payment method was anything else, such as a method that had the option to reverse it then either option would have been safe for you since you are making the payment in the reversible way.

[DannyHamilton]

Once it's confirmed, unless they have some massive mining operations behind them to do a 51% attack

It's impossible to remove the transaction from the blockchain unless someone can implement 51% attack or as I mentioned in my previous reply, another block has been mined at the same time and there will be a block reorganization.

Depending on how sophisticated the attack is, this isn't necessarily true.

It is possible that the attacker has control of the internet in the location where you meet up.  It is therefore possible that they have blocked all incoming blocks from the "REAL" blockchain. Perhaps this is why you haven't seen any blocks for 2 hours. Perhaps they already sent a competing transaction that has already been confirmed, and they are blocking you from seeing that.  Instead, the entire 2 hours, they've been attempting to mine a block themselves that has the transaction in it that they sent to you.  Finally, after 2 hours, they've successfully mined a single block (in the meantime, the competing transaction in the "real" blockchain has 12 confirmations already).  They allow their mining equipment to relay to you this one block that they've mined, and you think there is a confirmation on your transaction.  Then they leave and allow the blocks from the "real" blockchain through.  Suddenly your 1 confirmation transaction vanishes and is replaced with a 12 confirmation transaction that isn't paying you.

They would not need a 51% attack to pull this off.  As for mining equipment, they would need only 8.3% of the global hashpower to perform this attack repeatedly and average a 2 hour wait time.  However, they could have even less hash power than that if they either think that they can dismiss any suspicion you have long enough OR are willing to perform the attempted attack many times, knowing that sometimes they'll just have to engage in a legitimate transaction because they run out of time.

Perhaps the attacker actually only has 4.15% of the global hashpower, and they were willing to wait out 4 hours, but got lucky and found that block in only 2 hours.

The real question comes down to... What was the value of the transaction, and how much did the attacker have to spend on hardware and mining processes to complete the attack.  If it's going to cost them $200,000 to pull off the attack each time, plus they are missing out on another $250,000 in block rewards that they could have earned by mining honestly, and their attack only allows them to steal $2000, then why did they bother?  On the other hand, if the attack gains them $3,000,000, then it's perhaps worth it.

This is one reason why, for high value transactions, you want to make sure that both parties have enough time to wait around for multiple confirmations.  Each additional confirmation would cost the attacker in lost block rewards AND spent mining costs. You want to make sure that there is no good reason to use that hash power for fraud because it would turn a much bigger profit just mining normally.

[pooya87]

As for mining equipment, they would need only 8.3% of the global hashpower to perform this attack

This scenario and the numbers are all based on the assumption that the user is running a full node.
Usually people who are trading "away from home" don't carry around their full node, instead they use light clients usually on their phone. So the question also comes down to type of the client and the way it is implemented. For example does the light client validate proof of work or does it accept whatever the multiple nodes it connects to return.

In this scenario it can only connect to one so it would accept whatever block it is given which may not have the needed PoW, the target could be lowered and more blocks could be mined with a simple CPU in a short time.
I'm sure there are more vulnerabilities that could be exploited in these new phone wallets that keep showing up, some of which are closed source and yet popular!

[ranochigo]

Usually people who are trading "away from home" don't carry around their full node, instead they use light clients usually on their phone. So the question also comes down to type of the client and the way it is implemented. For example does the light client validate proof of work or does it accept whatever the multiple nodes it connects to return.

In this scenario it can only connect to one so it would accept whatever block it is given which may not have the needed PoW, the target could be lowered and more blocks could be mined with a simple CPU in a short time.

That assumes that SPV clients do not consider any pre-defined hardcoded checkpoints within the client which would result in the subsequent blocks still being equally difficult or somewhere in that region to be mined. Isolating someone from the actual network is easy if the attacker and have a MITM attack with the client not implementing any redundancies in the process, ie. SSL connection to the servers in the case of Electrum. SPV clients are intrinsically less secure but attacks won't be as easy as that.

51% attacks is a guaranteed success but it doesn't mean that the attacker requires 51% of the hashrate to be able to have any chance to reverse TXes with only a few confirmations. See selfish mining.

[DannyHamilton]

I'm sure there are more vulnerabilities that could be exploited in these new phone wallets that keep showing up, some of which are closed source and yet popular!

The key takeaway here is:

If you are going to engage in transactions with someone you don't have an existing trust relationship with, make sure you actually understand what the risks are, and how to manage those risks. Especially if you are exchanging values that you would find devastating to lose.

[pooya87]

That assumes that SPV clients do not consider any pre-defined hardcoded checkpoints within the client which would result in the subsequent blocks still being equally difficult or somewhere in that region to be mined.

Checkpoints are usually far deep in the chain not close to the head and are only used as the initial line of defense against wasting time to download the early blocks that had low difficulty and could be replaced and nothing more.

Isolating someone from the actual network is easy if the attacker and have a MITM attack with the client not implementing any redundancies in the process, ie. SSL connection to the servers in the case of Electrum. SPV clients are intrinsically less secure but attacks won't be as easy as that.

That's true and we are exploring hypothetical scenarios. In case of SSL it would be possible to trick the user to install a certificate authority to use the network where they are in which case the CA could accept the fake SSL keys pretending to be the legit servers.

[ranochigo]

Checkpoints are usually far deep in the chain not close to the head and are only used as the initial line of defense against wasting time to download the early blocks that had low difficulty and could be replaced and nothing more.

So for the checkpoints within Electrum, they wouldn't do anything to protect against a sybil attack? My impression is that it makes attacks more costly as the difficulty of a block has to be much higher. If they are able to generate a block, then it could be a better idea to just mine legitimately?

[pooya87]

So for the checkpoints within Electrum, they wouldn't do anything to protect against a sybil attack?

I don't think so. There are 327 hardcoded checkpoints in checkpoints.json up to block 000000000000000000046f183ba323cfceb2d11660376c59fb55e8521c4d32a5 (height = 659231).
As far as I can tell in Electrum hashes and targets are checked against this data for the initial synchronization before being stored as being valid, I believe it is mainly used to make sure that Electrum is on the correct chain not an altcoin's chain (like BCH) that may fork at any time but have the same difficulty, since Electrum doesn't download blocks to know which header of which block is an altcoin header.

My impression is that it makes attacks more costly as the difficulty of a block has to be much higher. If they are able to generate a block, then it could be a better idea to just mine legitimately?

That's true.
The important part is that in Electrum all headers are also validated individually and the PoW is verified by calculating the next target here just like how a full node like bitcoin core would.

This means if you wanted to fool Electrum to accept a new block through a Sybil attack it must have the correct proof of work which is currently very big and requires a lot of work as @DannyHamilton explained above.

[Theb]

Scenario#1 is a more safer scenario for the recipient waiting for a transaction since the transaction is already confirmed in a block and the sender won't be able to use the RBF enabled transaction since the transaction is already confirmed. Remember that for possible attacks such as doubled spending and the 51% attack the most important thing to look out for is the number of confirmations you have for your transactions so members are right to point out that it doesn't matter if the transaction is RBF enabled or not as long as the transaction itself is confirmed it is what matters the most.

[o_e_l_e_o]

In this case, the person can scam you only if he can implement 51% attack or in the unlikely event we have a block reorganization (i.e another block has been mined simultaneously)
Note that once a transaction receives the first confirmation, it no longer matters if it was RBF-enabled or not.

It does matter if it was RBF or not in the context of a chain reorganization.

Let's say the transaction was included in one mined block, and therefore had one confirmation when checked on a specific block explorer. However, it was not included in a competing block at the same height. If the transaction was RBF enabled, then it becomes trivial to replace it in the mempool of nodes working on the second block in which it still is unconfirmed.

As you say, RBF makes no difference in the context of a 51% attack, since the attacker can freely choose to replace their non RBF transaction with a competing transaction anyway.


I would agree that the second scenario is more dangerous than the first. Once we have one confirmation, then reversal depends on having a significant percentage of the hashrate (but does not require 51% to be a possibility), or a chain reorg. With zero confirmations, there could already be a competing transaction sitting in some nodes' mempools. After 2 hours, the transaction is highly unlikely to still be within 1 vMB of the tip, and with current mempool activity could take days to confirm. It could drop without confirming at all. It could be purged due to higher fee transactions. The other party could pay miners to try to include a different transaction.

[DaveF]

Usually people who are trading "away from home" don't carry around their full node, instead they use light clients usually on their phone. So the question also comes down to type of the client and the way it is implemented. For example does the light client validate proof of work or does it accept whatever the multiple nodes it connects to return.

In this scenario it can only connect to one so it would accept whatever block it is given which may not have the needed PoW, the target could be lowered and more blocks could be mined with a simple CPU in a short time.

That assumes that SPV clients do not consider any pre-defined hardcoded checkpoints within the client which would result in the subsequent blocks still being equally difficult or somewhere in that region to be mined. Isolating someone from the actual network is easy if the attacker and have a MITM attack with the client not implementing any redundancies in the process, ie. SSL connection to the servers in the case of Electrum. SPV clients are intrinsically less secure but attacks won't be as easy as that.

51% attacks is a guaranteed success but it doesn't mean that the attacker requires 51% of the hashrate to be able to have any chance to reverse TXes with only a few confirmations. See selfish mining.

Also, keep in mind that although a lot of what is being discussed CAN happen, the costs & time involved mean it probably will NOT HAPPEN.
The costs involved would be so high as to never being able to generate a profit.

Yeah, I could probably setup some sort of a MITM setup for the popular mobile SPV wallets (Mycelium, coinomi) that unless the user has made changes connect to known servers on known ports.

But, since there are a lot of "Electrum servers in a box" setups that people use you would have to find and redirect those too. And geeks like myself usually configure to only connect to my node on a different port. So the scam falls apart there.

4/5G connection instead of Wi-Fi, scam falls apart there

Oddball wallet that you didn't setup the MITM for scam falls apart there.

Samurai whirlpool since it's coming from elsewhere, scam falls apart there.

It would be easier, cheaper, and probably more reliable to find some knuckle draggers with bats to grab you and take the money.

On the 51% attack side, and all the other back end planning. Once again, yes it's possible and with as someone mentioned all the oddball wallets out there who knows how good they are. But once again, it's probably easier, cheaper, and more reliable to publish your own fake wallet and just let people install it and take their money.
Remember, to do the above things mentioned (MITH, 51%, etc) you need a fair amount of technical knowledge. To re-skin and redo a bit of the copay or electrum mobile wallet and get it out there to people would probably generate a lot more money.

-Dave

[20kevin20]

Thanks for the discussion this curiosity started from a discussion on the Romanian board where someone wanted to purchase coins worth €150k in cash.

As far as I can tell from the answers here, the second option is way more dangerous than the first and in order to accomplish such an attack, you need some pretty heavy resources. Since the sum was quite large, I thought it might not be that far-fetched for someone to attempt a manipulation.

A MITM attack is probably way less likely to succeed today since 4G and 5G are more likely to be used than the local Wi-Fi nowadays. So in order to set up such an attack and succeed it, you would need to meet up with a multitude of potential victims until you find one who fits your setup and uses the local Internet connection.

Even if a transaction hasn't been flagged as RBF, it's possible that a miner includes another transaction spending same inputs with much higher fee.

So without RBF I guess I can still use Electrum to manually delete the transaction and re-broadcast it with a higher fee and differenr outputs? Is that because miners take higher fees with priority? I thought a non-RBF tx automatically means a re-broadcasted one will be invalid.

[ranochigo]

So without RBF I guess I can still use Electrum to manually delete the transaction and re-broadcast it with a higher fee and differenr outputs? Is that because miners take higher fees with priority? I thought a non-RBF tx automatically means a re-broadcasted one will be invalid.

You can. Miners are ultimately the ones that determines the transactions that are included in their blocks.

By default, the reference client with those which recognizes opt-in RBF flags will not relay replacement transaction if the transaction that it is supposed to replace does not have a opt-in RBF flag. As such, having no RBF flag would only result in the replacement transaction having a poor propagation provided that those nodes have knowledge of the first transaction. Replacing a transaction without a RBF flag will not make that transaction invalid, just that the poor propagation will result in miners potentially having no knowledge of it.

[o_e_l_e_o]

I thought a non-RBF tx automatically means a re-broadcasted one will be invalid.

Not invalid, just not propagated as ranochigo has explained.

In reality, an attack trying to use this method would likely broadcast the two transactions simultaneously or very close to simultaneously. Some nodes would see and accept transaction A first, while others would see and accept transaction B first. In both cases, the nodes would reject the alternative transaction. Which one gets mined first would depend somewhat on chance.

If I know which node you are using to look up unconfirmed transactions, then I can potentially use that to my advantage. I can broadcast the transaction I want you to see to that one node, while simultaneously broadcasting a competing transaction to 100 other nodes. This would mean that you only see transaction A, but in reality, most of the rest of the network sees transaction B, making transaction B most likely to confirm.

[DaveF]

Thanks for the discussion this curiosity started from a discussion on the Romanian board where someone wanted to purchase coins worth €150k in cash.

Which kind of goes back to my big guys with bats theory to get the money back, instead of some oddball method.
Not to mention you can get the persons phone and send the coins back to yourself.

Large cash transactions are always going to be a risk.
Unless you do it in a back that you are putting the cash in, and using a phone that only has a watch only wallet for addresses you have control over, and you bring some large friends with you for support.

But, with going through all that time and expense, you might as well use Coinbase (or similar).
Remember, in this example, to be safe you just put your money in a bank, so it's not like you are hiding it.

-Dave