Topic: How easy would it be to fake transactions? - page 2. (Read 438 times)

The problem with the above attack is that it's just not worth it.
It really would have to be an epic one and done kind of thing, since after that payment processors and the rest of the internet are gong to know that miner is doing something funky.
And what are they really going to get out of it.

It's the equivalent of doing a "Mission Impossible" getting into the server room to steal a bag of chocolate. And then never to be trusted again.

And if it's real durable goods, say you got your Lambo and got out of the dealership before they figured out what happened. You are going to do what when the lawyers show up at your house asking for money?

It's all theory, but no more theory then me getting onto the roof of a WalMart store so I can get into their IT room to install my own router so when I go back in and run my credit card to buy my PS5 it just gives and approval instead of really running my card. I would be better off just grabbing the Cisco 8300-2N2S-4T2X router out of the server room and running out the door with it.

-Dave

Yes, absolutely. As I said in my first reply, this attack would be even less likely than a Race attack, which is already going to be incredibly rare. It may have been a feasible attack when the block reward (plus fees) was worth only a handful of dollars, but now it is far more profitable for the miner to just mine honestly.

The caveat to this is if the miner has a significant proportion of the hashrate and has a non-negligible chance of being able to mine a longer chain than honest miners when they both start from a given point. I broadcast a transaction which pays the merchant, while at the same time mining in secret a different transaction which double spends those coins back to myself. Once I find a block, I continue to mine more blocks in secret which build on my dishonest block. After the main chain has (for example) 3 confirmations, and the merchant delivers my goods, I then release my dishonest chain which has 4 blocks, and everyone swaps to my longer chain, invalidating the initial transaction to the merchant.

That's a very risky game to play as a miner! Let's assume a mining reward of 6.5BTC (including transaction fees), and 10 minutes per block. That means that every second you wait before you broadcast it, you lose about $500 (I took some shortcuts in the math to make a point). Maybe it's better to say there's a 1% chance of losing $300,000 for every 6 seconds it takes before you broadcast the transaction.
So for a small amount, it's not worth it. And for any substantial amount, the receiver will wait for more than one confirmation, so this won't be a problem either.

Exactly. I create, sign, and mine the double spend transaction in secret and include it in my own block, while publicly broadcasting the other transaction which sends the coins to the merchant. Other nodes will only discover that the transaction in their mempool was a double spend after it is too late, when they receive and validate my block and see the competing transaction, which will immediately have 1 confirmation.

It's the first time I've heard of such attack.
That pre-mined block can't really increase the chance of the success of the attacker very much. Am I right?

Let's say I have control over addresses A and B and I am a miner.
I make a transaction from address A to address B in transaction A and include it in a block. I don't broadcast that block.
Now, I double-spend same UTXO(s) from address A to address C in transaction B and broadcast it.

Although the block including transaction A hasn't been broadcast yet, it's still very unlikely that the transaction B can enter the mempool of the node address C owner is connected to. Because the transaction B has been broadcast later than transaction A.


Edit:
I should keep the transaction A in my own mempool and don't broadcast that before broadcasting the block including that. Right?
In this way, other nodes won't flag transaction B as a double-spend attack and it can enter their mempool.

Years ago I saw a scam in which Blockchain.info's block explorer showed transactions as real, but they weren't in any other block explorers and they never confirmed. I don't know how it was done, and clearly it's one of the many bugs that site has, but it made it much easier to trick people.

Anyone who accepts zero-confirmation transactions should at least check if all inputs are confirmed.

From what I know, usually payment processors accept 0-confirmation transactions as done only if they don't have RBF flag on.
The problem I see is that a malicious customer may already send you unconfirmed input. And even if the fee in your direction is just fine, the unconfirmed parent has a very low fee and has a good chance to get double spent. And when the parent is double spent, the children will become invalid. Of course, the malicious customer has to find the right balance so he doesn't do CPFP by mistake, but that can be done. I think that I've seen that when the network was congested.

There is one widely used scheme but it's not using a fake transaction (can be used in that "every day spending" scenario).
It's done by utilizing "replace-by-fee" flag which makes a transaction replaceable as long as it's not included in the blockchain yet (0 confirmation).
However, such transactions can be easily identified so merchants that accept 0-confirmation txns (eg. some Casinos) don't grant the "instant deposit" benefit if it has an 'rbf' flag.

