[Bitcoin-ml] Formal bitcoin protocol specification - project proposal

Cláudio Gil claudio.f.gil at gmail.com
Sun Jan 14 12:08:12 UTC 2018


I agree that a specification is an increasingly necessary thing for the
public and permissionless Bitcoin protocol. Nevertheless I believe that the
3rd benefit that you point is taking the specification work too far and can
be counterproductive.

> 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.

In my opinion any specification working group should remain neutral and
avoid being part of the decision process for protocol evolution. In simple
terms, the working group should not try to answer the question "What will
be valid tomorrow?", when writing the specification. Instead they should
specify what is valid today and what may be valid tomorrow. This means
that, although proposals for future rules should be specified, they should
be kept separately from the main specification and in an equal footing with
other proposals. Once a proposal is adopted it can be moved to the main
specification.

What does it mean to be "valid" and "adopted"? It seems obvious to me that
the introductory sections of the specification must start by specifying
this. Gavin Andresen's definition for Bitcoin, for example, stopped working
for Bitcoin Cash at block 4785589.

Regards,
Cláudio Gil
Random person on the Internet

2018-01-14 4:11 GMT+00:00 Steve via bitcoin-ml <
bitcoin-ml at lists.linuxfoundation.org>:

> 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.
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20180114/8d012e39/attachment.html>


More information about the bitcoin-ml mailing list