From rusty at rustcorp.com.au Wed Sep 23 04:40:53 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 23 Sep 2015 14:10:53 +0930 Subject: [Lightning-dev] Standardization In-Reply-To: <1442857428.4657.35.camel@hppg6.kloosterkade> References: <87si7eiehg.fsf@rustcorp.com.au> <87h9ntifwf.fsf@rustcorp.com.au> <877fopi4un.fsf@rustcorp.com.au> <20150829074239.GA15643@navy> <874mjgqne2.fsf@rustcorp.com.au> <87si6ybnmm.fsf@rustcorp.com.au> <87twrd1i1r.fsf@rustcorp.com.au> <1442857428.4657.35.camel@hppg6.kloosterkade> Message-ID: <87d1x94uju.fsf@rustcorp.com.au> CJP writes: > 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. Indeed. And it was great to meet you, too! > 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. Yeah. I feel torn between the desire to code, and the desire to write an RFC so we can argue properly. > 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 > this: Yes, it would also help newcomers get up to speed with ideas we've already thrown around on-list. Preferably avoid the bitcoin problem where you need to ask gmaxwell for a reference to an ancient bitcointalk post where a solution was previously presented. > 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. A wiki? This seems closer to what we want, at least for now. > 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: > > https://gist.github.com/anonymous/51631fe56f1f83e4af0a > > What do you think? I love separating concepts and standards. There are plenty of interesting concepts which may eventually percolate into standards once we get some kind of consensus; and I don't want to lose track of them all because they're not an immediate priority. > 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. RFCs are good for when you want to nail down proposal details. You can quote them in emails, code comments, and ideally implement the protocol off them. For example, an RFC describing the exact transactions used in lightning, or one describing the inter-node protocol. New ones appear over time as the protocols get extended. They're best when you have at least two independent implementations to make sure they're sane. They're not so good with concepts, or brainstorming future stuff. But that stuff, too, is vital. Cheers, Rusty.