Published on: 2018-01-18T11:12:38+00:00
The use of RFC2119 in protocol design is discussed in the context. The author argues that the use of MUST in RFC2119 can lead to lazy thought in protocol design, where the details are not sold as beneficial to individuals. However, it is clarified that the idea behind RFC2119 is that implementations must follow MUSTs, but there is no enforcement by vendors or any governing body. The enforcement comes from the community at large, where an implementation that does not follow a MUST may face financial harm or not be purchased by network operators. Private implementations are not bound by these rules, but if they become significant enough, they go through the standardization process before becoming an issue within the community.The RFC 2119 protocol, written in 1997, is seen as harmful to lightning and cryptocurrency protocols as it assumes a world of good guys and bad guys. However, the lightning concept embraces the idea that every node is pursuing self-interest alone. This philosophy needs to be carried through into the byte-level details and how those details are sold to programmers. Cryptocurrency protocol specifications are advisory, so there is no RFC 2119 MUST - only self-interest. Therefore, every detail must be sold, as there is no other source of authority at our disposal. Rusty Russell suggests dividing requirements into sender and receiver, with the former setting X and the latter closing the channel or performing another action based on whether X is set or not. Bugs are fixed in the spec where found.In RFCs, it is useful to have a brief discussion about the meaning of terms such as MUST, SHOULD, and MAY. However, the traditional approach to protocol design assumes cooperative nodes and later tries to retrofit security when it is discovered that not all nodes are operating in good faith. The initial definition of MUST in RFCs presumes good faith and inadvertently invites implementers to lower their guard. However, integrity despite adversarial nodes is an explicit design goal of the lightning network. When a BOLT states that a lightning node MUST do something, it should be stigmatized as "non-compliant" with protocol consensus as documented in BOLTs whenever discussed. Violation of a MUST should be considered hostile and it encourages nodes to fail a channel or connection upon observing a violation of that MUST. Implementers may also take implementation-specific defensive measures deemed appropriate, provided they have cryptographic evidence that the violation is not forged. However, a MUST does not assure implementers that they may assume this MUST will be respected by remote nodes since it is not the purpose of MUST to convey that cryptographic safeguards or such elsewhere in the protocol design have arranged to force adherence. It may be worth explicitly stating somewhere along with definitions of SHOULD and MAY.
Updated on: 2023-07-31T19:38:41.503649+00:00