[Lightning-dev] Standardization

CJP cjp at ultimatestunts.nl
Mon Sep 21 17:43:48 UTC 2015

On returning home from the Scaling Bitcoin workshop, I thought it was
great meeting some people in real life and discovering we basically all
want to achieve the same things. Still, I think there are some
differences in how we think certain problems should be addressed.

Design decisions in Lightning don't suffer from the same "consensus"
necessity as the block validity rules in Bitcoin, but still, some
decisions carry a strong network effect, and might be hard to reverse
once made. The people I talked to felt the need to make no mistakes on
these design decisions, but at the same time I feel the need to make
them ASAP, so we can quickly launch a prototype and convince the world
of how great this is.

Because of this, I'd like to have a well-organized process of collecting
and documenting design ideas and trade-off argumentation, and hopefully
reach some consensus on what are good and bad ideas. This should also
serve to increase interoperability between the several pieces of
software that are being developed. Some of my ideas on how to shape

We could have a Git repository, containing all concepts and standards.
New ideas, amendments & so on can be exchanged like pull requests. We
may / may not also need a process to make actual design decisions, but
assigning one Git clone to be the "true" one might be too simplistic (I
don't want to have a dictator). As long as the Lightning dev community
is small, a "100% consensus" rule might still be workable though.

I'd like to make a distinction between concepts and standards. The idea
is that a concept is a non-trivial design decision; typically people can
have strong preference between different alternative, mutually
incompatible concepts. Standards are based on concepts, and fill in all
the trivial design decisions that have to be made to make different
pieces of software inter-operable. For concept choices, I made the
following template:


What do you think?


PS. Rusty suggested something like an RFC-like process for Lightning.
I'm not an expert on RFCs, and my proposal is probably a bit different
from the RFC process. I'm open to other ideas and I'd like to be
informed about why we should use an RFC-like process or something else.

More information about the Lightning-dev mailing list