Clarification on the occurences of TLV records with the same type #777
Conversation
01-messaging.md
Outdated
| The main reason for unique occurrences of some TLV record type relates back the | ||
| fact that if a decoder doesn't recognize a field, it can't be certain whether | ||
| there should only be one, or if multiple are permitted. Asserting this would | ||
| require some knowledge of what the field encodes or a scheme from which it can | ||
| be inferred knowing only the type, e.g. (a silly example) only prime types can | ||
| have multiple records. The first defeats the purpose of the proposal, and the | ||
| latter is cumbersome in practice and would further fragment the type space | ||
| beyond the existing even/odd rule. | ||
|
|
||
| A minor reasons for strictly-unique types is that permitting multiple of the | ||
| same type is less efficient on the wire due to the overhead of redundant | ||
| type-length pairs. It is also less efficient when allocating memory for the | ||
| decoded objects, e.g. one can't allocate the exact size of a vector upfront and | ||
| will incur more copying overhead when appending each item individually. | ||
|
|
There was a problem hiding this comment.
I would remove these paragraphs entirely, they clutter the spec (IMHO).
There was a problem hiding this comment.
Well, I personally find this explanation (when was given it) quire useful; it helps understanding the reasons of particular design. The spec is not that large yet, so having two more paragraphs adding clarity is good. But I am fine to remove them LN community thinks they are unnecessary.
There was a problem hiding this comment.
I'll let @cfromknecht chime in, but I think the general feeling when we discussed this during a spec meeting was to remove or condense these paragraphs.
dr-orlovsky
force-pushed
the
bolt1-tlvuniqrec
branch
from
f0c2f3a
to
6299890
Compare
|
The paragraph, according to @t-bast critics, is removed. Also, have done a rebase onto master |
| @@ -135,7 +135,8 @@ according to the message-specific format determined by `type`. | |||
| ### Requirements | |||
|
|
|||
| The sending node: | |||
| - MUST order `tlv_record`s in a `tlv_stream` by monotonically-increasing `type`. | |||
| - MUST order `tlv_record`s in a `tlv_stream` by strictly-increasing `type`, | |||
There was a problem hiding this comment.
strictly-increasing is not the same as "unique", which this sentence implies with "i.e."
There was a problem hiding this comment.
Strictly increasing does imply unique, doesn't it? (the reverse isn't true)
There was a problem hiding this comment.
Below we have:
The strict monotonicity constraint ensures that all
types are unique and can at most once. Fields that map to complex objects, e.g. vectors, maps, or appear at most once
There was a problem hiding this comment.
indeed, but "i.e." implies that they are equivalent in that, as merriam-webster says "it introduces a rewording or a clarification". An implication is not a rewording.
There was a problem hiding this comment.
Is your suggestion to change i.e. MUST not produce to hence MUST not produce?
If so, @dr-orlovsky can you apply this small change and we can merge?
There was a problem hiding this comment.
yes, that is a great idea.
|
ACK |
dr-orlovsky
force-pushed
the
bolt1-tlvuniqrec
branch
from
6299890
to
a358828
Compare
Closes #776 as discussed within the issue