What is Nostr?
Benjamin Mord [ARCHIVE] /
npub16yc…jvwy
2023-06-09 12:48:30
in reply to nevent1q…qhxc

Benjamin Mord [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-11 📝 Original message: One thing I find useful ...

📅 Original date posted:2018-01-11
📝 Original message:
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. But in the traditional approach to protocol design we first
assume cooperative nodes, and then later attempt to retrofit security when
we are surprised (yet again) to find not all nodes are operating in good
faith. Initial definition of "MUST" in RFCs thus implicitly presumes good
faith, inadvertently inviting implementers to lower their guard. But of
course, integrity despite presence of adversarial nodes is an explicit
design goal of the lightning network.

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

Does that sound right? Is it worth stating explicitly somewhere, along with
definitions of SHOULD, MAY etc? Sorry if these definitions are already
stated someplace that I overlooked.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180111/36714035/attachment.html>;
Author Public Key
npub16ycdmhx5sct3h37cwvjff8le7qlp9k0ngst5ry5n262j6gkesrssskjvwy