Join 60,917 users and earn money for participation

A Simple, Elegant Way to Solve Instant Transactions on BCH

19 290 exc boost
Avatar for Jessquit
Written by   116
1 month ago

What if I told you that there was a way to have extremely reliable "zero-conf" near-instant transactions on BCH? What if I told you that the software changes required to achieve this feat were straightforward and wouldn't even require a hard fork upgrade? You'd be interested, right?


So it turns out that there are three forms of double-spending attacks possible on Bitcoin Cash:

  • fast respend

  • reverse respend

  • miner bribe

Fast Respend: This is what most people think of when they think of a double-spend attempt. The fraudster has a special wallet that broadcasts one transaction that the merchant sees and accepts as valid. Immediately after sending that transaction, the fraudster sends another transaction that sends the same coins back to himself. By optimizing the way the transactions are broadcast, the fraudster can sometimes get his coins back, and the merchant is unaware until the next block is mined containing the fraud transaction.

Reverse Respend: This is a form of attack in which the fraudster sends a very low fee fraud transaction prior to making the "valid" transaction. If the fee is low enough, the transaction will not propagate, and the merchant will not see it, but a miner will. Thus the merchant will accept the later, "valid" transaction which will be propagated to the rest of the network. If the miner who received the first transaction finds the next block, and if they operate under the standard "first seen" rule, then they will mine the fraud transaction.

Miner Bribe (aka illicit RBF): This final form of attack requires a complicit miner. In this attack, the fraudster pays the merchant using a "valid" transaction, then broadcasts another transaction that sends the coins back to himself, but paying a significantly higher fee than the first transaction, thus "bribing" the complicit miner to mine the higher-fee transaction instead of the legitimate transaction.

Good News / Bad News

The good news is that we already have a good solution to the "fast respend" fraud attempt in the form of double-spend proofs. These work roughly as follows: if a node sees two conflicting versions of the same transaction, it creates a cryptographic proof of the existence of the conflict, and broadcasts this proof to other nodes. This doesn't prevent the "fraud" transaction from confirming, but it does alert the merchant that the attempt has taken place. Since this form of attack requires the conflicting transaction to be broadcast practically simultaneously with the "legitimate" transaction, the merchant should see the fraud proof within a few seconds of the attempt, and be able to prevent the fraud from succeeding.

The bad news is that the other forms of double-spend attempts remain mostly unsolved. The reverse-respend attempt has been mitigated somewhat by working with miners and node operators to have a consistent minfee / relay acceptance policy, but this requires a lot of coordination among miners and is a partial solution at best.

The "miner bribe" attack remains completely unsolved. It is the goal of "pre-consensus" engineering projects like Avalanche to solve this remaining form of double-spend attempts -- but Avalanche is a very complex engineering problem to solve, and is highly controversial.

Arriving at a Solution

When trying to creatively solve a problem, a very common framework is to "break a rule" -- to challenge existing norms and fundamental assumptions to see if, by breaking an assumption, the "problem" suddenly goes away.

And that's when it hit me. It turns out that half of the problem with zero-conf results from an old assumption - a "loose end" left by Satoshi. If we could unmake this assumption, we could fix zero-conf for almost all usecases.

By unmaking this assumption, we arrive at a solution to the "reverse-respend" and "miner bribe" problems that is elegant, simple, and foolproof. The solution is bone-headed simple to deploy - and it wouldn't even require a hard fork. This solution would eliminate - not mitigate - these forms of double-spend attempts.

The result would be that any transaction broadcast and seen by the network could be assumed to always propagate, to always eventually confirm, and to never be replaced by another transaction. Combined with double-spend proofs to handle the edge case of conflicting transactions broadcast simultaneously, this solution would allow us to realize the original goals of Bitcoin as a fire and forget system where users could safely broadcast transactions and trust that they would be confirmed.

Before I tell you the solution, I'm going to warn you: you might not like this solution at first. It might offend certain preconceptions about how Bitcoin "should" work. I implore you to try to have an open mind to this solution, before you reject it out of hand. First I'll give you the simple version of the solution, and then we can discuss pros and cons, and some ways it might be tweaked.

