Sort of, but we can also expect that any claimable-ZCE will be quickly claimed. If “naive” miners don’t run that logic themselves, someone else likely will create the claim transaction and broadcast it. (And anyone between them and a naive miner can swap the output to themselves.) I expect many miners will also ultimately run general-purpose, anyone-can-spend claiming logic (which will appreciatively pluck the double-spend info out of any transactions broadcasted by the earlier parties, claiming it without the reconnaissance work).
So we can expect that someone will grab the ZCE, even if very few miners are cognizant of their being a network-wide race.
Ah, right, thanks! I was focusing on the scenario where B is already a lower-escrow ZCE amount, and gets replaced with a B’ of a higher escrow amount. (The second case can be eliminated by disallowing spending of ZCE transaction outputs for the 5 second lock-in period.)
The non-ZCE chain replacement is definitely harder to handle without having some limit on unconfirmed transaction chains.
I would much rather we avoid any setup requirements, since they are almost guaranteed to regularly cause UX delays. Especially if the setup isn’t necessary for typical operation, but only as a sort of signaling mechanism for how honest nodes should handle broadcasting. (Also, I’m not confident this wouldn’t set us back to having all unconfirmed transactions incentivize fraud-as-a-service mining. Unconfirmed transaction chains can always be killed by a paid-off miner, and the more they’re relied upon, the more likely we are to see those miners in the wild.)
I think there are probably some reasonable solutions though. Maybe something that takes advantage of the 5 second lock-in period? (Reminder: 5 seconds is ~2x the expected time it takes for the entire network to hear a transaction, so all commercial ZCE activity can be expected to happen within this time. ZCEs which attempt to e.g. replace a transaction from 1 minute ago would never be accepted by a merchant, and are almost certainly malicious/DOS attempts.) How crazy would it be for node implementations to keep the last 5 seconds of mempool updates in some sort of pre-commit log? After 5 seconds, the “rollback instructions” can be safely thrown away.
I’ll have to think about it more. I’d love to hear from node implementation devs on this topic!
It depends on exactly on how much change is made. Your system doesn’t require a consensus rule change, though it does depend on node non-consensus/policy changes.
To prevent more than one transaction being built on an output, there needs to be covenant functionality. You need to place a restriction on the scripts of the outputs of the transaction that spends the current output.
Maybe a hard fork would be acceptable to have a flag or something. It requires that all outputs of the next transaction are unspendable until 1 block has passed.
Excited to announce that I’ve implemented Zero-Confirmation Escrows for BCHN in the following merge request:
Improvements to the ZCE Specification
While implementing this MR (and after discussing with @bitjson and @marty), it became clear that the implementation would be simpler (and more secure) with one change to the spec, which I have incorporated into the MR:
Make the ZCE locking script standard (rather than wrapping it in P2SH). That way, nodes can determine whether a transaction is ZCE-secured simply by inspecting it (without needing to wait for the subsequent escrowReclaimTx to reveal the redeem script).
This MR also features a more optimized version of the ZCE locking script (courtesy of @bitjson) that saves a few bytes of data and no longer requires the altstack.
DoS Mitigation
A special thanks to @TierNolan, who identified a potential DoS issue involving the replacement of long chains of unconfirmed transactions.
This MR addresses that issue by ensuring that a ZCE-secured transaction may only replace a double-spend (and its descendants) if doing so is economically rational (i.e. the value of the escrow on the ZCE-secured transaction exceeds the cumulative value of the miner fees on the transactions it replaces).
Any peers that repeatedly send ZCE-secured transactions without adequate escrow to warrant replacement get banned.
In my testing, I found that removing an unconfirmed chain of transactions from the mempool is ~30x faster than adding it:
* The data in the above table was collected by running the chain_of_double_spends_replaced_by_zce unit test in my MR and varying the length of the unconfirmed transaction chain.
Additionally, after setting up a local network of 3 interconnected BCHN regtest nodes, I discovered that nodes are able to propagate chained transactions over p2p at a maximum rate of ~30 tx/s. And since an attacker has only 5 seconds to build his chain of conflicting unconfirmed transactions, the maximum number of chained conflicting transactions that can be propagated network-wide in under 5 seconds is ~150, implying a worst-case replacement time of ~2.5ms per the table above.
Therefore, the low computational cost of replacement, combined with the DoS mitigation code above, should provide adequate DoS protection.
Proposed Testing and Activation Timeline
Because deploying ZCE requires a standardness change, it is critical that all participants in the BCH ecosystem (especially miners and merchants) activate ZCE standardness at the same time to ensure that non-ZCE zero-confirmation transactions remain secure. Therefore, the May 2023 upgrade would be an ideal time to activate ZCE on mainnet and would give us almost a full year to fully vet ZCE on testnet to ensure there are no unforseen issues.
Acknowledgments
Thank you to everyone who made Double-Spend Proofs a reality, especially @tom, @freetrader, @cculianu, and @im_uname. This MR would not have been possible without DSPs, which enabled ZCE to be implemented in less than 600 lines of code (excluding tests). And thank you to @bitjson and @marty who authored the ZCE CHIP and answered questions and made improvements to the spec as I was implementing this MR, as well as Awemany who pioneered the original Zero-Conf Forfeits mechanism on which ZCE is based.
Would love to get feedback on this implementation!
Q: would it be possible to make the P2SH hash constant for all contracts - by extracting variable parts into another output - entangled with the “main” contract using the new introspection opcodes. By entangled I mean: have each of the output’s redeem script require spending the other one in the same TX. Something like this: Introspection opcodes are so cool, here's a teaser : btc
So far no merchant seems to even be asking for double spent proofs, why does one feel a need to improve upon it?
The CHIP is awefully hand-wavy on this.
Small observation; a collaborating miner that mines a double spend (the only thing that DSP doesn’t protect against) is also not going to get stopped by this one. Which means that the confidence level can not honestly be advertised as better.
Easy. The most important is: Instant transfer to exchanges.
Brick and Mortar stores are good with Double Spend Proofs. Internet Stores are good enough even with 1 or 2 confirmations.
But for instant deposits and quick withdrawals from/to exchanges (and probably gambling sites too) with no added risk is/will be definitely the killer feature.
I am loving your DSPs too, Tom, they are great BTW.
Really fantastic work @escrowtim! Thank you again for all the time and energy you’ve put into making this implementation happen. (And thanks to everyone already reviewing it!)
That’s definitely a valuable technique for many covenant use cases (for others reading, this is an idea behind convenant-tracking CashTokens). I don’t think it applies in this case though. 1) There are technically 14 contract permutations (supporting up to 14 merkle tree levels). 2) In this case, a constant P2SH hash breaks expectations of users and wallet infrastructure (a constant P2SH hash could help wallets “find” a latest covenant UTXO, but for ZCEs it would be counterproductive; wallets would need to look up not only UTXOs but also their sibling outputs to confirm ownership – requiring new indexes and unnecessary logic). 3) Using sibling outputs requires additional transaction size overhead, so any benefit would need to outweigh that cost.
Marty and I spent years thinking about ways for merchants to safely accept instant transactions (both point of sale and online) because we saw this issue set back real world Bitcoin (Cash) adoption countless times while working at BitPay (merchants cooling off or dropping support after being burned by the choice between UX and fraud risk). For merchants at significant payment volumes, this is among Bitcoin Cash’s most critical pain points to solve.
Double Spend Proofs are great! In my experience, merchants and payment processors are thrilled that people are working on zero-conf security again. However, there is serious, systemic risk for large merchants accepting non-ZCE, zero-conf transactions, even with DSPs. From Long-Term Security in the spec:
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 coinbase.
As block subsidies continue to be replaced by transaction fees and zero-confirmation commerce volume increases, the expected profitability of attack infrastructure may rise significantly. Unscrupulous mining pools could augment their income by offering zero-confirmation transaction reversal services which circumvent network monitoring strategies and occasionally succeed at reversing non-ZCE transactions approximately 10 minutes later.
ZCEs remain incentive-secure against this category of attacks, even as zero-confirmation commerce volume increases. With adequate escrow values, ZCE-secured transactions can be accepted with the same finality as single-confirmation transactions.
There are other reasons I’m more excited about ZCEs than alternatives:
I hope to convince you that this is not the case. There’s a much deeper discussion in Full-Value Escrow Requirement, but in short, such “fraud-as-a-service” miners are incentivized to double-cross the attacker (attackers risk >200% of each payment for the chance at a discount). We’ve even outlined a theoretical nuclear option we believe fully eliminates any expected profitability of fraud enterprises:
If a notable “fraud-as-a-service” miner were ever detected on the network, an additional mining policy could be implemented to solidify ZCE security: miners could ignore blocks which fail to claim sufficiently-aged ZCEs beyond some limit.
Because all miners are expected to eventually hear all transactions, blocks which fail to claim a significant sum of value from ZCEs of sufficient age can be assumed to originate from a miner engaged in zero-confirmation payment fraud. (A miner forgoing significant on-chain profits indicates that they are being paid a larger sum off-chain to modify their behavior.)
To ameliorate this fraud, honest miners can profitably provide a valuable service: ignore the offending block, claiming the ZCEs themselves in the next block. If all honest miners expect this behavior (and reasonable timing and value limits are established), the network can be expected to successfully drop the offending transactions.
The other miners can expect to make a profit at the fraudsters’ expense, and any users who were defrauded will automatically receive the payment they originally expected.
I asked why you think you need to improve a product when nobody is using the current solution. You state that there still is risk.
Should I read this as you saying that the reason merchants are not using double spent proofs (but simply accepting zero-conf without it) is because the risk is still too large?
At the end of the day, I think we have a good indication of demand (for more secure zero-conf) because a pretty neat product is activated on-main-chain and nobody is haressing Roger to add it to his product. Demand is very low. This has been proven empirically.
If a company doesn’t see demand for a type of product and then spends a year building a new one solving the exact same problem, the question of the CEO is going to be identical to what I asked; “what is the business case for this”.
And I still am hoping for an answer to that.
AFAIK this assumption is false. That is the entire point of the first-seen rule, to instantly reject a double spend and not bother the network with it. Since miners don’t actually have nodes that are going to be publicly reachable by SPV wallets, miners are actually expected to never see double spend transactions. They are not the ones creating the double spent proofs either and they are expected to ignore the DSPs (as an aside).
So your ZCE transaction may be sent to the merchant and some miner may naively mine a complete different transaction spending all the same inputs. Never having even seen the ZCE tx. That he mines one and not the other is NOT proof of that miner being a “fraud as a service” miner.
Naturally, the merchant will be notificed with a double spent proof.
hehe, that is a naive way of looking at the world.
Imagine you have a company doing “something” that hurts people and that company could be bribed (or otherwise cheats on its direct customers). How long do you think that company would stay in business?
The “fraud-as-a-service” has always been a bad business, your change doesn’t add or subtract from that. If someone wanted to run this business then they would run it, reputation being more valuable than getting the biggest instant-yield. Like in any and all commercial business.
Demand is very low because of another problem: Crypto adoption as a way of making payments is extremely low.
People are only interested in crypto as an investmentdumb speulation vehicle, nobody at the moment cares about paying with it at shops.
For the moment, if you want to get somebody interested, you should talk to Bitcoin.com, GoCrypto, WooCommerce or another payment processor that uses BCH directly. these are the only entities that will be possibly interested.
People do not think rationally, people follow the herd or the alphas. Internet actually made it even worse, the following, irrational nature of the population is even more visible. Which is why nobody is interested in crypto as payment but merely a speculation vehicle - because this is not what the majority wants and what the alphas promote at the moment.
Ah, I think we’re each talking about different categories of users. You’re looking at retail merchants who are already accepting zero-confirmation payments – in many cases the point of sale software they’re using has not yet implemented DSPs, but they don’t care because they’ve never been defrauded (after all, many of them know their BCH customers on a personal level, e.g. meetup locations).
You’re right that these users aren’t urgently demanding their point of sale providers add DSP support. I expect we’ll see a very gradual rollout among these users (because it’s easy and effectively free), but again, it’s not urgent because the fraud risk isn’t bothering them anyways – after all, they were already accepting zero-conf payments without DSPs.
ZCEs make Bitcoin Cash the best form of payment for a very different category of businesses: merchants in low-trust environments (anonymous, high-volume, and/or online). Marty and I were employees at BitPay when Steam and several other large merchants dropped bitcoin from their payment options; we’re deeply familiar with the pain points experienced by large merchants and payment processors:
I should note: it was definitely never as high as 50% double-spend attempts – even adding in the much larger categories of underpayments and delayed payments, I don’t think total payment error rates ever reached 50%. But it’s revealing that Valve’s president still has such a bad impression of accepting bitcoin – Bitcoin Cash can offer a much better experience for both merchants and users, especially with ZCEs.
These issues continue today, even with BCH’s low fees: of the larger online merchants that do accept Bitcoin Cash, practically none accept zero-confirmation transactions, even when it would significantly improve user experiences. (And for good reason: without ZCEs, zero-confirmation transactions are economically unreliable, and DSPs don’t change that equation.) Because of this, BCH users often have to wait an unpredictable 10 to 60 minutes or more for their gift card, account registration, access code, or other digital good, e.g. eGifter, SlingTV, Namecheap, CyberGhost VPN, cryptocurrency exchanges, etc.
ZCEs bring together lots of past ideas (including double spend proofs) to offer a complete solution for instantly-secure transactions on Bitcoin Cash. ZCEs solve some hard economic questions that make DSPs alone insufficient for large merchants, and they also offer a truly instant payment experience for BCH users. The only requirement is that the user has some extra BCH in their wallet for a split second.
I’m having trouble applying some of your other comments to the CHIP – if there’s something we should change, would you be willing to link to the relevant sections the specification? I’ll try to respond directly too:
1:
All nodes should hear every transaction with a sufficient ZCE that is broadcasted within the replacement window – it supersedes the first-seen rule for up to ~5 seconds (see also: @escrowtim’s excellent DOS analysis work above). So yes, if the hypothetical Miner Enforcement of ZCE Security was deployed, failure to claim a sufficiently-old, valid ZCE would indeed be proof of fraudulent behavior by the miner. (If you disagree, could you help us identify where the logic in that section is wrong?)
And again, that section is not part of the technical specification – it’s listed in the “Areas for Research” to discourage would-be fraudsters. In all likelihood, we’ll never need any consensus rules; the mere threat of enforcement could be sufficient to dissuade fraudsters from investing in attack infrastructure.
Q: Did Bitcoin have replace-by-fee at the time? Was it trivial to broadcast a double-spend transaction with a higher fee and have it mined instead of the previous one?
I think keys4coins accepts But yeah, we’d want 0-conf everywhere.
Mullvad VPN also accepts 0-conf. For subscription services like that it makes complete sense since they just can cancel the subscription automatically if fraud occurred and loosing 10 minutes of a $5 / month service equates to < $0.0012 Hardly worth the effort to enforce ZCE.
I think ZCE would mostly be applicable for automated payment flows where the product is instantly delivered and non-revocable; like a physical vending-machine, BCH ATM for cash withdrawal, exchange deposits or buying digital goods.
I also think the payment protocol needs to be flexible enough to allow some voluntary ZCE flows, i.e. a merchant that sells digital monkey pictures could allow ZCE for instant delivery or a wait-for-confirmation delivery of non-ZCE and the user would have to pick what suits him/her. Of course there should be cases where the merchant can force ZCE only payments – waiting for a confirmation at a coffee machine just makes everyone unhappy.
There are a number of cases where a user has the funds for a product but can not use ZCE, for instance if he/she doesn’t have enough funds for the escrow, many coins on the same pubkey, many coins with pubkeys used on other chains or not enough cofirmed transactions. This will be a very tricky UI/UX problem to solve for the average user.
Ah, thanks. That is indeed the direct answer to my question of what is the business case.
As far as I know, none of those are today asking for DSPs either. So I’m back at the beginning, your proposed scheme (which is not free, it costs a lot of developer time) is for a market that hasn’t even asked for the current solution that does lower their business risk. They are not using it.
What is the point of providing yet another product when the current one is not seeing any users?
I know of various such solutions and practically all of them ask for more than one confirmations. (travalla, coinbee etc).
What do you base your conclusion on that they will go from 3 confirmations to zero. If they found zero conf unreliable, they’d go with 1. But most of them don’t. Cryptocurrency exchanges most definitely don’t.
You, btw, linked to several bitpay-using merchants which is in a very different category of risk management. Also relevant here is that in the EU bitpay does full KYC, so your opening statement that it is about anonymous accounts does not apply to them.
Your business case for putting in the effort is very uncovincing. Again, there is an actual solution activated on main-chain, people can use it. But they are not. The conclusion is that merchants are not actually asking for a solution like you want us to add.
What? You want to break the first seen rule? That is a definte NACK from me. (Even for a short time).
You might be interested in learning that Bitcoin Unlimited did a similar thing to combat double spends and had for some months a client on mainnet that break the first seen rule.
When we had the DSP meeting in Italy the presentation from Peter about statistics and viability of double spends he gave a very clear indication that the only way for him to get these statistics is because of a client on mainnet that had a broken first-seen rule. Otherwise the numbers would all be zero’s.
With the first seen rule in place the vast majority of the double spend attempts simply fail to reach a miner. It is the first line of defence. It avoids tempting miners from replace-by-fee, for instance. Even with the best intentions you don’t break your first line of defense. You just don’t.
You should totally get them to implement DSPs too right now, if they haven’t already.
Perhaps they don’t even know it exists, because - honestly - your marketing is kind of non-existent.
AFAIK ZCEs require “deposit” to guarantee 100% fund safety, DSPs do not require such thing which is why they should be more convenient in the Brick&Mortar and Internet Stores use cases.
But yeah, we’d want 0-conf everywhere.