I’m pleased to announce that BTCC has agreed to provide me funding for 14 billable hours a month of Bitcoin development work under my standard contract for the next six months. This funding has been provided on a “no strings attached” basis, with the one condition being that I provide a weekly report on my development efforts.

So here’s what I’ve been working on:

  1. Pull-req review — A wide variety of smaller and larger pull-reqs, but most importantly review of the recently merged BIP68/112/113 soft-forks.

  2. Hard-fork discussion with the signers of the Hong Kong agreement (and others).

  3. python-bitcoinlib — I added support for many of the new script verification flags that have been added to Bitcoin Core, along with the associated script (in)valid unit tests. In that past I’ve found reimplementing Bitcoin Core logic in python-bitcoinlib to be a good way to do in-depth consensus code review, so this work builds towards getting ready to do final segwit review.

Hard-Fork

So where are we with the Hong Kong agreement? Right now the main priority for myself and many others on the dev team is getting segwit released; the agreement said that segwit was expected to be released in April. The final Segnet4 testnet has been released, so we’re getting close, but that’s still a tight schedule. One thing we’ve done as a team to speed up that process is after the recent MIT Bitcoin Expo most of the team was able to meet up in person, and during that meet-up we decided to not make two modifications to segwit that I proposed, namely a (fairly big) change to how transactions are hashed that could - in theory - aid fraud proofs in the future, and secondly, my idea of prev-block-proofs to prevent validationless mining. With regard to the former, I recently took a close look at the viability of the fraud proof concept, and have some serious doubts about it, and both ideas can be added later with soft-forks anyway. Not perfect, but it’s a reasonable compromise I think, particularly with so many people outside of Bitcoin Core already implementing segwit.

With regard to the hard-fork itself, there’s been a lot of discussion among both developers and non-developers about how to speed up the time-lines for a possible hard-fork; remember that the Hong Kong agreement was for a time-line where the proposed hard-fork would actually activate around July 2017. Given that we have people who want to see a hard-fork before the halving, I think we have a rather large difference of opinions in the community!

So how could we speed this process up? First, I think we need to ask the question why do we want to speed that process up? One of the main things that been brought up during and after the Satoshi Roundtable has been the need for requirements. The issue here is two part: we’re not getting clear requirements from the payments industry for how many transactions per second they need Bitcoin to be able to support, and equally, we don’t have a sense of what kinds of decentralization and censorship resistance requirements they need (maybe they don’t have any?).

Personally, based on my interactions with the major Bitcoin payments providers and similar industry representatives at the Satoshi Roundtable I suspect the main requirement those VC-funded industry members actually have is “convince our investors that Bitcoin can scale ASAP so they give us more money”, but that’s not an viable specification to work towards… It does however, suggest that there’s a much more fundamental problem: we’re not doing a good job of communicating why we’re concerned about decentralization, and why we think larger blocks are a risk.

Right now one of the best references explaining those issues in depth is a three year old Bitcointalk thread; given that poor communication it’s no surprise that we’re seeing fundamentally broken proposals like BitPay’s Adaptive Block Size Limit, not to mention the numerous misconceptions we’re seeing in non-Bitcoin technical communities like Hacker News. Better communication of requirements isn’t a panacea — highly regulated, AML/KYC compliant, services like Coinbase will always have different requirements for censorship resistance and privacy security than the rest of the Bitcoin community — but we should at least understand what those differences are exactly. I personally have been reluctant to put these kinds of requirements down in writing in public due to fears of splitting the community, but in hindsight, I think that was a mistake that I need to fix.

Still, if major industry players were willing to make a clear and credible commitment to layer 2 solutions like Lightning that have genuine scaling, without compromising on decentralization, I think it’d be reasonable for developers like myself to be willing to support a higher risk approach to hard-forks, with shorter time-lines, as an interim measure to give the industry some breathing room. There’s two main things being discussed among developers that could help implement that:

  1. Forced Soft Forks — By guaranteeing that non-adopting wallets and nodes can’t unknowingly accept transactions as valid on a chain that they didn’t intend to accept, we can shorten time-lines because we don’t need to give people as much time to adopt new software.

  2. Coin Voting — Discussed extensively during the Satoshi Roundtable, with wide support, the idea here is that users’ wallet software indicates in transactions themselves that they are both ready, and approve of, an upcoming hard-fork. This reduces risk and allows time-lines to be shortened by both getting solid evidence that users are ready for the hard fork, as well as showing strong political support for that hard fork, reducing the risk that the Bitcoin currency splits into two incompatible currencies.

For example, suppose segwit gets delayed for some reason. Would I personally support doing a hard fork that was expected to activate within two or three months as a replacement for that capacity increase, if techniques like the above were used? If major industry players were willing to commit to layer 2 solutions, I’d be willing to support something like a forced soft fork, and I’d be willing to support a coin voting hard fork even if they didn’t.