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.

1 Like
#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.

1 Like
#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.

#132

I just got around to reading this CHIP for the first time. Yeah I am with Tom on this one – not worth doing right now.

The requirements are insanely complex on the mempool, on the customer wallet, on miners, and on merchants – all at once!

By contrast, DSProofs require 0 wallet support from clients (or nearly 0). Just the merchant has to have support, really.

Aside from that, it’s not even clear to me this would actually work any better than DSProofs. It seems to try to solve 1 class of problems but introduces a whole other large class of problems in doing so.
But even if it works as claimed – the requirements are out of this world complex. Everything from the wallets to the mempool relay policy would have to be super rock solid and have 0 bugs otherwise you’re hosed. Lots of complexity there to me means: lots of opportunities for people to implement it improperly and lots of room for exploits to exist.

DSProofs seem like a great solution in that they are simple, are here today, and are available right now for merchants to use even if customers or miners don’t even “know” about their existence.

If you are really an interested merchant, you can find out with great confidence that no double-spends exist (provided your node is proparly randomizing its peers)… for a particular purchase.

I vote we maximize the emphasis that merchants start to use DSProofs … and they implement those properly.

And I vote we don’t do ZCE until and unless we find that DSProofs don’t do enough and we need to do something as elaborate as ZCE… which I think is insanely complex for what it is.

1 Like