Join and earn Bitcoin Cash for participation

Some practical problems faced by Bitcoin Cash (BCH)

21 265
Avatar for arslankhalid
Written by   28
2 weeks ago
Topics: Bitcoin Cash

Slow development of basic protocols

The upgrade of BCH on May 15 this year was the lowest community and media attention in history. Whether it is media reports or community discussions, it seems that everyone is not paying attention. This is also the upgrade with the least changes in BCH history, and there are no new technologies that are more news-intensive. Three main functions have been added. The signature check method "sigcheck" is changed when the script is executed; the opcode ": OP_REVERSEBYTES" is added to reverse the bytes in the string; the transaction limit in the memory pool is changed from 25 to 50.

In the previous upgrade, the BCH block size was increased to 32MB, the Satoshi opcode was re-enabled, OP_Checkdatasig was implemented, CanonicalTransactionOrdering (CTOR), and Schnorr signature support were added. These upgrades are milestones for BCH. As for why BCH's basic protocol development has slowed down, it is mainly because the development team lacks money and lacks technical developers. It can be seen from the fund-raising plan announced by Bitcoin ABC and other development teams that BCH's basic protocol development is a huge project.

Fortunately, BCH's main development team has received enough development funds. The total funds raised by Flipstarter for the BCH full-node client projects BCHD, BCHN, Knuth and Bitcoin Verd donated more than 2000BCH. BCH's important development team, BU, has sufficient funds and does not need to raise funds. BCH's core development team, Bitcoin ABC, has obtained US $ 1.5 million in development funds through other channels. This means that the BCH development team will not worry about development funds for a period of time in the future. With sufficient funds, you can concentrate on the development of BCH infrastructure, making the BCH infrastructure more powerful.

Infrastructure deterioration

Cointext, one of the most important projects on BCH, was rejected because of the low adoption rate of BCH. Cointext is a company, an application, or a third-party transfer system. Users can use Cointext to trade BCH in the form of SMS on their mobile phones without the need for Internet access and low handling fees. Bitcoin Jesus, the most important supporter of BCH overseas, fired 50% of the company's employees a few days before the halving, and bitcoin.com is no longer an open source wallet. However, Bitcoin Jesus appointed Dennis Jarvis as the new Chief Executive Officer (CEO) of bitcoin.com, everything returned to normal. Cointext is still welcomed by the community, and it continues to make efforts in payment and international remittances. BCH payment in Australia even occupies most of the cryptocurrency payment market.

Bitcoin cash transactions grow slowly

According to BitinfoCharts data, the number of Bitcoin Cash (BCH) transactions has remained at around 50,000 in a year. It can be seen from the graph that the growth rate in the past year is very slow and basically remains stable. Bitcoin is 300,000 transactions, only one sixth of Bitcoin.

Merchants accepting BCH payments grow slowly

According to r / btc's "Monthly Merchant Report", the merchant adoption rate increased by only about 50% last year, of which 88% + came from online merchants and about 5-10% came from physical stores. It seems to be growing faster, but it is still a bit slow for BCH, which is committed to becoming a global payment currency. If it has increased 10 times compared with two years ago, BCH is also popular with merchants in the payment field and is the mainstream of cryptocurrency payments.

Bitcoin ABC and BCHN dispute

Bitcoin ABC supports the controversial BCH Infrastructure Finance Plan (IFP), but the plan has not been widely agreed. In order to oppose the plan, some developers created a full-node client BCHN. The only difference between this client and the Bitcoin ABC full-node client is the removal of IFP in the code. IFP was controversial in the community at that time, and the technical differences among developers even increased to language violence, which caused an extremely bad impact on the BCH community, and was once misunderstood as BCH to be split. However, in the end, both parties chose to compromise, both refused to split, respected the longest chain principle, and IFP did not implement it.

Recently, the BCH community proposed the creation of a foundation. The foundation is responsible for raising BCH's development funds and coordinating relationships within the community. Others have proposed proposals to encourage developers in the form of Nobel Prizes. These are good suggestions, I hope the community can unite and work together, less debate, more thinking!


23
$ 5.31
$ 5.00 from @MarcDeMesel
$ 0.11 from @tula_s
$ 0.10 from @Darkerduck
+ 1
Sponsors of arslankhalid
empty
empty
empty
Avatar for arslankhalid
Written by   28
2 weeks ago
Topics: Bitcoin Cash
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.

Comments

Yea! Indeed less debate. We need all this currencies to be stronger and more valuable. Although I dont have much Idea about this article... But I believe its time to get things done as it might have been

$ 0.00
1 week ago

This is very wonderful article. Your content is good. Thank you for sharing your informative article.

$ 0.00
1 week ago

Wow thia will be very useful and informative for those bch maniac. If you alowed me can i share this article in another platform . I think it will worth it

$ 0.00
1 week ago

