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?
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.
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.
The culprit can simply wait 10 seconds to get the product in his hands and then post his double-spend TX.
If it is 10 seconds, then it is a lot of time. If the attacker is not the miner or the mining pool, then it is very hard to do that in practice. Satoshi addressed that issue long time ago (search: Bitcoin snack machine).
The network nodes only accept the first version of a transaction they receive to incorporate into the block they’re trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it’s a race to propagate to the most nodes first. If one has a slight head start, it’ll geometrically spread through the network faster and get most of the nodes.
A rough back-of-the-envelope example:
4 1 16 4 64 16 80% 20%So if a double-spend has to wait even a second, it has a huge disadvantage.
“[Statistically] very hard to do that in practice” but without cost or risk it will be achieved given enough attempts.
This was the numbers on 5 second delays with a small miner bribe a couple of years ago. I don’t know what the numbers for “10 s delay” would be, but I assume not zero.
Yes, there was BU nodes on the network with non-standard relay policies that probably isn’t there today. But deploying nodes with such software isn’t particularly expensive.
Yup, nothing stops anyone from running a rogue mining pool that has a little network of nodes that can take bribe offers. Right now there’s no incentive to have that, but as we grow there may be and nothing anyone can do to stop it - other than having a way of spending where it doesn’t pay to try and cheat.
The problem is that “rogue” in this scenario actually means “(short-term) profit maximizer”. The incentives are currently lined up for a miner to take the transaction with highest fees, but ZCE shifts those incentives so the highest profits is achieved by claiming the escrow.
Yes, but I have thoroughly analyzed this possible scenario like 6 years ago, loooooong before DSPs and ZECs even existed and concluded it is not profitable for the mining pool at sums less than $10000-$50000.
This scenario is so hard to do, so costly and so difficult to make it profitable (huge reputation hit is also a factor), that there is no wonder why miners never did it to this day.
We(the community) have been talking about such scenarios for like 10 years, but they never actually happen. Zero Confrimation transactions are generally safe, even more with Double Spend Proofs and Zero Confirmation Escrows.
In my opinion “0-conf is not safe” was always only propaganda, never reality. 0-conf can be and is safe.
I’m not talking about reorgs, this is just about enabling an interface to take in “bribe” TX-es which they’d put instead of the 1st seen one while they mine a block. If they get lucky with a block - they will make more, if not - they will still get a regular block reward later, and the guy at the vending machine will get his thing at normal price instead of 0. ViaBTC has a website where you can post a raw TX, and it must obey relay rules. What’s stopping them from dropping the requirement and accepting cheater TXes? ZCEs would make it so that it pays more to cheat the cheater 
