[Bitcoin-ml] Formal bitcoin protocol specification - project proposal
Steve
shadders.del at gmail.com
Sun Jan 14 04:11:03 UTC 2018
I'm sure many will agree that current situation where the bitcoin
protocol is defined as "whatever the reference client does including all
the bugs" is tenuous at best. Not only does this make it risky and very
difficult to re-implement the protocol. But now with bitcoin cash we
actually have three reference clients. The fact that they all fork the
same code base mitigates the risks somewhat but as they diverge further
and further the degree of mitigation falls. Furthermore as we scale and
find ourselves needing to radically re-engineer large parts of the code
the pace of divergence will likely increase.
As such I feel like it's time to get this addressed. I would like to
propose the formation of a working group with the goal of producing and
maintaining a formal protocol specification that addresses both hard and
soft consensus rules. Possibly extending into the network layer.
To that end I've had discussions with nChain and they are willing to
sponsor this as a project. This would include provision of a tech
writer and other resources as well as putting together a workshop to
kick things off. I would envisage starting off by convening a workshop
session somewhere at which we ideally have a technical representative
from each of the three Satoshi node teams as well as from the
re-implementing teams. As far as I know out of the ones that support BCH
that includes Bitcrust and (possibly) Parity. The aim of this workshop
would be to work through the code and develop of a set of known rules
and bugs and specify them as tightly as possible. Once we have the
framework in place we can go through an iterative process remotely to
get the rule set to a point of complete coverage and non-ambiguity.
A natural progression from this point is a separate project using the
protocol spec as the starting point to develop a comprehensive, language
independent, test framework. Many tests already exist although a lot of
these are c++ specific unit tests. Although I would envisage extending
upon the many of implementation independent tests rather than starting
from scratch. If we have a fully defined protocol then we are in a
position to measure the degree of coverage of the test framework and
extend it as necessary. This give us some key benefits: 1/ It allows us
verify the defined protocol rules against the Satoshi nodes to ensure
they have been defined correctly. 2/ Gives future implementations a far
higher degree of confidence in their level of protocol compliance. 3/ A
clear and well defined process for future non-contentious hardforks:
define spec changes, code tests, code implementations, ensure all
implementations pass, schedule fork time.
nChain's funding commitment also extends to the Test framework project.
To that end they are willing to fund at least one C++ developer position
(initially for this purpose but will likely stray into other areas as
these things tend to do) either full-time/part-time or as a project
based contract. I know it's a bit cheeky of me to mention it here but
it highly relevant to both projects so if anyone is interested feel to
contact me on steve at ncrypt dot com and I'll will put you in touch
with the right people.
So this post serves a dual purpose of being a proposal as well as a call
for expressions on interest in participating either just in the workshop
or in the entire project at more involved level. I'm open to other
ideas of how to approach this. I know writing a protocol spec isn't a
very sexy project. But given that nChain is committing to funding it as
a community project and the potential benefits to future of BCH are
significant, I think it's an opportunity worth seizing. Opening up to
new implementations not only adds diversity to the ecosystem but creates
a distinct competitive advantage for BCH. Not to mention increased QA
for existing implementations.
More information about the bitcoin-ml
mailing list