You are misunderstanding the mechanics of the attack. Let’s say that there is a DSP enabled vending machine where a user can buy a $5 snack bar and the candy is released after 5 seconds. Bob does a transaction for $5 with a $0.01 fee, waits 5 seconds and takes the candy. Then Bob constructs a conflicting transaction to himself with a $1 fee and broadcasts to many nodes. If the original transaction confirms (“attack failed”) Bob got his candy for a total of $5.01 and if the conflicting transaction confirms (“attack succeeded”) he got his candy for $1. Bob hasn’t lost anything if the attack failed and the DSP didn’t help the vendor.
1 Like
Wait, this is not right.
The transaction should be just rejected by honest miners, even without DSP. No DSP needed to protect against this attack.
After even 3 seconds, transaction will be propagated to most mining pools already, and the chance to mine it by a honest miner is very close to 100%.
Non-mining nodes do not create consensus. So by “his many nodes” did you mean Bob’s own mining pool? Because this is the only way I see this attack ever succeeding.
I do not think this attack actually works. Has any penetration tester actually ever tried it on a live system? Because Peter Rizun did not.
Yes he did. His experiment was conducted on mainnet and the network itself is of course oblivious to what the actual payments was for.
Edit: and with that I’m done arguing in this thread. It just pollutes the CHIP proposal.
Only the network rejects it while it attempts to make its way into miner mempools - the TX won’t be passed on to nodes while it’s 0-conf - but as soon as it is mined and gets 1-conf then it will be accepted by everyone as part of a valid block, and all miners, honest and not honest, will continue to mine on top of that block.
Yes, honest miners will not include it in their block template, but they WILL mine on top of a block that got mined by a not-so-honest miner.
I disagree, it’s part of the process to clarify things and clear up any misunderstandings.
Indeed he did it on mainnet, but he did not buy actual snack from an actual vendor.
I think that at this point we REALLY need an actual security researcher / pentester to actually visit St Kitts and Newis, Florida, Southe america or other places and try this attack LIVE on an actual vendor.
The reason for this is that this attack will not work on a well-connected payment operator. In such a scenario, the legit transaction will just get propagated to all mining pools way faster than 5 seconds.
EDIT:
Sorry, I forgot to add that a person trying to steal a snack from vending machine will not bribe a miner to do an attack for them.
I was talking about the scenario where the fake TX sent after 5 seconds supposedly propagates to some miner faster than the legit one.
EDIT2:
I kind of mixed up the attacks. Sorry for creating a mess here guys, I had some vodka yesterday and I am still not sober.
He needs:
- rent like 1% of BCH hashpower, which costs about $7.5k/hour now - BUT, he gets the block rewards anyway so he could even be making money while he tries the attack, or at least he’d be losing much less than $7.5k.
- direct it to his pool that patched open-source node software and removed the 1st seen rule
- spin up a patched SPV server and connect his wallet to it
- scale: patch an open source wallet and give it to many people and tell them that sometimes they can get free stuff, and have the wallet take a cut of the cheats and pay into adversary’s address. DSPs won’t catch this if wallet talks only to the adversary’s nodes. Rest of the network will see it only when it gets 1-conf.
And then he can try to get free stuff as much as he wants. 1 out of 100 blocks he’d get lucky, maybe even with multiple buys in that same block. If his rented mining operation is profitable, it costs him nothing, if it’s not - it costs him whatever % of hashpower is not paid for by block reward.
Your reasoning is correct, however you completely skipped the social and law side of this.
If you keep such operation running and actually go to real ATMs and real vendors in real world, you will get found and jailed, pretty quickly, probably before you earn any significant money (1% chance is very too low to make it a solid way of earning money).
Which is why nobody ever did it on any larger scale. Which is my point.
Even without DSPs, this attack is not really profitable in real world scenario, because the risk/reward ratio is too low.
Nobody will know what you’re doing unless you’re successful. You take the thing and go out, and the merchant will think you paid. You have like 10min to get away until your TX will be (maybe) mined and merchant be like wtf where’s my money. The above scenario doesn’t trigger any DSP alarms because it uses a covert relay network.
Nah, merchant will receive big red FRAUD WARNING the moment the other transaction gets mined.
It’s trivial to find out even without DSPs. I think that BitPay and other operators already have something like this.
You try to do it 10 times, the 10-th time you walk into a shop or to an ATM, police gets called and you get jailed. It’s as simple as that.
Merchants & police will obviously set a trap for you, it’s inevitable. This is why it doesn’t work.
Okidoki.
If you rent hash power to mine a conflicting transaction that is another type of attack. Sadly ZCE doesn’t help, unless the escrow is so substantial that all honest miners will reorg the attackers block to claim the funds which doesn’t seem likely.
Again, you seem to apply ZCE to use-cases that clearly doesn’t need them and no one wants to fix something that isn’t broken with additional complexity. ZCE offers more zero-conf reliability for other forms of payments that don’t use zero-conf at all today. How about an online merchant that sells digital goods anonymously, like e-mails an MP3 file. What good would a big red fraud alert do when the file has already been sent?
1 Like
Wait a moment…
I completely agree with the above statement.
Something must have gone wrong in this discussion.
Precisely, I was not talking about ZCE specifically. I was talking about bare 0-conf even without DSP.
It is trivial to detect 0-conf fraud after the merchant has been defrauded and after merchants are defrauded few times, they will call the police and catch the suspect, which was my point.
Don’t send the file until 3 seconds after seeing the tx first and you don’t need any solution at all. Other than the double spend proof.
After that timeout the chance of full nodes (any of them) accepting an alternative transaction is zero. Miners will never even see any double spending transactions because merchant, companies and volunteer nodes are the ones protecting the first-seen rule. So miners won’t see the replacement tx and they won’t be tempted to include it, for instance if it has higher fee, like Peters scenerio.
Sigh…
So the 5.5% success rate when upping the fee by 100x on the conflicting transaction sent with a 5 second delay was bullshit?
That was during a time that 800 BU nodes were forwarding double spending transactions. So they were actually reaching the miners.
We learned this lesson the hard way, as the numbers Peter found showed.
The current network and clients have learned this lesson and are not forwarding the double spending transaction anymore. One of the main requirements of the double-spend-proof was to avoid forwarding it or allowing a miner to reconstruct it.
because due to that:
It was not bullshit.
But it was also not done in real world scenario.
As I have told you, BitPay, GoCrypto and other operators can easily detect any double spend attempt even without DSPs within 3 seconds. BitPay could do so evein in 2015, most probably (I do not know for sure because I did not ask them, but there were never any successful attempts).
DSPs just make this orders of magnitude easier and do not require having your own infrastructure. Anybody, even without his own anti-double-spend infrastructure can detect double spends with DSP.
The only way to avoid this and execute a successful attack is to have your own mining pool, but the attack will only have a random (for example 5% does not actually mean you will always succeed in 20 attempts) percentage of success equal to the percentage of hashing power owned by that pool.
Zero Confirmation Escrows on the other hand, completely turn the tables because they make 0-conf transactions as safe as a confirmed transaction.
I thought out another weakness in this scheme:
If hashpower cannot be rented anonymously (can it?), the merchants can easily detect the double spends after the fact and inform the company(or the government of the company) that rented the hashpower that mined the DS, which can then lead to legal and police action.
So again, this scheme is incredibly complicated and requires getting other people involved. People are always the weakest element in the chain.
The most probable turn of events is that the weakest chain will fail and you will end up in jail.
Can this actually succeed on big scale? I guess we won’t know unless somebody actually tries. So far, since 2015, nobody ever had.
Law enforcement only comes after a crime has been committed, and dealing with the process is a hassle nobody likes. It may deter it, but it can’t prevent it. If it’s a viable business model for a criminal organization then they’d be buying their own hardware and running their own pool. If there was a ton of places where you could try and cheat, would it attract someone who sees an opportunity and doesn’t consider the risk of getting caught? Criminals never think they’ll be caught. If they didn’t have a messed up risk/costs/benefits calculators in their head they probably wouldn’t be criminals.
Yes, we’re speculating much with these hypothetical scenarios, but problem here is we’re viewing it from now where BTC abandoned the course of p2p cash, and BCH is at what, 300-400kB blocks. 32MB is uncharted territory, and at that level we could start seeing things not thought viable now. ZCEs are a tool to be better prepared, so are DSPs, pick what works for your and your risk scenarios.
1 Like
Right, however you would expect that criminals who have enough technical knowledge to pull off something of this magnitude, would have thought about risk/reward ratios.
Honestly, this scheme is incredibly complicated and the possible rewards are very low comparing to other options.
A criminal with such brainpower should be able to devise a scheme that pays out better with lesser risk - for example name a coin after a dog meme, get stupid people to buy it and then do a rug pull or something.
1 Like
Yap. Bitcoinautist also was wrong about DSP not catching his scheme, it would. Causing his thief to get caught of lose his funds (or both).
Most important part in his scheme is that its just the miner-assisted-double-spend with extra steps.
The original miner-assisted double spend is not protected by DSP, indeed. But it is also not protected by ZCE. Additionally, it is not profitable in any reasonable manner.
I agree with everything except:
Nah, it wouldn’t.
He was talking about having a modified SPV client that actually sends 2 transactions when making a payment:
- TX A: The fake TX, broadcasted to his own pool only, his pool does not share this TX with the rest of the network
- TX B: The “legit” TX - broadcasted to everyone else
There is no way for any kind of DSP to catch this scheme, because the fake transaction is completely invisible to the network.
When you have 1% pool, there is 1 in 100 chance the fake TX A will get confirmed by the network first, while being completely invisible to the network otherwise.
EDIT:
Also, the probability of success maybe less than 1% actually, because there is still some risk of a reorg.
As I said, extremely complicated, very low profit to risk ratio. No wonder nobody did it since 2015.
1 Like