Let's create a hypothetical scenario where you have paid someone recently in Bitcoin Cash, and proceeded to pay 49 more people afterward. Due to Bitcoin Cash's 0-confirmation stability, you can do this and you were able to pay even your debt in the banks for being able to get it into Bitcoin Cash. However, you realize that you need to pay someone else and the block hasn't arrived yet. Your wallet application would then let out an error message, something like "mempool chain too long".

You silently panic and decided to check the blockchain, trying to wait for a new block and it takes twenty minutes for all your transactions to get 1-conf, but by then your receiver has been waiting in front of your face.

Can't imagine it?

Now imagine if you are a developer who wants to cater to millions. You created a service where you can tip with other users using Bitcoin Cash and launched the website.

Immediately, the code started to give mempool errors after people signed up and started to tip each other with usage.

You can know how things went because that was noise.cash's problem for a few days.

The Chain

This event is called the "transaction chain limit" where you spend unconfirmed transactions towards another transaction. This is caused by a "chain" of unconfirmed transactions, all connected towards the first transaction submitted.

This can happen due to multiple things, such as paying multiple people in batches of transactions or implementing a system that pays more people than the network anticipated you to do.

This isn't a Bitcoin Cash-specific problem, but it's more prevalent in Bitcoin Cash due to sites like read.cash, memo.cash, member.cash, and Satoshi Dice.

This was brought into light during the development time to be implemented in the May 2020 Upgrade by Bitcoin ABC and Satoshi Dice created a bounty to raise it from 25 chained transactions to complete removal to fix it. What had happened was that Bitcoin ABC raised theirs to a 50-chain limit, and Satoshi Dice didn't like it.

Until today, the problem is still there in the Bitcoin Cash Node and other developers, like @Read.Cash/@mainnet, need a better fix than a 50-transaction chain limit.

How did this happen?

It was already explained by Jonathan Toomim, Bitcoin ABC had a problem with its algorithm regarding the performance of the ABC node's transaction retrieval. In essence, it was a way to ensure 0-conf stability.

However, due to the growing usage of BCH, Toomim gave a $1000 bounty about it.

This is one of the most important things that will need to be fixed for BCHN. Other nodes are already free of it, after all. Bitcoin Unlimited only had it as a command-line setting and they have higher transaction limits.

Bypassing the Limit

Now, back to the story at hand at the start, how did noise.cash fix this little problem? They fixed it by not fixing it because teams at BCHN is already working on it. The specifics on how the noise.cash team fixed it, however, is by implementing a queue to ensure all transactions would get through.

If you look at what noise.cash has told about, they use 10 wallets to spread out the payload, and even then it's too much for their node to handle. This meant that they have an overall limit of 500 transactions per block and because we have a mining pool that doesn't want to include transactions, this is sometimes a problem, especially when it has backed up a lot.

The side effect, however, is that your tips from the site are now delayed based on how many people have been tipping each other lately.

A worthy delay until BCHN fixes it.

If you want guys, you can follow me at noise.cash!
https://noise.cash/u/RowanSkie

I might start to write something new for once, like stories for an upcoming game running in BCH with @mainnet as its API, perhaps?

This is Rowan, signing off.

Happy New Year!

(I'm such a bad person for finishing this in 2021...)