@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.
As this has gotten some unexpected push, which I don’t really understand, here is the current state of the union.
I don’t really understand the reason why people want to have ZCEs, there is no actual problem we have today that would be fixed by them. It sounds geeky and fun, devs love to dev, but it would be better to not actually require breaking even a little the actual rule that protects the network today.
Remember, a ZCE is an actual double spend. It tries to front-run the transaction being paid to the merchant with one that sends the money elsewhere. Likely a miner.
Which leads to the not very technical observations:
Edit, adding more points. Can’t call it a state of the union and then trying to be terse 
You must misunderstand the escrow. The merchant never holds that money, it’s just an additional output in the paying transaction that pays money to a p2sh address. The payer can (and should!) spend those money immediately, which actually only solidifies that the merchant gets the money for the goods in his output. The only other entitiy that can spend the p2sh contract is someone (i.e. a miner) that has two signatures for a pubkey used as input (i.e. a double spend) and take the money himself. Either way the merchant gets his money.
AFAIK that’s not true, if the double-spend succeeds then the merchant doesn’t get the money, but the buyer still loses the same amount of money (the escrow) as if he paid for the goods, money which the miner gets when he sweeps the escrow.
I like to think of ZCEs as userspace microPoS: you put up your own stake to secure your own TXs, a stake that can be slashed if anyone can prove you even tried to cheat, you get punished even if it did not succeed, but it still has a chance of succeeding.
Than there must have been significant updates to the mechanics of ZCE still not written in the CHIP:
If a payer attempts to invalidate a ZCE-secured transaction by double-spending any of its inputs, a miner can claim the ZCE using information available in either the double-spending transaction itself or a Double Spend Proof (DSP). To claim the ZCE, the miner must confirm the ZCE-secured transaction, ensuring the payee also receives the expected funds1.
Then I must have misunderstood something as well 
Can you elaborate on this? How precisely does this triple-spending happen?
The reason and usage is simple. Instant secure transfers to exchanges at the cost of only being able to transfer a % (like 50%-75%) to the exchange.
I agree that it is not actually usable to merchants.
The UX of having $100 in wallet while actually being able to only spend $50 or $75 at best would be terrible.
Common people are never going to like this when shopping. It’s just not happening.
The basic mechanics is pretty much the same as awemany demonstrated with ZCF 5 years ago. ZCE is “just” a better version of it.
My initial point was too terse, indeed. My point did not come accros.
The point is that ZCE doesn’t benefit the merchant in any possible setup. The escrow can be taken, but that doesn’t benefit the merchant. Yes, we could maybe fix it by sending the escrow to the merchant but that is what my point counters.
A merchant would not want the escrow. He doesn’t want money that is officially not his. As such there is no incentive to them to actually claim the ZCE.
The only thing that the merchant wants is the original payment. The escrow is irrelevant and useless to the merchant. That was the point I wanted to make initially.
The assumption there is that the miner has a choice.
The assumption is that the miner has both transactions and can pick which to mine. This is indeed in line with the faulty premise of the CHIP that it assumes there is way for miners to start doing replace by fee. And thus the scheme is based on the idea that the miner now has MORE incentive to not take the higher fee one, but the original one.
This makes sense, if the miner had both transactions. But as I explained in the long post, this is not possible and the protection we have for double spends (first seen and the dsproof) are designed such that miners don’t get to see the alternative transaction.
So, a miner that gets the ‘wrong’ transaction (that cheats the merchant) in their mempool will have no clue that there is a way to get half of that money. They will simply mine the transaction they have access to.
If there is another miner that got the first transaction that wins the block, then indeed a miner can take the funds. But at this point we have exactly the same odds and outcomes as the dsproof usecase of the same setup.
The merchant still can lose their money in the small case of the ‘wrong’ transaction being mined first. 100% identical to a double spend without ZCE (to the merchant).
The assumption that exchanges will adjust to whatever we attempt is faulty.
Ask any businessmen this, this is universal knowledge to anyone that runs a bigger company.
If you are a small startup and you want something from a big company, the number 1 metric is how many customers or business you can give them.
If you’re too small they will give you polite answers (not to burn any bridges) but they won’t do it.
If you grow big enough to send plenty of business their way, they will come to you on how to interoperate.
This is nothing new. This you can find with some deft googling. Ask any company that started as a startup.
Bottom line is, the ONLY thing that is “broken” on Bitcoin Cash that helps faster exchange acceptance is user-base being too small as is the resulting business and price and money that others can make from our coin.
You misunderstand the concept behind ZCEs.
The ZCE scheme is not about directly benefitting the merchant/exchange.
ZCEs is about disincentivizing any possible double spend attempts by making them essentially not profitable, always.
In reality, when ZCEs get implemented, the amount of double spend attempts against exchanges will be equal to ZERO.
This is the point: Not to care about what happens if DS is attempted. Instead, think how to make sure it is never attemped.
This is true, but completely besides the topic.
This is the “how to get anything produced by BCH ecosystem recognized by any big players on the market” topic. It’s entirely different discussion. It applies equally to every new BCH tech.
You may have missed how this is based on a faulty assumption and thus not effectively true:
Wait, are you directly implying that the design of ZCEs is faulty and will not work in real life scenarios?
I cannot comment on this, we need to call @bitjson here, I would like to hear his refutal.
You’re misunderstanding the scheme, the merchant always gets paid to his address, he can then go on and freely spend it as 0-conf.
The main difference from typical p2pkh payment is in: which inputs get spent to pay him?
If he sees he’s getting paid from ecrowed inputs, he can have assurances that it won’t be double-spent, because the double-spender can’t profit from it, and miner has incentive NOT to mine the theft TX.
This makes sense, if the miner had both transactions . But as I explained in the long post, this is not possible and the protection we have for double spends (first seen and the dsproof) are designed such that miners don’t get to see the alternative transaction.
How does the alternative transaction get mined if no miner ever sees it? Whomever is trying to double-spend needs to show the offending TX to at least 1 miner. That one miner will see it. And he will have the original one, too, from the mempool. And now the miner can sweep the escrow, rather than help the offender do a double spend.
If attempt is done through public mempool, then everyone will have original TX + DSP, and I think those 2 would be sufficient for anyone to sweep the escrow.