CHIP 2021-08 ZCEs: Zero-Confirmation Escrows

CHIPs Standards Track
,
#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.

#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