From ben at mord.io Tue Jan 16 14:37:25 2018 From: ben at mord.io (Benjamin Mord) Date: Tue, 16 Jan 2018 09:37:25 -0500 Subject: [Lightning-dev] BOLTs and meaning of "MUST" in potentially adversarial contexts In-Reply-To: <87inc2isd8.fsf@rustcorp.com.au> References: <87inc2isd8.fsf@rustcorp.com.au> Message-ID: With all due respect to Bradner, RFC 2119 (written in 1997) is harmful to lightning and to cryptocurrency protocols more broadly. As was the prevailing mindset at the time, RFC 2119 is for a world of good guys and (if we're feeling diligent) bad guys, where good guys try to communicate despite presence of bad guys who would spoil the fun. The intended endpoint of your communication would never itself be a bad guy - why would you knowingly communicate with a bad guy? But Satoshi was less naive, and considered every node as pursuing self interest alone. Rather than good guys and bad guys, we have lots of selfish guys playing the game (and also selfish guys trying to destroy the game). The lightning concept itself embraces this idea also at the very abstract level, so the navel-gazing we MUST take on now is simply the task of carrying that philosophy through into the byte-level details and how we sell those details to programmers. RFC 2119 is harmful both for what it says and what it does not say. The harm in what it says is illustrated by this example - one of several (emphasis mine): "In particular, they MUST only be used where it is actually required for interoperation or to limit behavior *which has* * potential for causing harm* (e.g., limiting retransmisssions)" (Another example is where it limits what sort of behavior implementers ought to prepare for in their peers.) When someone violates a MUST, what shall we do? Throw them in jail? Say nasty things behind their backs? No, cryptocurrency protocol specifications are 100% advisory - a cleverly devised system where we can sincerely sell the implementer that it will be in their individual best interest to do highly specific things which have been arranged to also accrue to the collective benefit. Use of MUST (in RFC 2119 sense) invites lazy thought in the protocol design itself, where details need not be sold as beneficial to individuals. We should say, there is no RFC 2119 MUST - there is only self interest. Another way to view it: a protocol spec attempts to program the programmers. But unlike computers, people don't always do what you ask simply because you asked. Every detail must therefore be sold, as there is no other source of authority at our disposal. RFC 2119 assumes an intrinsic authority that simply does not exist here. We must arrange for that to be OK - not only at an abstract level, but at a detailed one also. On Mon, Jan 15, 2018 at 7:01 PM, Rusty Russell wrote: > Benjamin Mord writes: > > One thing I find useful in RFCs is a brief discussion about the meaning > of > > terms like MUST, SHOULD, MAY, etc.. as used in the subsequent protocol > > definition. > > Hi Benjamin! > > Weird, I always find them kinda useless. RFC2119 pretty much > covers it. > > > When a BOLT says that a lightning node MUST do some X, what does that > mean > > exactly? I'm thinking it means we should stigmatize it as "non-compliant" > > with protocol consensus as documented in BOLTs, whenever we discuss the > > implementation. I think violation of a MUST should be considered > hostile. I > > think a MUST encourages nodes to fail a channel or connection upon > > observing a violation of that MUST, and even to take > > implementation-specific defensive measures as deemed appropriate by > > implementers (so long as they have cryptographic evidence that the > > violation is not forged). But in no way does a MUST assure implementers > > that they may assume this MUST will be respected by remote nodes, as it > is > > not the purpose of MUST to convey that cryptographic safeguards or such > > elsewhere in the protocol design have arranged to force adherence.. > > This is why we attempt to divide requirements into sender and receiver. > For example, this is an absolute unchangable protocol requirement: > > Sender MUST set X. > Receiver MUST close channel if X is not set. > > or: > Sender MUST set X. > If X is set, Receiver MUST ... > > The latter implies that future versions of the spec may have senders not > setting X. > > I thought about writing a BOLT on how to write BOLTs, but it would > doubtless come across as inane navel-gazing. > > Note also that the spec does not live up to this property in all places, > but we bugfix where we find that. > > Cheers, > Rusty. > -------------- next part -------------- An HTML attachment was scrubbed... URL: