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.
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.
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:
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.
Yup. It will be invisible until the block is mined. With only DSPs, nothing anyone can do about it, they could be constructed only after seeing the 1-conf TX and it’d tell you what you already know - a double-spend transaction got mined instead of the one you have seen.
However, with ZCEs, the DSP could be used to try and take the cheater’s money even after a 1-conf - there would be incentive to reorg the 1-conf block that has offending TX-es in them and replace them with donations to miners, giving them some extra BCH on top of the block reward and both the cheater and the miner who helped him would be losing money.
(DSP+ZCE)-assisted reorg consensus?
We may be onto something here…
That assumes that the full nodes behind the pool (the one you don’t own, nor run) are somehow not going to send an INV for your stealing transaction. Why would they magically know this one should be kept secret?
How can your special SPV server even connect to them? No pool has their full nodes connectable on the general Internet. Because that would be stupid.
You’d need to start a full miner outfit to do this. Which gets me to this great joke about the guy that found a foolproof way to steal from banks which included working for them for 30 years and get a good paycheck from said bank 
This scheme is indeed convoluted, extremely complicated, risky, low profit-to-risk ratio and insanely difficult to do properly.
But still doable.
Which is @bitcoincashautist’s point.
Nobody ever did it and it is possible that nobody ever will, because there are thousands easier ways to steal crypto/goods paid with crypto from other people, which is my point.
Hi all, thanks for all the discussion.
I think this earlier comment summarizes my goal in working on ZCEs:
There’s also an existing forum topic for this conversation that I hadn’t seen before:
Could we move further discussion on whether or not BCH zero-conf is already “feature complete” there? It would be helpful to focus this forum topic more on technical discussion of ZCEs.
I’ll have to stay focused on CashTokens for several more months, but I don’t want to keep sitting on some ZCE development I’m excited about.
The original ZCE contract design used a merkle tree to enforce not double spending any input P2PKH keys, but in June I realized there’s another construction with better tradeoffs: we entirely drop the need for pre-computation (including the merkle tree), significantly simplifying transaction creation, validation, and size in the common case, at the cost of limiting the number of ZCE transaction inputs to 3 (given the current 520 byte push limit).
With this change, the common case saves 15 bytes (mostly by dropping the ZCE root hash), and creating/verifying a ZCE output no longer requires meaningful computation – it’s basically just a P2PKH output with some extra, static bytes (adding only 22 bytes to the whole transaction vs. no-ZCE transactions!). The implementation is also far easier for wallets, merchants, nodes, and the claiming miner. As a side effect of the simpler implementation, chains of ZCE-secured transactions are also immediately supported (they were hypothetically possible before, but e.g. @escrowtim’s BCHN patch didn’t yet include support).
The contract is here.
The primary downside to this change is the 3 input limit vs. practically unlimited in ZCEv1 (due to the 520-byte push limit constraining the Miner Claim code path). But in practice, I don’t think it’s an actual limitation: if wallets use CashFusion properly, they should always be able to create transactions using 1 or 2 fresh UTXOs, and most coin management and selection algorithms have been optimized to do this since 2013. To corroborate, even before the scaling issues in ~2015, average input count was 2. So if anything, this limit might actually encourage healthier use of CashFusion for UTXO consolidation in wallets.
It may be a while still before I get around to revising the ZCE CHIP (we also need to review some cases where the beta DSP specs miss transactions), but I’d love to take feedback and questions here!
Ah, I should add that we save at least 10 bytes by assuming that an attacker cannot produce a private key for any string of 33 bytes in the produced ZCE transaction, as I believe it requires ~2^128 operations (via birthday attack) to find the 256 bit collision (e.g. a 35-byte,P2SH32 locking bytecode where some 33-byte slice also happens to be the public key to a private key known by the attacker). If that’s correct, the attack requires the same amount of work as finding a private key for someone else’s address, i.e. impossible. (Assuming wallets don’t naively include e.g. an attacker-provided OP_RETURN with a public key in their ZCE transactions – the CHIP will need a few wallet guidelines around ZCE transaction creation).
I’d appreciate if anyone with more crypto expertise could verify this security assumption. We could design the contract to not rely on it, but if it’s a reasonable assumption, the savings are meaningful.
@ShadowOfHarbringer would you mind moving these posts over to that thread?
I moved the relevant section of my post there too:
I’d appreciate if we could keep this thread more focused on the technical implementation of ZCEs. That thread already has a lot of relevant discussion on whether or not zero-conf development is “feature complete”, and ZCEs are just one technical solution to the types of issues being discussed there.
Can I do it automatically somehow, or should I just copy-paste the text?
Some super admin might have a way to move, but I can’t find it. Can you just copy paste to there and delete here?
I can and I will then.
Done.
Is this proposal still under discussion/consideration?
Yes, Treeless ZCEs work today and are also a useful construction for improving finality in more complex applications (e.g. DEXs).
The next step here is all wallet development work – we need end-user wallets that are sufficiently-advanced enough to work with these types of contracts.
Once we have user-facing applications ready to use ZCEs, the rollout doesn’t need to be coordinated in a network upgrade, miners that want to maximize revenue can just patch their own software at any time. (And once tooling is ready, I’ll clean up the CHIP as a reference for implementers.)
I’m working on that wallet development in Libauth – most recent status update here, and other developers are also independently working on similar projects.
In the recent Reddit AMA it was asked how the VM Limits CHIP would impact ZCE’s, here’s Jason’s response:
[The VM Limits CHIP] makes ZCEs more practical for mobile wallets, where the existing limits made implementation a bit harder (the 3 input limit of the most efficient “treeless” scheme).
While 3 inputs seems like it should be sufficient – given most transactions use only 1 or 2 inputs – I think in practice it creates edge cases that slow down user facing product development, and there’s a chicken and egg problem in getting node implementations to deeply review the idea and implement some claiming and transaction relay code.
Though, note that BitPay had public pull requests for bitcore and BitPay wallet with a full ZCE implementation in 2021. The CHIP was paused exclusively by concerns from a few stakeholders about the 5 second period of fast ZCE relay. I plan to get back to it eventually, or others are welcome to push the proposal forward without waiting for me. It’s waiting primarily for node implementations to give users/miners an option to turn on.