read.cash is a platform where you can earn money for your articles and comments. You can get paid upvotes
from other users or just earn points for writing articles and comments, which are converted daily to
Bitcoin Cash (BCH) cryptocurrency, which can be used on the Internet or converted to your local money.
Takes one minute, no documents required
MailGun (our mail provider) has blocked our domain, so at the moment no mail can go out (verification emails, notifications, etc). Still unresolved, no specific reason given.
Time flies - more than a month has passed since BCHN v0.21.0 was released, and a little over two weeks since my last report. Since then the COVID-19 pandemic has touched us all in different ways, but I hope everyone is taking the necessary precautions, staying as safe and healthy as possible and helping others do the same.
I'd like to make these maintainer reports a bi-monthly occurrence. If we get much busier with developments in the coming weeks, I might only have time for a monthly report myself, with other reports (e.g. BCHN financial statements) possibly being done separately.
SBI crypto mining on BCH seems to have dropped away to almost nothing, losing us some support. I do not know the precise reason for this removal of hashrate by the pool, but they contributed a fair amount to signaling for our project. I thank them for their past support and hope they can come back. If they do have feedback for our project, contact me!
(Update 2 April: I've heard now, inofficially, that allegedly the drop-off from SBI is due to testing of their pool, and that the intention is to continue signaling for BCHN - this seems good news and we hope they return!)
We lost some signaling from ASICseer pool, who stopped their pool project. They gave me an official statement on the reason: "ASICseer remains a strong supporter of the BCHN project. However, ASICseer has terminated its pool project due to the broken BCH DAA. The current version of the algorithm allows BTC mining pools to exploit periods of low difficulty by bringing exahashes of foreign hashrate onto the BCH chain, leaving all other honest pools at a competitive disadvantage."
(note: "foreign" here is not talking about nationality, it refers to hashrate which does not originate from miners who care about BCH)
Bitcoin.com pool is still signaling support for BCHN. Thank you Bitcoin.com for your continued support.
Due to the above, the amount of blocks signaling for us has dropped from a high of ~12.5% of BCH blocks in this last 2-week period, to about ~ 5.5% over last 1000 blocks, per https://cash.coin.dance/blocks at time of writing.
Since last report, the project has received funds through its multi-signature donation address bitcoincash:prnc2exht3zxlrqqcat690tc85cvfuypngh7szx6mk .
However, we are on the verge of participating in the Flipstarter node crowd-funding campaign, which may see the addition of further funding addresses earmarked for specific tasks which will be outlined in our funding proposal.
As of today (block 628882), our public wallet, which holds all our funds at the above address, contains a balance of 143.23690617 BCH, which represents a net increase of 2.18412567 BCH from last time.
There were three payments made from our multisig wallet during this last period:
2020-03-18: -0.26542268 BCH for two article translations to Chinese (the previous maintainer report, and our 'May 2020 and beyond' plans)
2020-03-18: -0.0000048 BCH due to a wallet configuration mistake, the change from the preceding transaction was sent to a new address instead of being returned to the main donation address. We made another transaction costing a small network fee directly afterwards to return the change from pplgxva6cdkl9ye3par05yspm37jmjpv7vj569rw0a back to the main address prnc2exht3zxlrqqcat690tc85cvfuypngh7szx6mk
2020-03-27: -0.03130073 BCH , another re-imbursement for a Chinese translation, this one for announcement of maintaining our own BCH specification (without the IFP parts) for the May 2020 upgrade
The total expenses over the period were -0.29672821 BCH.
At the moment, most issues being raised are by contributors to the project who are finding things to fix, and need to track those items. As I remember, there were very few support requests from users (less than 5), and some of those were raised and addressed on our Slack.
With regards to the project's previously announced plans, progress has been made on the following items:
BCHN developers have been looking at the univalue library (originally created by Jeff Garzik, and nowadays maintained by various projects such as Bitcoin Core independently), which is used extensively by RPC calls.
It appear significant performance gains through optimization are possible, and some early promising results been achieved by a collaboration of two BCHN developers (Calin Culianu and BigBlockIfTrue).
further updates of developer and build related documents
overhaul of UNIX installation documents, splitting out separate documents for Debian-based, RPM-based, Arch Linux and FreeBSD operating systems
finalization of our security disclosure document, including our security contacts, PGP key, security email address and confirmed disclosure relationships with other projects (see below for more info)
FreeBSD platform instructions for GUI build were added and validated, and a failing regression test was fixed. We were able to confirm that all unit and regression tests pass on FreeBSD 12.1.
A static checking pipeline stage has been added to our Continuous Integration (CI). At the moment it runs the same checks as Bitcoin ABC's "linting", but can be extended as we come across more static checking tools that appear useful to our project. A manual run of Clang Static Analyzer has been performed on a recent master state (see Appendix A), with no significant issues detected in the application code. In the next weeks I will familiarize myself with other tools that may give more information (I already used Coverity Scan on Bitcoin ABC in the past, but now we also have a PVS-Studio free license (thanks Program Verification Systems, your support of open source projects is awesome!)
Creation of accurate May upgrade specifications for our project:
Our specifications for May exclude the IFP consensus changes but are otherwise the same in terms of features.
Public Consultation System (PCS):
We have gathered community feedback (25 responses) to our March 2020 survey and stored it in our PCS repository. We are beginning to evaluate it (see Appendix B) and will store evaluation outputs in the output section of that repository. After some more evaluation I will report some summary results which should be easier to digest. Just reading through the feedback has already been very useful to me in forming a mental picture of the issues that are most important to many users. As we did not receive much feedback from the Chinese community through this, I am considering to launch a separate survey targeted at that part of the Bitcoin Cash community in April, to see if we can get a clearer view of their needs.
Repository for BCHN Project Management:
A new public project management repository has been created. This repository will be filled with various PM documents related to the project setup and life cycle of BCHN software, its quality control processes, its financial activities including funding campaign materials and more. At this time, some team profile inputs are being collected there to supply the construction of our Team page on the website. The team page is being filled on a voluntary basis with short biographies and pictures (where available) of our project contributors. This is in response to community feedback that we should represent ourselves and our resumes a bit more personally. I'm looking forward to seeing more of our developers and testers on there soon!
Draft of our upcoming Flipstarter crowdfunding campaign:
I'm working together with our team on the abstract and proposal text which we will hopefully be able to submit to the Flipstarter team in the next day or two. Can't give too much away yet as the details are not all final at this time, but it will be out soon anyway, so patience grasshoppers!
This is being managed on our side via Issue #45 (Port Xversion from BU). Our current status is that a working agreement on the required adaptation has been reached to make Xversion palatable to BCHN and others, and that BU developer Greg Griffith is going to work on adapting a specification which will then serve as basis for common implementations.
In the process of confirming which projects were amenable to forming a security relationship with the "new kid on the block", BCHN, I reached out to multiple projects. The following projects confirmed and we have entered a mutual (reciprocal) disclosure relationship:
I believe we have a similar informal understanding at this time with Bitcoin Verde, but I still need to confirm that formally. Congratulations to Josh Green of Software Verde on the birth of his daughter, all the best from me & our project.
Unfortuntely, the following projects did not respond at all to my explicit invitation to form a responsible disclosure relationship with us. I sent them invitation emails on 11 March 2020 to their official security addresses.
Our figurative doors at BCHN remain open to any projects that are closely related (protocol wise) and would like to form a security relationship with Bitcoin Cash Node. Contact us at security at bitcoincashnode dot org , or come visit us on our Slack and have a chat.
Our main focus in the next days will be on getting our fundraising campaign into gear, but in parallel I will push a minor roll-up patch release of our project. We are committed to a hard deadline of no later than 15 April, to give at least a full month for users to install and test. Reminder: this will be a completely optional release - users already running BCHN do NOT have to upgrade again before 15 May unless they wish to run our latest software (which we encourage, of course!)
Output of Clang Static Analyzer test run (clang 8, default checkers):
The reported code sections were all in the third party libsecp256k1 library which is cryptographic code and likely takes special measures that static analyzers will find objectionable but which have good reasons for being the way they are (e.g. to defend against timing attacks or making extra sure secret data does not leak).