BTCC Funding, Development Report, and Hard-Forks

Mar 31, 2016

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:

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.

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:

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.

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.