Community Update: Sprout Development

As we are all painfully aware, the Sapling upgrade that is being developed to close the vulnerability announced earlier this year by the Zcash foundation has been stalled for some time. Due to the uniqueness of the BTCP code and its integration with Bitcoin functionality the changes required to implement Sapling are complex and affect many individual code items. As well as closing the vulnerability, Sapling was to provide increased shielded transaction efficiency leading to a lower computing overhead which would allow for faster shielded transactions. Additionally, it would allow decoupling of the wallet and zero knowledge processor allowing for a lightweight client.

Whilst these changes are exciting, they are proving to be challenging to implement with the resources that we have available and our primary focus must be on ensuring that the protocol is robust and not subject to the announced vulnerability. It is also clear that the primary focus of the community is on the ability to trade and increased presence on exchanges. With the vulnerability still present, it would be irresponsible to seek listing at this time and it is unlikely that any ‘good’ exchange would consider this possibility unless the protocol was deemed to be safe.

Privacy is key to BTCP, and, while the Sapling upgrade would allow easier access to privacy features for the masses, the fact remains that shielded transactions are currently available using the full node wallet.

With these factors in mind, the new treasury has been seeking alternative means to ensure that the protocol is secure and that the vulnerability is fixed. This will allow us to progress with additional features and functionality with the knowledge that BTCP is not compromised.

Rather than implementing Sapling, it is possible to close the vulnerability by updating the sprout circuit as has been done by Horizen. This would result in a much smaller change to the code which has advantages in terms of testing and ensuring that additional vulnerabilities are not introduced. It is known that the implementation of Sapling introduces the possibility of a denial of service attack by spamming the network with shielded transactions for example.

All of these factors have led to the new treasury liaising with developers who will be providing a proposal to implement and test the necessary changes to fix the vulnerability by making changes to the sprout circuit. This is an unprecedented move by the new treasury, but it is felt important for the success of BTCP that the protocol is stabilized in order to provide a solid base for progression. It is estimated that the new treasury will need to pay in the region of $3,000-$4,000 for the work to be completed. We ask the community to raise any objections or comments within the next 7 days. However, we hope that you all agree that the future of BTCP depends on having a secure protocol.

We hope to have the proposal soon from the developers with timescales and a detailed breakdown including costs. It is anticipated that this will be merged with the change to Equihash 192,7 and removal of the difficulty bomb.

It is worth noting that the changes proposed will not prevent the implementation of Sapling at a later date and it is hoped that development will continue with this in mind.

As the new treasury, we are keen to ensure that the needs of the community are met. As such, we will be cognizant of the sentiment in the community on how best to work with the limited funds that we have remaining. If you have any suggestions you would like to make, please take to Telegram or Discord as a sounding board so that we can have a healthy discussion and debate and together determine the future direction of BTCP. It is anticipated that a ‘wish list’ is created by the community and proposals for change are made and stored in a backlog for devs to consider. Do remember that we are a decentralized project, and as such, your involvement is vital and very much welcome!