I’m clearly not getting thru to you.
The numbers above from Rizun says that if the ATM would wait 5 seconds before giving someone the money anyone could, without risk or cost, do a miner-bribe attack of ~300000 satoshis and succeed 5.5% of the time. Any DSP would be triggered too late!
I get this.
5.5% is not enough. Also ATM is real life. Real life is not secure, unlike properly secured Internet connection.
You would have been found and stopped using traditional means (police, jail time) maybe even before you could succeed (5.5% is a very low chance, also it is not guaranteed at all you will succeed in ~20 tries, this is random).
This is exactly why I am saying this attack is not practical. Sure - it is doable theoretically, but risks outweigh the possible profits. Not practical on larger scale - that’s for sure.
I am still waiting for the merchant who was scammed using 0-conf. I am waiting since 2015.
I am starting to think I won’t live to see it.
hey guys,
just wanted to add some facts around the actual state of the zero-conf transaction security right now as that seems to be not known widely.
First of all, sending a second transaction to double spend your own can only lead successfully to a double spend in a very small amount of time. Within 3 seconds the entire network has the first one sent, so if you wait longer your new transaction will simply get rejected by each and every peer. No effect. You basically need to do it at the exact same time as the original one that the merchant has to see.
A user that successfully sends two transactions and is already extremely lucky to make it into some miners mempools then gets into the gamble of getting the one they want mined. If that miner didn’t get the block, no luck.
This is a big gamble and most of the DS-attempts end up simply paying the merchant anyway. (which is why users trying this with DSProof in place lose their money most of the time).
DSProof protects against all those cases.
We didn’t make DSProofs any more strong than just a message to the merchant because the human factor is important. People testing, people confused and all that are relevant and various service minded companies will prefer to decide for themselves what the policy is. Anything from calling the police, confiscating the funds (in the ~80% chance of the DS failing) to simply giving a stern talking to. The currently deployed DSProof solution allows all of this.
An anonymous service or casino or vending machine are most likely just going to cancel the order and if the money arrives it will cover the administrative costs. The user that went out of their way to double spend loses it. I can’t lose any sleep over that…
There is another thing we want to do. An improvement of behavior when it comes to payment protocols. BIP 70 specifies that the customer is to send the transaction to the merchant and the merchant is then the one responsible for broadcasting it to the network. But this doesn’t happen in any current implementations.
Yet, having the merchant send the transaction to the network is super useful as it allows them to play with timing (we are talking about some 100s of milliseconds) of broadcasting the transaction.
This is super useful because the attacker has to know the timing in order to broadcast his offending transaction himself and have the right effect of his second transaction landing in the mempool of a miner. If the attacker is too fast, the merchant will instantly know as the transaction is rejected by the node he connects to (and he gets a bonus double spend proof).
If the attacker is too slow, the chance of the attack succeeding drops massively. (and still the merchant gets a double spend proof).
I learned recently that this exchange has added ds proofs ‘silently’. https://imgur.com/pKWZVLm for https://imgur.com/vk1p2w2
In short, in mainnet today:
Here is an example of what happens when a wallet checks for double spend proofs. Notice that it doesn’t really take long at all after first seeing it:
@tom is right here.
People realy need to understand that 0-conf was already pretty safe and “safe enough” for everyday spending.
With DSP, this is taken to another level, the chances for a successful attack and profitability of such attack scheme at large scales is decreased by order of magnitudes, literally.
With ZCEs, the risk of 0-conf transactions is reduced essentially to 0. Unconfirmed BCH transactions will be as good as confirmed BCH transactions.
But it cannot be so good without any downsides, right? Without caveats? Yeah - ZCEs requires an additional percentage of deposit in user’s wallet (for the self-escrow/penalty), so it is perhaps not as convenient for the user as DSPs.
The point is, BCH already has safe&secure transactions for doing groceries&small business. Now it will get safe&secure transactions good enough even for exchanges, ATMs & banks.
This HUGE. We are making history here.
That doesn’t explain the 5.5% success rate Rizun got when attempting miner bribe attacks with a 5 second delay. We can’t just ignore that piece of data.
What if the environment is not face-2-face and the payment flow is automated and anonymous? If the digital goods are released after 5 seconds there is no cost or risk and a 1/20 chance of success (at the time of Rizuns experiments) for a customer to attempt a double spend by increasing the fee 100x for the conflicting transaction. No police can easily investigate, no funds to confiscate and no customer to have a stern talking to.
As I said above ZCE is better suited for another type of use case.
Some information from the field; someone that is working in Townsville (Australia) on adoption shares his experience (reddit link);
Bitcoin Cash 0-conf is a BCH superpower! Every merchant uses it for every transaction, every day.
It is extremely hard to reliably conduct a double-spend and what nobody seems to acknowledge, it is super easy for a merchant to detect and have the shoplifter detained for attempted fraud whether it is successful or not.
Oh, and lets not forget that 0-conf is only used for small payments (global median cash spend is just $15). Anything significant can easily wait for a confirmation or six.
0-conf is perfect just the way it is. The genius of Satoshi.
to attempt a double spend by increasing the fee 100x for the conflicting transaction
In that case, I wonder if the fee won’t exceed the payment. If there is only 5% chance, and if the fee is 100 times larger, then I wonder how to correctly calculate the profitability of a gambler that would always try to cheat. How many coins are needed to break even in that case? I guess it is as unprofitable, as it is for a miner to steal coins by overwriting the chain.
Let’s assume that some evil mining pool has 5% of the hashrate, and that pool always try to double-spend by mining a block with another transaction than is broadcasted to the P2P network. Then, that case of 5% chance and 100 times higher fee from some evil user is even worse than only 5% hashrate required from the miner. And for miners, we have formulas in the whitepaper, for 5% it is quite unlikely that such evil pool will try to cheat.
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.
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:
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?
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?