CHIP 2021-08 ZCEs: Zero-Confirmation Escrows

CHIPs Standards Track
,
#105

As this has gotten some unexpected push, which I don’t really understand, here is the current state of the union.

  • ZCEs are in essence allowing a 3rd party triple spending a transaction that was double spend by the user.
  • ZCEs thus require the first-seen rule to be (partially) broken in order to ensure a “correct” double spend can take place to punish an “incorrect” attempt of double spend. Today it would block both indiscriminently.
  • Double spends today are insanely hard to do. You need specialized software, you need very good connectivity and an ideal setup with a merchant and your merchant should not listen to double spend proofs.
    Even then you’re not going to get a very good result. Most double spend attempts will fail for various reasons.

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:

  • A merchant honestly doesn’t want the escrowed money. Where would they put that? Especially since the original party has a clear claim to want it back.
    A merchant doesn’t care about all of this. They just want to get paid the money they asked for. And BCH delivers that much better than visa or btc.
  • There seems to be a theory that miners in future would turn evil and start doing replace-by-fee.
    Apart from the fact that this hasn’t happened in 15 years, neither have the assisted-double-spend services.
    Apart from that, the miners don’t actually have the ability to do that.
    This was a consious decision in the design of the double spend proof, for instance, we don’t propegate the second transaction. A double spend is ONLY seen by the peers that the user send it to and they reject it and do not forward it.
    Miners never see the higher-fee transaction, as such they can’t be tempted to implement replace-by-fee.
  • A customer may be asked to spend $50 plus lock up $50 for at most a couple of hours. But the customer may very honestly not have that money in their wallet. A huge percentage of the population lives paycheck to paycheck!
    This requirement of locking up money in order to allow people to use zero conf is completely at odds with the markets wishes.
  • Double Spend Proofs exist. Their purpose is simple and effective.
    Protect the 99.99% of the normal every day transactions. It can do that with some engineering in middleware or in all wallets. Make the ones that do funky things (using custom wallets designed to do funky things, really) stand out as a sore thumb.
    And make the transaction finality show to the end-user after some 3 to 5 seconds.
    That is possible today with the tech that is running on the network today. Why ZCEs?

Edit, adding more points. Can’t call it a state of the union and then trying to be terse :wink:

  • The concept of confiscating the person’s money has always been possible using double spend proofs. It was silent, but the graph here explains it: The Double Spend flowchart
  • The idea that seems to go around about double spend proos not being complete is misunderstanding their purpose.
    In essence people are saying that since p2sh isn’t covering them, they need fixing. I disagree.
    The basic concept of dsproofs are to make normal daily payments smoother. In normal daily payments people use p2pkh. People have wallets that in almost all cases will spend confirmed coins.
    It would make sense to go back a couple of transactions in the chain, but honestly the moment you get to a situation that seems artificial you don’t have to bother. You can just tell the customer to wait for a confirmation. Because those situations don’t actually happen in normal shopping. Normal wallets can avoid them very easily.
    So you have two states. Either a payment is not protected and this means the customer did weird stuff. Make them wait and bear the consequences of said weird stuff.
    The second state is it is eligable for double spend protection and you know that after a couple of seconds you can give the product to the customer because the transaction is settled.
  • Exchanges. Yeah, it needs attention since so many people seem to care an exceptional amount about sending coins there. Mind you, those people are selling their BitcoinCash, why would we need enabling them? Anywho…
    Catering to exchanges is equivalent to you trying to change yourself in order for that movie star to notice you. Sorry, that’s just not going to happen. The reason they are not noticing you has practically nothing to do with the technicals of BitcoinCash. Has nothing to do with anything we can actually change.
    If you want exchanges to be more friendly to Bitcoin Cash: get a wider userbase. Make products that actual normal people want to use.
#106

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.

#107

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.

#108

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.

1 Like
#109

Then I must have misunderstood something as well :sweat_smile:

#110

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.

#111

The basic mechanics is pretty much the same as awemany demonstrated with ZCF 5 years ago. ZCE is “just” a better version of it.