It goes like this: The transmitted "unconfirmed" rbf flagged transaction will be seen by most clients and the victim,
but when the scammer received what he paid for and wants to "cancel" it, he just have to send another transaction transaction that spends the same input(s) and replace the output with his own address. That essentially boots out the old transaction from most mempools.
Bitcoin Core with default setting are setup to replace the older transaction with rbf flag as long as the new transaction follow some specific rules.

BIP-0125: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#Implementation_Details

You cannot fake a transaction, because every node checks for it's validity. You cannot spend something that doesn't exist or if the signature isn't valid. The only exception being some sort of design flaw which inadvertently causes the node to pass some checks even if it is not supposed to. That would be incredibly rare to say the least, because it isn't that difficult to check for the few simple criteria.

Merchants calculate certain risks that they are able to bear. Be it through the percentage of revenue that they're making or frauds that would happen with other payment methods.
On top of that, merchants evaluates the risk of every transaction, how likely is it for someone to double spend the transactions and what they'll otherwise gain. If the risk is acceptable, then there is nothing wrong with accepting zero-conf transaction.

Of course, LN is practically instantaneous and many merchants have switched to that.

So it's about accepting zero-confirmation transactions.
This has always been a known risk, and there is no way you can completely and successfully prevent it 100% when accepting them and letting your client leave with the merchandise or releasing funds before at least one confirmation.

As for how likely it is, I doubt somebody would do this for a coffee and I doubt any of your regulars would do it, in this era every shop has cameras, the tx will be recorded you will know who tried to cheat you on it, you can ban him from the store and what have you lost...a coffee. What has he gained? One coffee! It would be ridiculous to even try this shit as the cost he will have to pay for the traction which renders the first null will probably be half of that or even more.

But accepting transactions worth thousands with a 1sat/b fee that is clearly marked as RBF from a stranger when the mempool is full is like holding a sign asking poeple to rob you.

Not very likely (assuming RBF is not enabled, of course).

Let's say I am a customer at your coffee shop. Such an attack is usually a Race attack, which would require me to broadcast a transaction paying for my coffee which you will see, while at the same time broadcasting a different transaction to the rest of the network which will double spend the coins which I am using to pay for my coffee back to myself. This requires me to have an intimate knowledge of how your bitcoin wallet is set up and which node or nodes you are connected to so I can broadcast the first transaction to nodes you are connected to so that is the one you will see, while the second transaction spreads through the rest of the network. Even then, there is also absolutely no guarantee this would work since both transactions are in the mempool and either could be confirmed. If your wallet is well connected, then almost certainly at least one of the nodes you are connected to will see both transactions and flag up that there is a double spend attempt happening.

There is also the even less likely Finney attack, where I am a miner and I have already mined but not broadcasted a block which includes a transaction sending some coins I control to another address I control. Instead of broadcasting this block, I instead go in to your coffee shop, buy a coffee, broadcast a transaction using those same coins to pay for my coffee, wait for you to hand over the coffee, and then broadcast my block which double spends those coins back to myself.

My technical knowledge is very basic but no, I wasn't thinking about that.

What I think is: suppose I have a coffee shop and I decide to accept bitcoin for coffee payments (let's leave aside LN), but I will accept the payment as good as soon as I see that the transaction is retransmitted to the blockchan. How likely is it that someone will slip me a transaction that won't be confirmed (and that doesn't have a very low fee, which I could check and reject the transaction based on that).

After seeing the answers that have been given to what the OP asks in this thread:

BTC as "every day" spending currency vs. 10 min Block Confirmation/Mining time

A couple of questions come to mind, which I thought it would be pertinent to ask in a separate thread.

The first one is how easy it is to create a fake transaction and transmit it to the whole blockchain without it being instantly detected as fake.

The second is: once we have a first confirmation of a transaction, how could it happen that the transaction is rejected by the rest of the miners? Would it mean that the first one is part of the scam if he validates that fake transaction or not necessarily? What would be the level of difficulty of doing this?

This comes to my mind because for day to day payments if the difficulty is high maybe some businesses could accept a transaction as soon as it is transmitted to the blockchain. There is a website where I have made several purchases and lately they show the payment as confirmed  as soon as they detect that the transaction is transmitted to the blockchain, without waiting for the first confirmation. Obviously they are small amounts but quite larger than the price of a coffee.