The Solution

And the solution is: a consensus-level transaction fee.

In its simplest form, this would be a fee requirement (ostensibly "satoshis per byte") set as a consensus rule. If any transaction fails to pay sufficient fee, it's invalid. If any transaction overpays the fee, it's invalid. All transactions pay the same fee per byte. All of them. No more, no less. If a miner takes a "bribe fee" or accepts an "underfee," then their block is rejected by the network.

Already I can feel your objections to this proposal! Wait just a couple more paragraphs before rejecting it. Stop to consider what this change would buy us:

  • Reverse respend and miner bribes are eliminated as a way to defraud. Combined with double-spend proofs, this closes the door on zero-conf fraud. Unconfirmed transactions would become practically bulletproof. Propagation issues due to policy conflicts likewise vanish.

  • Incredibly simple implementation. Compared to super-complex "preconsensus" plans like Avalanche or subchains, this would be a change that could be implemented in a minimal number of lines of code.

  • Soft-fork change. This change would be a soft-fork to the network, and would therefore be able to be implemented with lower risk of network disruption.

  • Eliminates malformed fee overpayments. This is a tiny benefit that is still worth mentioning. Every so often we hear of a transaction confirming that paid a gigantic fee because something in the sending wallet broke or someone was hand-crafting a txn and screwed up. None of these transactions would be valid under a consensus fee approach.

  • Eliminates low-fee stuck payments. A similar problem sometimes happens with custom wallets where the user includes an insufficient fee and the transaction hangs in limbo for weeks. Such a transaction would always be invalid and would never be accepted by the network.

  • Removes the incentive for miners to choke capacity. If there is a consensus fee rule, then there is no incentive for miners to artificially limit capacity to try to juke up fees. By setting a consensus fee rule we make it clear to miners that the only way to increase their marginal revenue is to accept more transactions.

Here's how the network would feel under a consensus-fee regime:

Alice sends Bob some BCH. Maybe Bob is a brick-and-mortar merchant, or maybe he sells digital assets for immediate download.

When Bob sees the transaction, he checks to make sure it's paying the consensus fee. Assuming it is, he rebroadcasts it to ensure that many network nodes see and propagate it; then he waits a few seconds to see if a double-spend proof arrives. Once Bob is reasonably confident that Alice didn't broadcast an alternate transaction, Bob can safely let Alice have the merchandise or let her download the digital asset. The double-spend proofs give Bob confidence that "honest nodes" haven't seen another version of the transaction, and he knows that Alice cannot trick or bribe miners into mining a higher-paying (or lower-paying) version of the transaction.

This is "zero conf" the way we always wanted it to work. No messy "preconsensus" needed.

Exchanges Excluded

The one place a consensus fee wouldn't help is exchanges. A consensus fee wouldn't change the confirmation requirement for exchanges, because while the consensus fee does prevent miners from being bribed or tricked by low-fee txns, it doesn't prevent a dishonest miner from sending his coins to an exchange and then spending them back to himself by mining a replacement transaction that also pays the consensus fee.

Since miners can still perform transaction replacement of their own transactions (or those of accomplices), the consensus fee probably doesn't allow instant purchases of high-value goods like gold, homes, bags of cash, or luxury cars; however, it's unclear that there exists any requirement for "instant" sales of Lambos. If you're buying a car, or a home, or a truckful of gold bars, the process is already sufficiently lengthy to allow for confirmations.

Problems with a Consensus Fee