The number of transactions does not reflect the usage. This is not the case for BTC and BCH. Unfortunately, most of the transactions are still speculative transactions between the Exchanges, and because more speculation occurs with BTC than with BCH, the number of BTC transactions is also much higher.

$ 0.00
1 week ago

I have been holding some BCH for a while, hopefully more market adoption will happen soon and increase the value of the coin.

$ 0.00
1 week ago

Then use it. If you hold it and don't use it, acceptance won't rise.

$ 0.00
1 week ago

I do use it, I like to play poker online with it and use it for trading, etc.. If you are ever interested, check out

https://blockchain.poker/#/?affiliate=547425a60bcde0b9474f9d02d7b3b956#cash

$ 0.00
1 week ago

That's good that you use it. Any real use of the crypto is helpful. But better would be the use with real merchants. Do you know the many possibilities where you can use BCH?

https://read.cash/@Read.Cash/bitcoin-cash-specific-sites-and-applications-7f03d537

$ 0.00
1 week ago

Thanks for the information

$ 0.00
1 week ago

Thank you for identified those itches as the cogs in the wheel to success for BCH. "It will be appreciated if you can suggest the ways to rectify those errors. I believe the authorities concerned will take bold actions on it".

$ 0.00
1 week ago

Very useful information . I agree with that. Less people seems to aware of this change . Rather they focus mainly in halving event

$ 0.00
2 weeks ago

This article was so good, it acually looks highly similar to what i wrote so i am wondering if i influenced you lol

$ 0.00
2 weeks ago

SigChecks is a big development milestone. It is very necessary for future scaling, and significantly simplifies the node's internal operation.

$ 0.10
2 weeks ago

Would you be able to write a blog on that?

I'm still very much confused what the point was that was trying to be solved by the sigchecks feature addition, where the basic idea requires an actual UTXO lookup to find the output script, this is definitely more complex and expensive than the old sigops, so maybe you can explain why you see this simplifying the internal operations.

$ 0.00
1 week ago

The main problem with SigOps was the retarded counting mechanism. SigChecks simply count the number of signature checks you execute, that's it. SigOps on the other hand counted signature checks when they were not executed and failed to count signature checks when they were executed.

Additionally, the SigChecks limit depends on the block size limit, instead of the SigOps limit depending non-continuously on the actual block size (introduced when BCH split from BTC), which had all sorts of crazy considerations when deciding whether to add a transaction to a block template.

By counting signature check operations separately, you can allow a higher number of other script operations.

$ 0.00
1 week ago

SigChecks simply count the number of signature checks you execute, that's it.

For that to work you need to fetch the matching outputs for a tx. This means you need to do a UTXO lookup and load the previous output from disk. Both of which have a significant performance impact.

The "retarded mechanism" was there because it was cheap. This isn't.

Additionally, the SigChecks limit depends on the block size limit, instead of the SigOps limit depending non-continuously on the actual block size (introduced when BCH split from BTC)

Actually, that was because BU refused to enable sigops checks without this stepping mechanism. (remember, when BU forked classic on testnet due to them removing sigops checks?, this happened shortly after).

By counting signature check operations separately, you can allow a higher number of other script operations.

Well, a typical block has maybe 200 to 400 sigops. While we allow 20000 per MB. Maybe theoretically it means the limits are higher, but practically there is no change. This can't be the reason for increasing the node complexity...

Anyway; you haven't answered my question:

I'm still very much confused what the point was that was trying to be solved by the sigchecks feature addition

$ 0.00
1 week ago

I don't know why you keep bringing up UTXO lookup costs. It does not make much sense to me to mix that with signature checking costs.

The problem solved by SigChecks is to limit the costs of signature checks. The old SigOps counting mechanism tried this too but did a poor job because it didn't count signature checks when they actually occurred.

$ 0.00
1 week ago

I don't know why you keep bringing up UTXO lookup costs. It does not make much sense to me to mix that with signature checking costs.

Because to calculate the sigchecks you need both the transaction you are checking as well as the output it is spending. Sigops didn't need that.

This extra step means you can only check sigchecks if you have a full node with a UTXO and the associated previous output or previous transaction. You can't do the check without having the output of the previous tx.

The problem solved by SigChecks is to limit the costs of signature checks.

Good to know, it failed.

$ 0.00
1 week ago

Right, I get what you're saying now. For purposes of block/transaction validation (for which you need to count SigChecks) you are going to do that UTXO lookup anyway, so the old system has no benefit in that context - it does not change the time required to conclude a valid block/transaction is valid. The benefit compared to the old system is that it actually works to block a DoS vector because the counting mechanism can no longer be gamed to make you verify a large number of signatures despite the SigOps count being low.

$ 0.00
1 week ago

Yes but most of the people are not aware of it like they do in bitvoin halving. I realy dont kniw why

$ 0.00
1 week ago

Good information to be honest. But i think BCH can come past these set backs with a matter of time. It is a strong coin with a great future

$ 0.00
2 weeks ago