From 44c5fa1c7a42d5722d7be91c18c149e7f039e24a Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Tue, 24 Dec 2019 13:29:37 -0500 Subject: [PATCH 1/2] Resolve conflict between BOLT 4&9 re: var_onion_optin context BOLT 4 explicitly indicates var_onion_optin may appear in a BOLT 11 invoice, however, BOLT 9 only indicates it is available in init and node_announcement contextx. Resolve this conflict in favor of BOLT 4 as there doesn't seem to be much reason to *not* allow it in BOLT 11 invoices. --- 09-features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/09-features.md b/09-features.md index b05d83557..c0948c506 100644 --- a/09-features.md +++ b/09-features.md @@ -32,7 +32,7 @@ The Context column decodes as follows: | 3 | `initial_routing_sync` | Sending node needs a complete routing information dump | I | [BOLT #7][bolt07-sync] | | 4/5 | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel | IN | [BOLT #2][bolt02-open] | | 6/7 | `gossip_queries` | More sophisticated gossip control | IN | [BOLT #7][bolt07-query] | -| 8/9 | `var_onion_optin` | Requires/supports variable-length routing onion payloads | IN | [Routing Onion Specification][bolt04] | +| 8/9 | `var_onion_optin` | Requires/supports variable-length routing onion payloads | IN9 | [Routing Onion Specification][bolt04] | | 10/11 | `gossip_queries_ex` | Gossip queries can include additional information | IN | [BOLT #7][bolt07-query] | | 12/13| `option_static_remotekey` | Static key for remote output | IN | [BOLT #3](03-transactions.md) | | 14/15 | `payment_secret` | Node supports `payment_secret` field | IN9 | [Routing Onion Specification][bolt04] | From 5abee4d362b89cdd73f276032d14e88e295d32c3 Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Tue, 24 Dec 2019 13:45:30 -0500 Subject: [PATCH 2/2] Do not allow routing to a node with unkown feature bits set. This appears to have been an oversight in the flat features spec, and is somewhat implicitly relied on for several new feature bits - if var_onion_optin is set on a node_announcement (its not allowed on a channel_announcement), then trying to route through that node using the pre-tlv formt is somewhat nonsensical, and should be forbidden. --- 07-routing-gossip.md | 3 +++ 09-features.md | 6 ++++++ 2 files changed, 9 insertions(+) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index ab4ece066..6ae579d8a 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -323,6 +323,9 @@ any future fields appended to the end): - MUST NOT process the message further. - if `features` field contains _unknown even bits_: - SHOULD NOT connect to the node. + - Unless paying a [BOLT #11](11-payment-encoding.md) invoice which does not + have the same bit(s) set, MUST NOT attempt to send payments _to_ the node. + - MUST NOT route a payment _through_ the node. - SHOULD ignore the first `address descriptor` that does NOT match the types defined above. - if `addrlen` is insufficient to hold the address descriptors of the diff --git a/09-features.md b/09-features.md index c0948c506..70f1899a2 100644 --- a/09-features.md +++ b/09-features.md @@ -60,6 +60,12 @@ There is no _even_ bit for `initial_routing_sync`, as there would be little point: a local node can't determine if a remote node complies, and it must interpret the flag, as defined in the initial spec. +Note that for feature flags which are available in both the `node_announcement` +and [BOLT 11](11-payment-encoding.md) invoice contexts, the features as set in +the [BOLT 11](11-payment-encoding.md) invoice should override those set in the +`node_announcement`. This keeps things consistent with the unknown features +behavior as specified in [BOLT 7](07-routing-gossip.md#the-node_announcement-message). + ![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY")
This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).