How easy would it be to fake transactions?

[Poker Player]

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.

[1714947253]

1714947253

[1714947253]

1714947253

[1714947253]

1714947253

[1714947253]

1714947253

[Poker Player]

If you actually mean invalid signature/non-existent UTXO when you say "fake", it's impossible since each node verify the transaction before it's being shared with other node.

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

[o_e_l_e_o]

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

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.

[stompix]

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

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.

[ranochigo]

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.

[nc50lc]

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.

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

[NeuroticFish]

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

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.

[LoyceV]

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.

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.

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.

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

[hosseinimr93]

There is also the even less likely Finney attack...........

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.

[o_e_l_e_o]

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.

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.

[LoyceV]

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.

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.

[o_e_l_e_o]

That's a very risky game to play as a miner!

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.

[DaveF]

That's a very risky game to play as a miner!

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.

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

[Poker Player]

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.

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.

So it's not very likely that that kind of transaction would be made by someone who comes to my coffee shop to pay me for coffee, unless they're not sane or something like that.

These questions had come to my mind because of the issue of day to day payments and, although LN is better, I see that it would not be so difficult to accept small payments via blockchain, without waiting for confirmation or waiting for just one, because with cash and cards there is also the risk of being scammed and not for that reason coffee shops stop accepting them.

I guess a bigger problem for Bitcoin to be used for day-to-day payments would be scalability.

[pooya87]

So it's not very likely that that kind of transaction would be made by someone who comes to my coffee shop to pay me for coffee, unless they're not sane or something like that.

Let's just say that there is a good chance that the person paying for coffee with cash is handing you a fake bill than there is a chance of that kind of attack happening on bitcoin transaction.

I guess a bigger problem for Bitcoin to be used for day-to-day payments would be scalability.

The biggest problem for bitcoin as a currency is still its volatile price in my opinion, since it encourages "investment" rather than spending. Otherwise we have LN that solves the scalability well enough.

[LoyceV]

Otherwise we have LN that solves the scalability well enough.

I doubt it: LN still requires on-chain transactions for opening and closing channels, and that still depends on on-chain block space. It would be impossible for (say) 100 million people to each open a few LN channels next year. That leaves custodial (LN) wallets as a solution, and for small amounts I'm okay with that additional risk.

[stompix]

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.

The main problem with this is that there is almost no business that would release your goods worth hundreds of thousands of dollars 30 minutes after the confirmation and have no way of tracking you back when they observe what happened. As DaveF mentioned, if you go buy a Lambo there is no way 30 minutes after the confirmation you've got your keys and you can afterward hide yourself and the car forever, casinos won't let you withdraw large sums after such a short time and so on, and speaking of Lambos, the block reward stands above 300k, just screwing your chances at one extra legit block negates the prices of almost all models of cars.

To do such a thing with a slim chance of keeping your identity hidden I see only a possibility that would make some sense, if you find an exchange with enough volume to matter and one that would let you use your funds after one confirmation and use a ton of BTC from multiple accounts to pump some shitcoin or to dump the price temporarily in one go, enough to cover some huge million bets put on some other platforms.
Furthermore, this attack would allow you to try it numerous times, since if you make the transaction invalid you just withdraw the money back to your wallets and try again next time, with the lambos you might end buying 10 000k of them before you manage to grab one for free.
But the consequences of this price manipulation went it comes to light might erase all your gains.

So it's not very likely that that kind of transaction would be made by someone who comes to my coffee shop to pay me for coffee, unless they're not sane or something like that.

Or you make really good coffee  

[LoyceV]

casinos won't let you withdraw large sums after such a short time

It's even easier: if a casino allows zero-confirmation deposits, you can simply go all in. If you win, you wait for confirmations and withdraw your funds. If you lose, you invalidate the deposit by double spending.

[stompix]

casinos won't let you withdraw large sums after such a short time

It's even easier: if a casino allows zero-confirmation deposits, you can simply go all in. If you win, you wait for confirmations and withdraw your funds. If you lose, you invalidate the deposit by double spending.

And if you lose and you fail at invalidating the chain? 
Not only do you have a gambling situation on getting the blocks now you add more with the gambling itself, it would be better to try a trifecta at the Grand National, at least you risk 1$ and you might get well over 10k, and I still think the odds are better. Not even mentioning if the casino is 1xbit....

[pooya87]

Otherwise we have LN that solves the scalability well enough.

I doubt it: LN still requires on-chain transactions for opening and closing channels, and that still depends on on-chain block space. It would be impossible for (say) 100 million people to each open a few LN channels next year. That leaves custodial (LN) wallets as a solution, and for small amounts I'm okay with that additional risk.

Well this is why I have talked about increasing the block size in the past. So far we are OK since the adoption is not that fast to get 100 million people into bitcoin in a year and those who are adopting bitcoin aren't all using it for payment. By the time we get to that situation (probably in another decade) we must have a hard fork.