2 Likes
#112

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).

#113

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.

#114

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.

#115

You may have missed how this is based on a faulty assumption and thus not effectively true:

#116

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.

#117

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.

1 Like
#118

You’re missing the locality of reference here.

Any ANY single node will only EVER have one of the two transations in their mempool.

Some nodes will have one, the others will have the other.

Now, if you have the one with the ZCE, you can claim the reward if you get a dsproof.

But the scenario we’re talking about is when a miner gets the cheating transaction. Remember, he will ONLY ever see one transaction.
As such, when they receive the cheating transaction and later a dsproof, there is no trace of any ZCE here. They will not realize there is any money to claim. They will just mine the cheating transaction as in that miners mempool that is the only transaction there is.

This is a feature. Not a bug. Miners do not have access to both transactions WHICH MEANS that they are not incentivized to decide what to include.
In this case they won’t include the ZCE, even though that would be profitable for them. They won’t because they don’t have that tx.
But in the case of replace-by-fee, this is good because again the miners don’t have access to alternative transactions and thus they never learn about a transaction that is paying a higher fee.

That is how the system is designed, it works that way today. Lets not change that. There is nothing broken.

#119

Seems like this completely invalidates ZCEs, if true.

Not an “exploit” - wrong wording, but more of a critical bug.

#120

It is an assertion that went wrong.

An assertion is an assumption they started out with. The fact that miners never have the ability to pick which transaction to include means that there is actually no reason for ZCEs to exist in the first place.

The proposal logically supports the assertion here:

Long-Term Security

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 coinbase1.

This argument makes no sense the moment you realize the ones that follow the first-seen rule are the merchants and the exchanges and the companies building bch stuff. It is in their interest to have the first-seen rule.
Miners are a minority on the network, miners don’t want end-user wallets to connect to them directly. As such they will never even see the ‘other’ transaction. There is no incentive because those that want to enforce the first seen rule simply don’t give miners a choice.

The quoted paragraph is bogus. With that the ZCE proposal doesn’t solve any real problems.

#121

The only way this could happen is if the cheating tx was transmitted before or at the very same instant as the ZCE protected transaction. But any merchant would of course see this instantly, even before processing the payment since the ZCE protected tx is given to the merchant via a paymentprotocol and will thus reject the payment before the transaction is even broadcasted when trying to verify the given transaction.

I’m not fully up to speed with needed changes in mempool acceptance that was implemented in the BCHN branch mentioned above (not merged), but there could hyptothetically be changes such that the merchant can transmit the ZCE protected transaction and other nodes will prefer that instead of the cheating transaction…

(That being said, I’m not pushing for ZCEs just yet. There are some issues that I mention early in this thread that I don’t know if they are answered – don’t consider me a ZCE-fanboy at this time even though I think it’s an interesting idea worth exploring)

#122

As I suspected:

To be considered ZCE-ready , node software must implement specialized transaction relay/mining policies for ZCE-secured transactions. […] 3. If a ZCE-secured transaction is received within 5 seconds3 of a conflicting, non-ZCE-secured transaction, the ZCE-secured transaction must replace the first-seen transaction4. (Implementations must rebroadcast and/or add the replacement transaction to the candidate block.)

1 Like
#123

Oh, so ZCE breaks first-seen rule.

Interesting.

Wait a moment… Can’t this be essentially used in reverse way, to send the normal transaction as non-ZCE to the merchant/exchange and then send the double spend attempt as ZCE?

ZCE would then essentially work in the same way as RBF.

What is the countermeasure against this attack?

There is nothing wrong with being a fanboy of something that is actually great.

I was literally a fanboy of ZCE 4 hours ago, now I changed my mind because new evidence that was never seen before was presented.

I might become a ZCE opponent if the attack I devised has no countermeasures.

#124

Paraphrasing what was said in TG for posterity.

The proposed changes to node transaction relay policies states that a (non-ZCE protected) transaction can only be replaced by a ZCE protected transaction during the first 5 seconds. After that time any node will drop the replacement in the same way as they today drop a conflicting transaction with higher fees.