The following is an incomplete list of some of the issues with this approach.

  • Begins to break down under "always full blocks" assumptions. If blocks are always full, with a large backlog, it's possible that unconfirmed transactions could get dropped. A consensus fee can't solve the problem of a dropped transaction. Obviously, one of BCH's engineering goals is to never run into the situation of always-full-blocks with transactions that drop from the mempool -- and it's arguable that all blockchains "fail" in this condition -- they just "fail differently."

  • May exclude very low-value microtransactions or non-financial uses of the blockchain. Depending on your point of view, this may be a bug, or it may be a feature (I lean towards "feature"). If the community feels this is sufficiently problematic, it could possibly be solved by creating a "tiered" fee structure in which a certain amount of block space is allocated for low-value txns that meet certain criteria (ie. "Non Financial Transaction" flag).

  • Could result in a future split over fee levels. If BCH is wildly successful, it's possible that some users may feel strongly that fees should be lower, or higher, or that there should be more or fewer fee tiers. Maintaining consensus over "the fair fee" isn't problematic when the coin is undervalued and the chain is underutilized, but could become contentious under conditions of success. I file this under "risks worth taking" aka "good problems to have" since it's a problem that would only manifest under extremely good outcomes for BCH.

  • Will require changes to all wallets and node software. This is the biggest technical impediment in my view. While the changes are simple to make (make sure the app pays the right fee), they will have to be made to all applications that use the BCH blockchain, else those apps may allow the creation of invalid (pays too much / too little) transactions.

When you consider the benefits -- that is, effectively "solving" the double-spending problem in an absurdly simple manner -- without resorting to complicated, esoteric, and controversial solutions like subchains or Avalanche -- I think the problems are very small by comparison. With a consensus fee - plus double-spend proofs - we close the loopholes to double-spending elegantly and simply. These are small prices to pay to achieve our vision of safe, secure instant merchant transactions, and much less disruptive than "preconsensus."

The Catch?

Which brings me to my greatest potential issue with this proposal, and that is that it may offend people's ideas about the way Bitcoin "should" work - namely, that the change to a consensus fee instead of a "fee market" doesn't "feel like" Bitcoin.

I want to challenge that assumption.

Let's not lose sight of the fact that Bitcoin Cash divorced itself from the BTC development strategy literally because BTC had the goal of "creating a fee market" by having "always full blocks." BCH has a stretch goal of having "never full blocks" with "always low fees." As a matter of social contract, we tell everyone that nobody should ever have to pay more than (for example) 1sat/byte. Why not incorporate that social contract into a consensus rule, and reap the rewards?

If BCH is able to keep block size relatively unconstrained, then there should never be a need to pay more than the recommended fee/byte. And as we've seen, there are problems to allowing lower-than-recommended fees (transactions that don't propagate, reverse respend vulnerabilities). Fees on BCH are like Goldilocks porridge: if the network is running correctly according to our engineering goals, fees should never be above or below the recommendation. We are already having to coordinate a network-wide minfee anyway to prevent propagation problems. Why not incorporate our engineering objectives into a consensus rule, and reap the rewards?

We should realize that block size doesn't exist in a vacuum: it is directly related to required fee. If BCH starts to fill up blocks, then we all agree the first order of business is to increase block size as far as the engineering will allow; and only then to allow fees to increase. So we should only have to increase the consensus fee once we've exhausted engineering limits -- again, this is a "good problem" that can only occur because we've been incredibly successful.

And if we should find ourselves in the incredibly enviable position of being so successful that we fill blocks up to their known engineering limits with fee-paying transactions, then at that point we might be able to deploy a "flex consensus fee" much the same way that we think about a "flexible max block size." While I've presented the "really simple" version of a flat consensus fee for the purpose of simplicity, we should realize that a lot of variations on this theme could exist, like a tiered fee structure, reduced fees for consolidation or CashFusion txns, etc. I could even envision a world where the fee is set in conjunction with an oracle that prices the fee/byte in "stablecoin" values, so that it's always the same "price per byte" irrespective of the market value of BCH.

I Don't Like Command-And-Control Either

There's a certain type of BCH user that is automatically opposed to anything that feels like a "command economy." I'm sensitive to this point of view. But a consensus fee isn't Big Brother telling you the price of a loaf of bread. Here's why.

I want you to imagine a world where you go to a Starbucks and there are no prices on the board. Instead, you're supposed to bid for your coffee in a blind auction. When placing your bid, you should take into consideration factors like: the size of your coffee, the time of day, the number of other people in line ahead of you, and how urgent your coffee is. You should make sure to consider the possibility that a busload of rich tourists might arrive at any moment who will outbid everyone in the room, and factor that possibility into your bid.

