📅 Original date posted:2018-01-15
📝 Original message:
Benjamin Mord <ben at mord.io> 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.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:48:30
in reply to nevent1q…ltzg
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:48:30Event JSON
{
"id": "0a919a96021177430f3140bb676033f799c85b40df228fdd3ac2713db9479432",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314910,
"kind": 1,
"tags": [
[
"e",
"5e266bbeea9ea7dd2a454375db884149cee20a05a82ac4d9a94351b1df7db2d8",
"",
"root"
],
[
"e",
"ee6e59171eb6867b77ea4296fcb43adfab08ba76cd7bc27d40ebc3baadab7e3e",
"",
"reply"
],
[
"p",
"d130dddcd486171bc7d87324949ff9f03e12d9f3441741929356952d22d980e1"
]
],
"content": "📅 Original date posted:2018-01-15\n📝 Original message:\nBenjamin Mord \u003cben at mord.io\u003e writes:\n\u003e One thing I find useful in RFCs is a brief discussion about the meaning of\n\u003e terms like MUST, SHOULD, MAY, etc.. as used in the subsequent protocol\n\u003e definition.\n\nHi Benjamin!\n\n Weird, I always find them kinda useless. RFC2119 pretty much\ncovers it.\n\n\u003e When a BOLT says that a lightning node MUST do some X, what does that mean\n\u003e exactly? I'm thinking it means we should stigmatize it as \"non-compliant\"\n\u003e with protocol consensus as documented in BOLTs, whenever we discuss the\n\u003e implementation. I think violation of a MUST should be considered hostile. I\n\u003e think a MUST encourages nodes to fail a channel or connection upon\n\u003e observing a violation of that MUST, and even to take\n\u003e implementation-specific defensive measures as deemed appropriate by\n\u003e implementers (so long as they have cryptographic evidence that the\n\u003e violation is not forged). But in no way does a MUST assure implementers\n\u003e that they may assume this MUST will be respected by remote nodes, as it is\n\u003e not the purpose of MUST to convey that cryptographic safeguards or such\n\u003e elsewhere in the protocol design have arranged to force adherence..\n\nThis is why we attempt to divide requirements into sender and receiver.\nFor example, this is an absolute unchangable protocol requirement:\n\n Sender MUST set X.\n Receiver MUST close channel if X is not set.\n\nor:\n Sender MUST set X.\n If X is set, Receiver MUST ...\n\nThe latter implies that future versions of the spec may have senders not\nsetting X.\n\nI thought about writing a BOLT on how to write BOLTs, but it would\ndoubtless come across as inane navel-gazing.\n\nNote also that the spec does not live up to this property in all places,\nbut we bugfix where we find that.\n\nCheers,\nRusty.",
"sig": "f5be4594f4d8ed64c8b47833ef9b3838e7cf5903f9dafb8dbd11d13bc7ce329c161a3ef4212c2daf596abf39c4a80678c4d4b5b356e4c6cdc311041f569dbdd6"
}