Benjamin Mord [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-16 📝 Original message: With all due respect to ...
📅 Original date posted:2018-01-16
📝 Original message:
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 <rusty at rustcorp.com.au>
wrote:
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180116/9a13eedb/attachment.html>;
📝 Original message:
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 <rusty at rustcorp.com.au>
wrote:
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180116/9a13eedb/attachment.html>;