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.
2 Likes
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.
3 Likes
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.
1 Like
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.
2 Likes
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.
2 Likes
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 
2 Likes
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.
I actually do not think they address the exact same problem. ZCE is more suited for automated payment flows as I stated above. DSPs might work wonders if you are buying a piece of gum from a physical person. But if you are buying it from a vending machine it’s basically risk free to do a double spend attempt. Worst case is that the vending machine sees the proof and waits for a confirmation (or a refund as specified by an applicable payment protocol).
With ZCE you loose the escrow when trying to do funny business.
1 Like
Exchanges obviously not, some want 10+ blocks today. Last time I used a crypto ATM (it was in Poland/Lodz) it wanted more than one confirmation (BTC).
What makes you think that they would go for instant transactions? The amount of risk increase is not explained. No example that currently wants more than 1 confirmation (also on BTC) is a valid usecase for ZCE, because how could it be?
You are advertising based on emotions, not reality.
Please keep the tone more civil, please. Turns out your example was invalid.
A vending machine can, today, be implemented risk-free as well. All it needs to do is listen for double spend proofs and when one appears for the transaction (or a parent) it cancels the transaction. This happens FASTER than a credit-card transaction and is more secure than a card transaction (can’t be reversed).
With ZCE you loose the escrow when trying to do funny business.
And wtih DSP you lose your funds too. No difference in risk to merchants.
Additional advantage of using DSP is that the customer doesn’t have to tie up additional funds. You can actually buy that mars bar from your LAST coin with DSP.
Its a slight variation on the theme of this flowchart; The Double Spend flowchart
The variation is that you would not call the police but let the thief be the one that takes action. Exactly like with vending machines today.
Again, this is possible today on main-chain. Should people want to use it. No need to start a new CHIP or invent a new thing. It already works.
How long does it take for the machine to release the product? 10 seconds? The culprit can simply wait 10 seconds to get the product in his hands and then post his double-spend TX. Sure, there’s the “first seen” policy, but that is an externality the merchant can’t control, and there are no guarantees that it will always be widely adopted - so the point of creeping risk with our network growing still applies.
You don’t exactly lose - you still got the product you bought, and here a double-spend attempt is a free shot at trying to get your money back but keep the product. With ZCEs you’d lose an additional value on top of the money paid for the product, you’d pay double the price of product for attempting to cheat and get it for free.
I think you misunderstand.
The point is to convince them that they don’t want the confirmations.
They are not aware yet that ZECs exist and actually work. Once they gain confidence in the tech, I am sure instant deposits and withdrawals for sums less than $100.000 should be natural.
The risk is almost non-existent. This is the point. Which you missed.
This is my “civil level” right now. I am not going to tell you I love you, I am here to tell you your argument is invalid, not love you and be your boyfriend.
The point of discussion is to point out that somebody or something is wrong in order to reach the truth.
I will not discuss to be excessively polite to people. That does not make any sense.
This. With ZCE miners are incentivized to take the escrow but the product gets payed with the correct amount either way.
2 Likes