Clarify Mandatory Field Length Requirements and Add Note on Low R Signatures in BOLT 11

11-payment-encoding.md

@@ -209,8 +209,9 @@ A writer:
     - MUST specify the most-preferred field first, followed by less-preferred fields, in order.
 
 A reader:
-  - MUST skip over unknown fields, OR an `f` field with unknown `version`, OR  `p`, `h` or
-  `n` fields that do NOT have `data_length`s of 52, 52 or 53, respectively.
+  - MUST skip over `f` fields that use an unknown `version`.
+  - MUST fail the payment if any mandatory field (`p`, `h`, `s`, `n`) does not have the correct length (52, 52, 52, 53).
+  - MUST fail the payment if neither a `d` field nor a `h` field is present, or if both are present.
   - if the `9` field contains unknown _odd_ bits that are non-zero:
     - MUST ignore the bit.
   - if the `9` field contains unknown _even_ bits that are non-zero:
@@ -237,19 +238,12 @@ A reader:
 
 The type-and-length format allows future extensions to be backward
 compatible. `data_length` is always a multiple of 5 bits, for easy
-encoding and decoding. Readers also ignore fields of different length,
-for fields that are expected may change.
-
-The `p` field supports the current 256-bit payment hash, but future
-specs could add a new variant of different length: in which case,
-writers could support both old and new variants, and old readers would
-ignore the variant not the correct length.
+encoding and decoding.
 
 The `d` field allows inline descriptions, but may be insufficient for
 complex orders. Thus, the `h` field allows a summary: though the method
 by which the description is served is as-yet unspecified and will
-probably be transport dependent. The `h` format could change in the future,
-by changing the length, so readers ignore it if it's not 256 bits.
+probably be transport dependent.
 
 The `m` field allows metadata to be attached to the payment. This supports
 applications where the recipient doesn't keep any context for the payment.
@@ -354,7 +348,7 @@ A payer:
       understands for payment.
   - MAY use the sequence of channels, specified by the `r` field, to route to the payee.
   - SHOULD consider the fee amount and payment timeout before initiating payment.
-  - SHOULD use the first `p` field that it did NOT skip as the payment hash.
+  - SHOULD use the first `p` field as the payment hash.
 
 A payee:
   - after the `timestamp` plus `expiry` has passed:
@@ -368,6 +362,7 @@ https://github.com/rustyrussell/lightning-payencode
 
 NB: all the following examples are signed with `priv_key`=`e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734`.
 All invoices contain a `payment_secret`=`1111111111111111111111111111111111111111111111111111111111111111` unless otherwise noted.
+Signatures are deterministic and generated using RFC6979 (using HMAC-SHA256). Note that even though using a `low R` would save 1 byte in the DER-encoded signature (by avoiding the need for a leading zero byte when the most significant bit is set), it is not enforced in this specification.
 
 > ### Please make a donation of any amount using payment_hash 0001020304050607080900010203040506070809000102030405060708090102 to me @03e7156ae33b0a208d0744199163177e909e80176e55d97a2f221ede0f934dd9ad
 > lnbc1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpl2pkx2ctnv5sxxmmwwd5kgetjypeh2ursdae8g6twvus8g6rfwvs8qun0dfjkxaq9qrsgq357wnc5r2ueh7ck6q93dj32dlqnls087fxdwk8qakdyafkq3yap9us6v52vjjsrvywa6rt52cm9r9zqt8r2t7mlcwspyetp5h2tztugp9lfyql