Topic: Which scenario is safer than the other? (Read 296 times)

Depends on a few things.
As a rule, if you are putting it into a private account, yes they are going to look at you. If it's a commercial / business account, not so much.
Also, how "off" is it from your usual money moving. In the US they will do a SAR form since it's over 10k in cash. but if you move a lot of cash in & out of your account it probably will not go past that.
If your last 500 deposits were for $125 or less and then you drop $125,000 into your account. Red flags are going to pop up.

Also, it depends on the bank and how long you have been there. I have one account that is decades old it's amazing how much even a crappy bank like the one I have it in will help out an old time small account holder then a new larger one. Odd, but true.

Either way, it would be such a fringe case, probably would not ever happen.

-Dave

All methods have weak points. Face to face is good since you don't really leave much information about you, your partner or your transaction - but on the other hand, you risk being scammed or robbed. Trading through p2p exchanges is good since you cannot be physically attacked or robbed, but on the other hand it's risky to get that much cash into your bank since you are going to likely be interrogated about the sum/source of funds. If you want to trade without compromising privacy, you will always have a quite strong weak point to be afraid of (if that makes sense). Privacy has a cost, and these are the ones you have to go accept for p2p txs.

There is also cash by mail - but I'm not sure how that would work when you have 1.5/10 of a million to send?

Probably even worse in this case. Showing up unannounced to your bank to deposit $150k in cash is going to raise multiple red flags for anybody. This looks like money laundering until proven otherwise. They might cash the funds, but they won't credit them to your account before you hand over more information, proof of source of funds, perhaps some enhanced ID checks, etc. Good luck providing "proof of funds" that your average bank would accept saying "I just sold 3 BTC in cash".

I wonder what is the best way of selling a large amount of bitcoin and getting the fiat in to the banking system without giving away KYC beyond that required for a basic bank account.

I never too consider buying or selling BTC for cash with someone personally is safe too, if people care about the taxation system then they can go with p2p trading platforms where the trading volumes are more higher than $150K but still the user maybe asked for KYC details.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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?

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.

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.

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.

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.

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!

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.

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.

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.