Is Starbucks "wrong" for having centralized control over its menu pricing? Is Starbucks rejecting the free-market? Would a "wild-west free-market" approach be better? Of course not. Personally I've never been happy with the idea that the cost to execute a Bitcoin transaction is some sort of unknowable mystery. I think most users would love the idea of a known "price menu" for their transactions.

The idea that transaction fees needed to be a competitive auction for a fundamentally scarce bit of block space was an idea foisted on Bitcoin from the outside by the people who wanted to make transactions expensive. If you operate under the philosophy that blocks should not be artificially constrained, then you reach the conclusion that it should be possible to have a fixed price for block space; and if the natural limits to block space are ever reached, then at that point the price can be raised. if needed.

The fact is that consensus is required among all participants of a blockchain. We have consensus rules that limit how much block space is allocated, that limit how much miners can mint in each block, and how much random data can be attached to each transaction. We can also decide on a fair price per transaction that, like the block size, can be adjusted up (or down) if circumstances require.

And let's not take our eyes off the prize: look what we gained!? We eliminated the miner bribe and reverse respend attacks!

Wouldn't it be nice to simply not need Avalanche or other "preconsensus" approaches, because we fixed the problem elegantly in a way that improved user experience overall?


Let's have a bigger conversation about the potential benefits of a consensus-level fee system!

$ 8.65
$ 4.26 from @TheRandomRewarder
$ 1.00 from @JonathanSilverblood
$ 1.00 from @emergent_reasons
+ 12
Avatar for Jessquit
Written by   116
1 month ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.


You might not like this solution at first. It might offend certain preconceptions about how Bitcoin "should" work. (...) The solution is: a consensus-level transaction fee.

Indeed I don't like it at all.

The problem is correctly described and your proposal is well articulated, so thank you for this quality post. However, I dont think that a consensus-level transaction fee is a good idea.

In my opinion, fees are the ultimate thing that guarantee censorship resistance of the chain. I really like this text written by Eric Voskuil that explains why.

The reason why miners will always want to include a transaction in a block is the fee it pays. If a transaction is blacklisted by authorities (e.g. because it is indentified as a darknet market transaction), then miners have no incentive to confirm it without a big fee to compensate them for the risk. This type of attack could appear sooner than we think, as some groups of miners start to follow regulators.

If you implement a fee level in the protocol, users will still be able to pay more, as a side fee. ViaBTC already does this for BTC transactions. But this side-fee market weakens users' privacy dramatically.

Besides, this is also why, as others have said here, your proposal does not solve the "Miner Bribe" doublespend.

I don't think such a change is worth it.

$ 1.18
1 month ago

I strongly recommend that all Bitcoin Cash ecosystem should rise the fees. If someone dares to do it, you will see strengthening of BCH on the long run, so far low fees have weakened Bitcoin Cash exchange rate vs Bitcoin and vs Ethereum. A lot of people think that the low fees are very beneficial, they are beneficial for customers, but not for the ecosystem and not for SLP tokens.

$ 0.00
1 month ago

As an end user, I had no idea any of these problems existed. It's been an eye opening read. There is a need in the market for a coin that works in real time (30 sec? 1 minute delay?) and can do small(ish) transactions with low fees. The first coin that brings that will get a big pie.

$ 0.00
1 month ago

Aside from @jonathansilverblood 's excellent comment on out of band bribes (they can even be nonfinancial gains; for example a miner can have an axe to grind against the merchant), the fee adjustment problem also goes both ways. In case we need to adjust the fee downwards in the future, a messy consensus debate and change would be needed. It might not be that bad considering we already want fee policies to be coordinated, but perhaps if we want this policy, we should also take the chance to think about an automated or semi-automated fee-setting mechanism so we don't have to deal with it again. Start working on a CHIP!

$ 0.00
1 month ago

Problem with automated is how you give it signal to move in either direction if your fee is forced to be fixed. The fee itself can't be the signal so you'd need something else, adding to the complexity of solution. If you give the fee some +/- allowance then maybe miners will try and game it, and it ceases to be fixed so you lose all the benefits of fixed. This reminds me of the blocksize discussion on the research forum where I particularly liked Tom Zander's comment: "If you expect miners to game the system, and we currently have no system. What, then, is the reason for introducing a system?"

