CHIP 2021-08 ZCEs: Zero-Confirmation Escrows

CHIPs Standards Track
,
#125

OK, I will also copy-paste my TG post with some improvements:

It should be basically trivial to construct a wallet that sends the transaction to the merchant and the double-spend transaction to other nodes with a very specific delay. As in, the transaction to the merchant will be received by nodes in 0.5s and the ZCE double spend will be received 0.5s later.

First implement a delay in software and then just use a well-connected proxy and ping other nodes.

Or you can basically sellect well-connected and badly-connected nodes and send TX1 to well connected nodes and TX-ZCE to badly connected nodes.

Seems like the result would be almost guaranteed and the first TX would be removed.

Therefore this countermeasure seems ineffective.

#126

The counter measure for the merchant (if he doesn’t want to wait 5 seconds for a dsproof) is: Require a ZCE protected transaction.

#127

This is indeed an effective countermeasure, it makes sure ZCEs work as intended.

However, this makes things even worse: It will lead to non-ZCE transactions (zeroconf transactions) being abandoned by merchants who adopt ZCEs.

Essentially this countermeasure breaks the current Bitcoin Cash value proposition: Zero Confirmation Transactions. Then replaces it with a new value proposition: Zero Confirmation Escrows with forced self-escrow system.

Now it seems like ZCEs and normal ZeroConf (either with DSProofs or not) are mutually exclusive.

#128

Unless they would wait 5 seconds after which any zero-conf tx is handled in the same way as today.

But sure, the 5 seconds might be a concern. I don’t know how long the current merchants wait with releasing products while monitoring for DSPs and how much 5 seconds is to them.

#129

5 seconds? This is not good enough.

Even right now in Bitcoin Cash City, Australia, almost every BCH zeroconf transaction goes through under 2 seconds, no DoubleSpendProofs used. Waiting for 5 seconds is too long comparing to instant VISA transactions (yes, I know these do not even connect to the payment server, it’s irrelevant from customer’s/merchant’s point of view)

There are lots of videos on it.

#130

Another issue with ZCEs is that they are not really useful for customers/merchants in brick&mortar store. More like they would be useful for exchange transfers as an option, because crypto people are more understanding.

I will copy-pasta my posts from TG:

Because essentially you need more money than you pay in the wallet. Part of the money becomes frozen until transaction is confirmed.

I can tell you already people won’t like this / Will have problem with this.

(…)

I can tell you, that psychologically this will be a problem for VAST numbers of people, ESPECIALLY these who live from-paycheck-to-paycheck, which is most probably the majority.

(…)

I think that you can figure out yourself that if Joe Sixpack has $100 in his wallet, but cannot buy a $100 kitchen appliance, this will ba a huge problem, right?

(…)

this is super bad UX

Basically, common people are just not going to accept this type of transactions.

Joe Sixpack has $100 of value in his wallet. Why would Joe Sixpack want to sacrifice his $25 or $50 so that he can pay for something?

Because some people might cheat the merchant?

This is basically like accusing Joe of stealing/cheating before he even cheated (guilty by default).

Really, nobody is going to like this.

#131

Summing up the problems after the telegram discussion:

  • Emperical tests show that after 2 seconds most of the network has a transaction. At 3 seconds this reaches the ‘nearly all nodes’ level.
    This means that not seeing a dsproof for 2 seconds is safe. 3 is super safe.
    ZCE breaks that by breaking the first-seen rule for 5 seconds.
  • ZCE is essentially replace-by-fee in a different form. Same concepts.
  • The 5 second rule is bad.
    First reason, that’s not how mempools work today.
    But the second is due to the nature of decentralization. Time is full-node local. There is no timestamp of creating / sending a transaction. Only when you first see it. So effectively it may be 6 or 7 seconds where a node accepts and forwards the double spending zce transaction. Repeating point one, zce destroys zero conf.
  • ZCE CHIP misunderstands the basic way our network works. The entire section on “long term security" is basically wrong. The understanding of what DSProofs do is wrong.
  • ZCE does not in actual fact solve any problems that are not already solved or easy-to-solve today with currently deployed tech.
  • The market is NOT asking for this. The market isn’t even pushing for double-spend proofs because there is no perceived risk of double spends on the network.

In short, full nodes should not add code to break the first-seen rule for some specific case that is eery similar to rbf.