Jason Cox Extends Open Invitation for Assistance With Development and Review of Bitcoin Cash Code

BCH developer conversations have been taking place ahead of the upcoming May 2019 upgrade. In their latest video meeting, devs agreed that they need to know how much BCH is locked up in p2sh segwit addresses. It was also agreed that Andrea Suisani will take charge of the byte transaction size limit and Mark Lundeberg will review Amaury Sechet’s code on Schnorr signatures. Lastly, Jason Cox extended an open invitation for the qualified to assist with the development and review of BCH code.

Also read: Major Mining Pools Have a ‘High Die-Off Rate’ Study Reveals

Meeting of the Minds

A BCH developer meeting was held recently to get the ball rolling for the upcoming May 2019 upgrade. The meeting was moderated by David R Allen and consisted of lead developer of Bitcoin ABC Amaury Sechet, Bitcoin Unlimited developer Andrea Suisani, Bitcoin ABC developer Antony Zegers, Bitcoin ABC developer Jason B. Cox, Openbazaar developer Chris Pacia, CTO of Bitcoin.com Emil Oldenburg, and Bitcoin Cash developer Mark Lundeberg.

Agenda One: BIP 62, Attempts to Fix Third Party Malleability

After introductions, the meeting opened with discussions on BIP 62. Zegers pointed out that some BCH users are unable to recover their funds because they are sending BCH to BTC segwit P2SH addresses. Then, Cox asked if it was possible to identify the extent of this problem. In response, Oldenburg proposed indexing all segwit addresses and then checking the UTXOs, an extremely time-consuming process.

Alternatively, Lunderberg proposed a way to fix third party malleability by applying the clean stack rule to Pay-to-Public-Key-Hash and Pay-to-Script-Hash multisig. That way every other script would have to manually check itself using OP_DEPTH. However, he noted that his solution would require another hard fork on top of the May 2019 hard fork.

In conclusion, the developers concluded that they need to measure the amount of coins that are locked in p2sh segwit addresses before proceeding on BIP 62.

Agenda Two: Changing the 100 Byte Transaction Size

Lunderberg pointed out that since the August 2017 hard fork, there have been in the ballpark of ten transactions that were less than 100 bytes. Since a 100-byte limit could affect some transactions, he proposed relaxing it to 64 bytes.

Interestingly, Cox pointed out that it’s easier to to lower the byte transaction size limit than it is to raise it. Suisani added to Cox’s point, and explained that raising the byte transaction size limit would have to be implemented by hard fork.

At the end of the discussion, Suisani offered to lead the second agenda by maintaining a stream of communication between the developers, and writing notes to rationalize tweaking the constraint.

Agenda Three: Schnorr Signatures

On the topic of Schnorr signatures, Sechet pointed out that Schnorr has cost advantages because of batch validation. For example, computing and verifying eight signatures as a batch is more cost-effective than checking eight signatures individually. He then pointed out that Schnorr will aid with user privacy and is better for the Bitcoin network itself.

Even though Sechet had made an implementation of Schnorr just over a year ago, his code has not yet been thoroughly reviewed. The lead developer of Bitcoin ABC warned that the code would have to be reviewed more than usual and implemented carefully, otherwise the network would become susceptible to side-channel attacks through the branch predictor of the CPU and through the cache hierarchy of the CPU.

After Sechet’s explanation, Lunderberg agreed to review the former’s code within a month and a half. Sensing that everyone in the group was stretched thin, Cox issued an open invite to cryptographers and developers to assist with development and review of Bitcoin Cash code.

Agenda Four: Old Opcodes

As this point, most of the developers in the meeting had their plates full. In response, Suisani explained that he would reach out to the other Bitcoin Unlimited developers to see if they were interested in working on the old opcodes. Suisani explained that Bitcoin Unlimited developers were the logical choice as they had previously included Nchain implementation in the SV client they produced.

Closing Thoughts

Towards the end of the meeting, Oldenburg mentioned that there is currently a 25 unconfirmed transaction chain limit that is affecting various protocols right now, which needs fixing. He also mentioned that Bitcoin.com was currently working on its own on-chain dice game similar to Satoshidice. In response, news.Bitcoin.com reached out to Oldenburg for some closing thoughts on the developers meeting. The Bitcoin.com CTO was positive about the meeting overall, especially since the “limitation of unconfirmed chained transactions will be removed long term.”