Difficulties and opportunities for Bitcoin Cash 2026
Bitcoin Cash has as the goal/motto that they are providing the world with money that is just like cash. Every day usage of money. Providing the worlds needs to pay for your daily groceries and scones all the way to buying a house. From paying the weekly rent to getting dividends payments all on the Bitcoin Cash blockchain.
The chain already has been doing a metric ton of work to pave the way to get there and is the most fitting chain to actually be able to reach this future.
Yet, opportunities are still abundant stemming from difficulties that basically have not yet been attacked, let alone solved.
This document tries to briefly go over some of the opportunities that anyone with sufficient patience and dedication can solve.
1. Transaction fees to become decided by the market, not the full node operators.
The basic premise of this part is that eventually demand will outstrip supply. We build to win and this means we should assume we will get into scenarios where we have more demand than we can handle.
Blocks would be full and backlogs will appear. Some will uncork the champagne, many more will be annoyed at their money not being as fast or secure as it used to be.
The difficulty is about deciding what is a good transaction that should be mined now and what is later. The current solution is based on fees, and fees alone. Which is not a very good solution which leads to $50 fees and stems from the Bitcoin Core minds who we know were hijacked.
The much better solution for the Bitcoin Cash devs is to NOT decide who is mined now and instead give tools to miners to let each of them decide individually. You know, open market style. They may not like the responsibility, but they are the only party that has the incentive to do it well. Best part is that the miners that embrace this will be more profitable. So I have no doubt this will happen.
For miners to be able to decide who makes it into a block we need tools.
1.1 Transaction selection for mining
Today transactions a miner mines are selected based on nothing more than it paying enough fee. There are various options that also make a lot of sense to keep the chain clean and profitable. For instance transactions that eat more UTXOs than they produce, those should be cheaper as to avoid exchanges and others from never cleaning up or considering moving money to be expensive.
Another example of a good selection criteria is if the transaction is expected to raise the value of Bitcoin Cash. If a user makes 400 transactions in an unconfirmed chain, all in a one block interval, there is a pretty darn good reason to believe it is not going to be nearly as positive for the coin when compared to a boring money transfer transaction spending coins that last moved a month ago. The idea is called ‘bitcoin days destroyed’ and has been well documented.
Miners should be able to select transactions to include in congested blocks based on such parameters in order to keep the chain as valuable as possible. Some tool to build a block with such parameters is needed for that to become possible.
1.2 Mempool separation from BlockTemplate
Today the full node has a Mempool that is used for relaying transactions as well as for mining a block. This causes the perspective to be tweaked about what transactions a full node aught to relay. The assumption is implied that what is relayed is also mined. It helps a lot of we separate those two concepts from each other and sever the connection of relay vs mining.
A user that owns a full node expect the node to be able to give warning about double spends, and it requires the Mempool for that. Because today if you change the parameters of what transactions you want mined, this impacts the mempool and relay too. And the double spend protection goes away in far too predictable a manner.
1.3 Transaction ownership
When a wallet creates a transaction and sends it to the network it should really not assume anything about that transaction getting mined. The wallet may have set too low a fee. The peer it was connected to may have just tossed the transaction. The “network” can verifyably not be responsible for everyone’s transaction getting mined. The full nodes are not the miners, the full nodes are not even meant to be reliable. Trust but verify! Check the transaction hit a block when the next block comes.
The only sane idea is that the wallet sending (or the one receiving) is responsible for the transaction being offered to miners again and again until it gets mined.
Nothing complex, really. Simply a different way of wallets attitude (and code). That gets you there for a large part.
When wallets are following this approach, full nodes should consider severely lowering the length of time they keep an unmined transaction in the Mempool. Maybe 10 blocks only. This allows a wallet to resend it with higher fee later, if wanted. Additionally it would be really nice to get a new message when a transaction is accepted into the Mempool. Today only a message is send when the transaction is relected. What would be nice is when my wallet sends a transaction and it gets back from the full node how much longer the full node will keep it before tossing it.
2. Payment protocol next
The actual contact between a payer and payee is basically enshrined in a “payment protocol”. A protocol is simply series of formal steps taken to reach the expected goal.
There are a LOT of features that a mature bitcoin cash needs which should be made easier and mostly automated. And that is why we need a new payment protocol. Nothing today is coming close to what we want.
The needs start by being able to make payments between two people both on mobile devices, without the need of a central server.
But we also need to be able to have a payment request that simply request the funding of a transaction. Because if we simplify it to that level then the receiver has a lot more flexibility in what happens with that money. For instance the point of sale software can add a token to go back to the customer. Or maybe a small fee can be paid for some 3rd party.
A protocol is just a series of formal steps. It is useful to think this as an longer interaction between the phone of the payer and the phone of the payee. One concept that I would love to see is that when I send a transaction to pay for something and the merchant can’t verify it because of a missing transaction on the network. Then I can respond with the missing transaction.
What this idea does is that it allows not internet connected or even dumb wallets to become useful. Imagine I top up my payment-card with my phone sending the data from that phone over NFC to the card. No Internet involved. Then for some reason that transaction never gets send to the network.
OK, the next day I buy a scone and I pay with my offline payment-card. The money on that card is the result of yesterdays transaction. That the merchant can’t find on the blockchain. Solution: send the transaction that is on the payment-card from yesterday and both transactions one after the other are indeed fine and OK. I get to eat my scone without shame and the merchant got her money.
3. Repeat Payment Processor
Flowee Pay has solved the repeated payments problem, you can schedule a payment in your app and it creates and signs and sends it on the day you intend it to be send.
While this is very nice, this alone doesn’t come close to what people are expecting from a system like Bitcoin Cash if it were to replace what companies use today via the banking system.
A person that wants to pay their rent every week or so needs to be able to have several more components than JUST sending the money. The main one is getting the initial repeat payment set up in the first place. While this could be done as part of simple payment request, that would make a lot of needed parts harder.
What we need is the ability for the company to update the payment amount. Unfortunately, prices do change.
What we also need is the ability to get late payment notifications. A user could purely accidentally have failed the payment. They should have a way to get a message on some system or chat. Or email or snail mail.
And that instantly leads to the obvious next requirement. Late payment punishment. Most companies require a late-fee in order to entice people to pay on time. For a company being able to demand that and it just showing up in your wallet (maybe with email notification) is needed.
The point is that we expect more regular communication between the company asking for the payments and the customers paying their bills. And those companies will not want to each run a server, and those customers don’t want to find the connection details of each company they pay to.
The way this is setup can be a simple website. But the end result just has to be nice and usable which leaves a lot of interesting options available. Maybe some sort of message system where messages can be deposited and the other side can fetch them. These messages include the data they want. A central server may be useful, a nostr path is possible. Maybe a binary payload via SMS.
The opportunities are yours to figure out.