$ 0.00
1 month ago

Interesting proposal. I would actually like to study the impacts of removing the min tx fee altogether, which would solve the reverse respend which might be the most problematic of the three types especially since both fast respend and (on-chain) miner-bribe are solved by DSP.

$ 0.00
1 month ago

One problem with this is that it actually does not resolve the miner collusion version - as long as the miner is willing to keep the transaction a secret and not relay it, no one will be able to create a double-spend proof and you can pay the miner out-of-band to achieve this.

That said, I still think this could be an improvement and it certaintly helps remove naive wallet/user misstakes, which improves the user experience.

I would encourage you to take ownership of a proposal to get this more deeply evaluated, like a CHIP.

Draft up how the change would be, make a list of all parties you think will be impacted that you can also identify and aquire contact information for, then reach out to the parties and get their involvement/statemenst. Bring it to the public at large and ask people to help you break it.

$ 0.00
1 month ago

Good point re. collusion/secrecy and out-of-band. Why doesn't the double spend proof protect from reverse double spend, tho?

$ 0.00
1 month ago

I loved your text! I really want this implementation, I hope the developers see this, because it is simple, and very useful. I read comments that say the miner can be bribed and that this method doesn't work, but that doesn't make sense. How would anyone pay a miner out to hide a transaction from buying a hamburger?

$ 0.00
1 month ago

Fyi, you can already pay a miner in BCH to accelerate a TX on BTC

Nothing preventing a miner from creating such an interface to boost BCH TX-es

$ 0.50
1 month ago

But a btc fee doesn't cost a hamburger, but a Macdonald franchise 🤣😂

$ 0.00
1 month ago

Hahah good point. Even still, imagine a McMenu costs $10, and there's an easy online txaccelerator service like that costs $1, then you could potentially save yourself $9 on that meal if you cheat. If the miner running such a service had a low % of hash-power then this trick would work maybe once in a hundred or thousand attempts and you'd be paying $11 instad of $10 for every failed attempt. Even if all miners ran their own boosting services, you can't know which miner will win the next block so you'd have to pay a $1 to each of them. Only if miners formed a cartel where they'd split your $1 they could break 0-conf, but breaking it is not in their long-term interest I think so I don't see it happening.

$ 0.00
1 month ago

Just to be clear, this does not completely fix miner bribe. It only prevents on chain miner bribe, where the miner takes the highest fee tx. However it does NOT solve out of band miner bribe where an entity sends money to a miner to swap out a transaction and instead mine a different transaction. So if someone really wants to collude with a miner to do double spends, they could still send them money via a different BCH transaction, or even send them a bribe over other payment networks.

$ 0.00
1 month ago

You have a clear view of it. At least there are good values and give you something positive. keep writing and I love reading your articles.

$ 0.00
1 month ago

Nice article keep it up bro I love you ❣️

$ 0.00
1 month ago

Okay, this was a very long article but there are so many obligatory information to know. I've been reading the article for 10mins, I'm just fascinated by your writing skill.🥰

Best wishes to You

$ 0.00
1 month ago

Happy to see this come out in a well-considered way! There are other benefits in avoiding mempool fragmentation generally as well. It really would need a lot of airing out and long term consideration about e.g. when purchasing power increases dramatically, will miners be willing to reduce it? Also regarding different OP codes, it may be that an economy around those is desirable (probably not - just throwing it out there). UTXO delta may also be a very important consideration. Like Jonathan, I really hope you or someone will create and own a CHIP for this. It's a long but probably worthwhile conversation, whatever the outcome.

*edit - from Rosco Kalis: breaks all current covenants breaks SLP postage terrible user experience for any wallet that doesn't get the memo

$ 0.00
1 month ago

You know, you can still bribe the miner through an accelerator scheme, the fee doesn't have to be part of the actual transaction, it can be paid in covert way.

$ 0.00
1 month ago

I love suggestions that challenge the established thought box.

$ 0.00
1 month ago