That’s definitely a valuable technique for many covenant use cases (for others reading, this is an idea behind convenant-tracking CashTokens). I don’t think it applies in this case though. 1) There are technically 14 contract permutations (supporting up to 14 merkle tree levels). 2) In this case, a constant P2SH hash breaks expectations of users and wallet infrastructure (a constant P2SH hash could help wallets “find” a latest covenant UTXO, but for ZCEs it would be counterproductive; wallets would need to look up not only UTXOs but also their sibling outputs to confirm ownership – requiring new indexes and unnecessary logic). 3) Using sibling outputs requires additional transaction size overhead, so any benefit would need to outweigh that cost.
Thanks for reviewing the idea!
Marty and I spent years thinking about ways for merchants to safely accept instant transactions (both point of sale and online) because we saw this issue set back real world Bitcoin (Cash) adoption countless times while working at BitPay (merchants cooling off or dropping support after being burned by the choice between UX and fraud risk). For merchants at significant payment volumes, this is among Bitcoin Cash’s most critical pain points to solve.
Double Spend Proofs are great! In my experience, merchants and payment processors are thrilled that people are working on zero-conf security again. However, there is serious, systemic risk for large merchants accepting non-ZCE, zero-conf transactions, even with DSPs. From Long-Term Security in the spec:
The presently-low risk of accepting zero-confirmation transactions is predicated on a common but unenforceable norm: the “first-seen” transaction mining policy. Because miners who do not follow this policy cannot be conclusively identified and punished by other network actors – and BCH is not the only SHA256-based chain on which miners can operate – the current behavior can only be considered stable while the “defraudable” volume of zero-confirmation commerce is less than the expected value of each block coinbase.
As block subsidies continue to be replaced by transaction fees and zero-confirmation commerce volume increases, the expected profitability of attack infrastructure may rise significantly. Unscrupulous mining pools could augment their income by offering zero-confirmation transaction reversal services which circumvent network monitoring strategies and occasionally succeed at reversing non-ZCE transactions approximately 10 minutes later.
ZCEs remain incentive-secure against this category of attacks, even as zero-confirmation commerce volume increases. With adequate escrow values, ZCE-secured transactions can be accepted with the same finality as single-confirmation transactions.
There are other reasons I’m more excited about ZCEs than alternatives:
- ZCEs can be faster than any payment systems in use today because they don’t require a slow round-trip communication with a centralized payment system,
- BCH becomes more valuable as an instantanous collateral for ZCEs (even if e.g. users are paying in tokens rather than BCH units), and
- ZCEs are far better for user privacy/freedom than the status quo.
I hope to convince you that this is not the case. There’s a much deeper discussion in Full-Value Escrow Requirement, but in short, such “fraud-as-a-service” miners are incentivized to double-cross the attacker (attackers risk >200% of each payment for the chance at a discount). We’ve even outlined a theoretical nuclear option we believe fully eliminates any expected profitability of fraud enterprises:
If a notable “fraud-as-a-service” miner were ever detected on the network, an additional mining policy could be implemented to solidify ZCE security: miners could ignore blocks which fail to claim sufficiently-aged ZCEs beyond some limit.
Because all miners are expected to eventually hear all transactions, blocks which fail to claim a significant sum of value from ZCEs of sufficient age can be assumed to originate from a miner engaged in zero-confirmation payment fraud. (A miner forgoing significant on-chain profits indicates that they are being paid a larger sum off-chain to modify their behavior.)
To ameliorate this fraud, honest miners can profitably provide a valuable service: ignore the offending block, claiming the ZCEs themselves in the next block. If all honest miners expect this behavior (and reasonable timing and value limits are established), the network can be expected to successfully drop the offending transactions.
The other miners can expect to make a profit at the fraudsters’ expense, and any users who were defrauded will automatically receive the payment they originally expected.
I asked why you think you need to improve a product when nobody is using the current solution. You state that there still is risk.
Should I read this as you saying that the reason merchants are not using double spent proofs (but simply accepting zero-conf without it) is because the risk is still too large?
At the end of the day, I think we have a good indication of demand (for more secure zero-conf) because a pretty neat product is activated on-main-chain and nobody is haressing Roger to add it to his product. Demand is very low. This has been proven empirically.
If a company doesn’t see demand for a type of product and then spends a year building a new one solving the exact same problem, the question of the CEO is going to be identical to what I asked; “what is the business case for this”.
And I still am hoping for an answer to that.
AFAIK this assumption is false. That is the entire point of the first-seen rule, to instantly reject a double spend and not bother the network with it. Since miners don’t actually have nodes that are going to be publicly reachable by SPV wallets, miners are actually expected to never see double spend transactions. They are not the ones creating the double spent proofs either and they are expected to ignore the DSPs (as an aside).
So your ZCE transaction may be sent to the merchant and some miner may naively mine a complete different transaction spending all the same inputs. Never having even seen the ZCE tx. That he mines one and not the other is NOT proof of that miner being a “fraud as a service” miner.
Naturally, the merchant will be notificed with a double spent proof.
hehe, that is a naive way of looking at the world.
Imagine you have a company doing “something” that hurts people and that company could be bribed (or otherwise cheats on its direct customers). How long do you think that company would stay in business?
The “fraud-as-a-service” has always been a bad business, your change doesn’t add or subtract from that. If someone wanted to run this business then they would run it, reputation being more valuable than getting the biggest instant-yield. Like in any and all commercial business.
Demand is very low because of another problem: Crypto adoption as a way of making payments is extremely low.
People are only interested in crypto as an investmentdumb speulation vehicle, nobody at the moment cares about paying with it at shops.
For the moment, if you want to get somebody interested, you should talk to Bitcoin.com, GoCrypto, WooCommerce or another payment processor that uses BCH directly. these are the only entities that will be possibly interested.
People do not think rationally, people follow the herd or the alphas. Internet actually made it even worse, the following, irrational nature of the population is even more visible. Which is why nobody is interested in crypto as payment but merely a speculation vehicle - because this is not what the majority wants and what the alphas promote at the moment.
Ah, I think we’re each talking about different categories of users. You’re looking at retail merchants who are already accepting zero-confirmation payments – in many cases the point of sale software they’re using has not yet implemented DSPs, but they don’t care because they’ve never been defrauded (after all, many of them know their BCH customers on a personal level, e.g. meetup locations).
You’re right that these users aren’t urgently demanding their point of sale providers add DSP support. I expect we’ll see a very gradual rollout among these users (because it’s easy and effectively free), but again, it’s not urgent because the fraud risk isn’t bothering them anyways – after all, they were already accepting zero-conf payments without DSPs. 
ZCEs make Bitcoin Cash the best form of payment for a very different category of businesses: merchants in low-trust environments (anonymous, high-volume, and/or online). Marty and I were employees at BitPay when Steam and several other large merchants dropped bitcoin from their payment options; we’re deeply familiar with the pain points experienced by large merchants and payment processors:
I should note: it was definitely never as high as 50% double-spend attempts – even adding in the much larger categories of underpayments and delayed payments, I don’t think total payment error rates ever reached 50%. But it’s revealing that Valve’s president still has such a bad impression of accepting bitcoin – Bitcoin Cash can offer a much better experience for both merchants and users, especially with ZCEs.
These issues continue today, even with BCH’s low fees: of the larger online merchants that do accept Bitcoin Cash, practically none accept zero-confirmation transactions, even when it would significantly improve user experiences. (And for good reason: without ZCEs, zero-confirmation transactions are economically unreliable, and DSPs don’t change that equation.) Because of this, BCH users often have to wait an unpredictable 10 to 60 minutes or more for their gift card, account registration, access code, or other digital good, e.g. eGifter, SlingTV, Namecheap, CyberGhost VPN, cryptocurrency exchanges, etc.
ZCEs bring together lots of past ideas (including double spend proofs) to offer a complete solution for instantly-secure transactions on Bitcoin Cash. ZCEs solve some hard economic questions that make DSPs alone insufficient for large merchants, and they also offer a truly instant payment experience for BCH users. The only requirement is that the user has some extra BCH in their wallet for a split second.
I’m having trouble applying some of your other comments to the CHIP – if there’s something we should change, would you be willing to link to the relevant sections the specification? I’ll try to respond directly too:
1:
All nodes should hear every transaction with a sufficient ZCE that is broadcasted within the replacement window – it supersedes the first-seen rule for up to ~5 seconds (see also: @escrowtim’s excellent DOS analysis work above). So yes, if the hypothetical Miner Enforcement of ZCE Security was deployed, failure to claim a sufficiently-old, valid ZCE would indeed be proof of fraudulent behavior by the miner. (If you disagree, could you help us identify where the logic in that section is wrong?)
And again, that section is not part of the technical specification – it’s listed in the “Areas for Research” to discourage would-be fraudsters. In all likelihood, we’ll never need any consensus rules; the mere threat of enforcement could be sufficient to dissuade fraudsters from investing in attack infrastructure.
2:
Is this feedback on the discussion in Benefits: Long-Term Security or Full-Value Escrow Requirement? Would you prefer we change some terminology, or is there a particular section we should clarify?
Q: Did Bitcoin have replace-by-fee at the time? Was it trivial to broadcast a double-spend transaction with a higher fee and have it mined instead of the previous one?
I think keys4coins accepts 
But yeah, we’d want 0-conf everywhere.
Mullvad VPN also accepts 0-conf. For subscription services like that it makes complete sense since they just can cancel the subscription automatically if fraud occurred and loosing 10 minutes of a $5 / month service equates to < $0.0012 Hardly worth the effort to enforce ZCE.
I think ZCE would mostly be applicable for automated payment flows where the product is instantly delivered and non-revocable; like a physical vending-machine, BCH ATM for cash withdrawal, exchange deposits or buying digital goods.
I also think the payment protocol needs to be flexible enough to allow some voluntary ZCE flows, i.e. a merchant that sells digital monkey pictures could allow ZCE for instant delivery or a wait-for-confirmation delivery of non-ZCE and the user would have to pick what suits him/her. Of course there should be cases where the merchant can force ZCE only payments – waiting for a confirmation at a coffee machine just makes everyone unhappy.
There are a number of cases where a user has the funds for a product but can not use ZCE, for instance if he/she doesn’t have enough funds for the escrow, many coins on the same pubkey, many coins with pubkeys used on other chains or not enough cofirmed transactions. This will be a very tricky UI/UX problem to solve for the average user.
Ah, thanks. That is indeed the direct answer to my question of what is the business case.
As far as I know, none of those are today asking for DSPs either. So I’m back at the beginning, your proposed scheme (which is not free, it costs a lot of developer time) is for a market that hasn’t even asked for the current solution that does lower their business risk. They are not using it.
What is the point of providing yet another product when the current one is not seeing any users?
I know of various such solutions and practically all of them ask for more than one confirmations. (travalla, coinbee etc).
What do you base your conclusion on that they will go from 3 confirmations to zero. If they found zero conf unreliable, they’d go with 1. But most of them don’t. Cryptocurrency exchanges most definitely don’t.
You, btw, linked to several bitpay-using merchants which is in a very different category of risk management. Also relevant here is that in the EU bitpay does full KYC, so your opening statement that it is about anonymous accounts does not apply to them.
Your business case for putting in the effort is very uncovincing. Again, there is an actual solution activated on main-chain, people can use it. But they are not. The conclusion is that merchants are not actually asking for a solution like you want us to add.
What? You want to break the first seen rule? That is a definte NACK from me. (Even for a short time).
You might be interested in learning that Bitcoin Unlimited did a similar thing to combat double spends and had for some months a client on mainnet that break the first seen rule.
When we had the DSP meeting in Italy the presentation from Peter about statistics and viability of double spends he gave a very clear indication that the only way for him to get these statistics is because of a client on mainnet that had a broken first-seen rule. Otherwise the numbers would all be zero’s.
With the first seen rule in place the vast majority of the double spend attempts simply fail to reach a miner. It is the first line of defence. It avoids tempting miners from replace-by-fee, for instance. Even with the best intentions you don’t break your first line of defense. You just don’t.
Sorry for a slight offtopic guys, but I think this is important:
BTW, @tom
Apparently BitPay is already getting ZCEs implemented in their software.
You should totally get them to implement DSPs too right now, if they haven’t already.
Perhaps they don’t even know it exists, because - honestly - your marketing is kind of non-existent.
AFAIK ZCEs require “deposit” to guarantee 100% fund safety, DSPs do not require such thing which is why they should be more convenient in the Brick&Mortar and Internet Stores use cases.
I’m a technical person, I don’t do advertisements or politics or pushes like you are talking about. It would make me a worse technical person if I started doing politics.
If people care about zero-conf security, I hope they can pick up the slack and convince the wallet makers to implement support for double spent proofs. I have not met a single person here that disagrees with the benefits of DSPs. It probably gives a lot better return on investment to push for DSP support than to invent some new thing that nobody was asking for.
1:
Exactly 
2:
This is definitely true for merchants with strong enough internal interest in Bitcoin Cash, but (as I was surprised to learn at BitPay) many merchants don’t have simple or real-time methods of cancelling orders in cases of fraud. Fraud often sets off expensive, manual processes, like a support system ticket or phone call, and it can even negatively impact important externally-shared metrics (e.g. metrics shared by public companies or metrics impacting performance evaluations of a company subdivision).
Most merchants do not care enough about the experience of one particular payment method (like BCH) to expend significant resources and take on the additional technical risk of automating order cancellations. After all, cancelling a user’s order is a terrible user experience – merchants want to recover users after payment errors, not punish them. Instead, we can see that most merchants are choosing the conservative option – wait for one or more confirmations, and tell the customer that it’s the fault of their payment method. (And honestly, they’re right. BCH does not yet offer secure, instant payments.)
Even more surprisingly, this is often true even for companies that ship physical products – if you don’t get an order confirmation email until ~10 minutes later, it’s probably waiting for the payment infrastructure to mark the order as paid. And even for companies that separate the confirmation email from internal fulfillment processes, they’re still only going to start packing your box an hour later. In a world of same-day delivery, that still makes for a worse user experience.
ZCEs are useful in these cases because they are far easier for most merchants to implement – they happen at the same layer as the payment itself, and they can be implemented directly into whatever library/API the merchant is using anyways. For the merchant, they require effectively zero additional effort, they don’t risk generating new support tickets or negatively impacting payment failure metrics, and they don’t require any new business processes.
(Thanks for bringing this up!! I should probably try to get this rationale into the CHIP somewhere.)
3:
Great point, thank you! We should definitely include a way for merchants to indicate whether or not ZCE is required. Opened issue 18. 
Thanks!
4:
To clarify, DSP uptake among existing merchants is completely unrelated to demand for ZCEs. If a merchant is already accepting zero-confirmation transactions, they are – by definition – already unfazed by double-spend risk. Why would we expect urgency for them to adopt DSPs?
You’re looking at the seen – zero-conf accepting merchants – not the unseen: merchants who don’t accept zero-conf and merchants who have dropped BCH altogether. Please see above for multiple examples of both. In my view, this is clearly one of the biggest issues faced by BCH adoption; is there another form of evidence you would find more convincing?
5:
This is a good point – ZCEs only improve the security of zero-confirmation to be equal to 1 confirmation. I’m sure many merchants that currently require more than 1 confirmation will not adopt ZCEs initially. The implication is that these merchants are concerned about the relatively low reward/cost of mining a BCH block (right now, only ~$1300 USD), allowing a fraudster to temporarily rent mining power with a non-negligible chance of success.
In some cases, ZCEs will actually mitigate this risk sufficiently: they force fraudsters to work alone (or risk 200% loss for a small chance at whatever discount they’re able to negotiate with a fraud-assisting miner). I’d bet many merchants will find that sufficient to move from e.g. 3 confirmations to zero-confirmations. But yes, for merchants waiting 6 or 10 confirmations currently, ZCEs don’t really change the equation – faster finality for them will require BCH to have a higher percentage of global hash power (i.e. time and adoption). (Of note: Areas for Research: Miner Enforcement of ZCE Security would also improve finality beyond 1 confirmation.)
6:
Yes, there are certainly other business reasons to collect customer information; for many businesses it’s a combination of factors (mentioned in Improved Privacy). But there are still examples from which we can learn: why are there ATM operators requiring palm/vein/fingerprint/ID scans in jurisdictions with no legal requirements to identify the customer? I’ve asked, and their answer was 1) the machine already supports it (for KYC in some jurisdictions), 2) it gives them something to hand the police if there’s a double spend, and 3) scanning your palm/finger is faster than typing an email address in the on-screen keyboard, and the company wants to track your activity and send you emails.
ZCEs aren’t a privacy magic bullet, but they at least make it possible for these companies to offer improved privacy to customers, e.g. let customers refuse the email or manually type a single-use email address.
7:
We are aware – the CHIP actually references that research. Again, ZCEs have no impact on existing users of zero-confirmation transactions. See Modification to Transaction Acceptance/Relay and Transaction Replacement Period. (If you think we’re wrong or we’ve missed something, we’d deeply appreciate your feedback on specific errors in the CHIP.)
8:
BitPay knows. They haven’t advertised whether or not their monitoring infrastructure takes DSPs into account, but I also doubt it moves the needle for them. Larger entities that have been accepting zero-confirmation transactions for years (and especially on other chains without DSPs) already have significant, well-connected network monitoring infrastructure. (In a sense, they’ve been constructing their own DSPs internally for years.) DSPs are really more valuable for smaller/new operations because they reduce costs – you can get similar monitoring without having to run all that infrastructure. (See also: Reduced Infrastructure Costs.)
Again DSPs are fantastic – they’re critical for ZCEs to work, but DSPs themselves don’t impact zero-confirmation risk; they only reduce network monitoring infrastructure costs. It would be quite surprising if many merchants were rushing to adopt DSPs.
You don’t need to.
A simple email or PM like “Hey, BitPay CEO, I see you are already implementing Zero Confirmation Escrows, there is another tech called DSP that has a very similar target but may be more convenient for your customers to use. BTW, If you don’t know me I have been a well known & respected Bitcoin Developer for 8 years now”.
Have you tried this already?
I’m not so sure that this is true. New risks and unknowns are introduced.
You know, the invention of fire and wheel also introduced new risks and unknowns. Yet we all use fire and wheel today.
Every new revolutionary tech introduces new risks, there is no way around it. And ZECs certainly are revolutionary.
As long as the tech itself is solid, we will manage.
If it is, then why is it not possible to point to a business case where it is actually needed. If you scroll up you can see me asking various times about the business case and not getting a straight answer.
All of the examples given so far are perfectly possible on mainchain today. The infrastructure is completely done, likely some merchant tools are actually already doing it.
I agree its a really neat trick, to use script to somehow change incentives. Its bad for UX wrt to the balance issue, but neat indeed.
Don’t know if its revolutionary as the trick was first demonstrated in 2018 (by awemany), but the real point is that it doesn’t open up new usecases, it doesn’t allow things to be done we could not do before. All the given usecases can be done on mainchain today.
@tom I would love to be able to convince you that BCH would benefit from instant, incentive-secure payments.
I’ve tried three approaches (first, second, third), but I’d prefer to avoid crowding this thread with too much of one discussion. If you still feel strongly that zero-confirmation escrows have no use case, would you please start a separate forum topic for that?
Sorry I missed this question earlier – yes, opt-in Replace By Fee (RBF) existed, but it was trivial to identify and downgrade RBF transactions to require confirmation. I don’t recall hearing about any zero-confirmation accepting payment processors or merchants having trouble with that.
Ultimately, much of the real pain experienced by businesses came from delayed payments (due to the block size constraint) and otherwise honest users manually sending slightly incorrect amounts (sometimes due to wallet error). Zero-confirmation payment fraud has occurred, but as far as I know, it’s never been widespread or consistent. (Though when it occurs, it’s likely surprising and frustrating enough that it leaves an outsized impression vs. the primary pain points – that might explain interviews like the above.)
Anyways, beyond a few isolated examples, I think the greatest impact of zero-conf fraud has been the freezing effect from business uncertainty (mentioned here) – non-ZCE payments appear to work fine at smaller volumes, but past a network-wide tipping point, they could fail spectacularly at great loss to merchants. Merchants know this, and it makes them wary – it means they need to actively monitor for bursts of fraud, they need fast ways for operations teams to turn off or slow down finalization of BCH payments, and even then, they may be financially overexposed at any particular moment in time.
As a result, merchants need to either be extremely internally-motivated to create and maintain a good BCH payment experience or – as in the examples above – simply choose not to accept zero-confirmation payments.
This is the strongest argument for pushing for ZCEs IMO. Under this assumption the risk would grow with success of the network.
Btw, I was entertaining the thought of something more radical, have a look here 
What we were discussing is a different topic, you are moving the goalpost with this message.
The discussion was about your CHIP proposing a second way to make instant transactions secure, while we already have one which is active and operational. My question has always been about the business case. Why do you want the ecosystem to invest resources into this while there is a fully functional solution available that addresses the same problem. The business question is relevant because we have actual empircal data showing that the merchants don’t have a need to decrease zero-conf risk.
To put it in simple terms; you are asking everyone to put a lot of effort into a new virus killer for Linux, while all previous virus killers for Linux failed to get a userbase due to lack of interest.
It is not my job to push back, it is yours to convince the community that this is actually something they need to put time in.
Which reads:
For many businesses, assessing the risk of payment fraud against zero-confirmation BCH transactions is non-trivial.
This is mostly due to the point-of-sale software not incorporating double spend proofs. The rest is available, the support in the full nodes, the support in servers like Fulcrum. A point-of-sale software (should it be available open source) is not hard to adjust and this problem goes away.
Notice that incorporation of ZCE likewise needs adjustment of that exact same software. You may argue it is somehow a different workload, but as we are for both jobs talking about less than a week of work I have to ask why you are not advocating using of what is available on mainchain today. If for no other reason than speeding up the security of zero-conf.
In a previous post I probably was not clear, so I’ll say it plain.
Your “long term security” concern is based on a misunderstanding of how the p2p network operates and who secures the first seen rule. The result is that your point is not applicable to Bitcoin Cash and that section and that reason should be removed from the CHIP.
The first-seen rule is secured by the nodes on the edge, the ones that the SPV wallets actually talk to. Miners hide their nodes behind firewalls (because duh) and they are never going to even see double spend transactions. Should a miner implement replace-by-fee, it would have no effect.
First-seen is secured by the companies that depend on it working, not the miners.
Can you please update the CHIP to reflect those two points?
- Provide a business case explaining from the current state of mainnet which has zero-conf security.
- update (and likely remove) the long term security chapter.
I already found 2 which you conveniently skipped: Exchanges and Casinos (EDIT: Also crypto ATMs for instant Cash<->BCH transfers).
But I am sure there are more.
Try another argument please, this one is invalid.