blip-0037: Bolt 12 encoded wallet node_id

[t-bast]

Bolt 12 introduces a new sciddir_or_pubkey field that can be used to identify the introduction node of a blinded path. This is primarily used to reduce the size of encoded offers, but this encoding trick can be extended to carry more information about the node it's referencing. We introduce an additional prefix to this field to tag node_ids that belong to mobile wallets.

When relaying a payment or an onion message, wallet providers usually want to offer additional features to mobile wallets. Encoding the information that the next node is a mobile wallet directly inside the onion payload makes it easy for the relaying node to efficiently insert additional steps before relaying (such as trying to wake-up the wallet if it is offline) without negatively impacting relay to normal nodes.

[TheBlueMatt]

It seems weird that we add an encoding for the introduction node in a bLIP? Maybe I'm misunderstanding something but don't all nodes need to support reading such nodes in order to send to offers generated with such introductions?

[t-bast]

It seems weird that we add an encoding for the introduction node in a bLIP?

This isn't used for the introduction node, we're only using this in encrypted_recipient_data.next_node_id. But in the BOLTs, sciddir_or_pubkey was added to reference the introduction node, so we mention that we're re-using this same encoding elsewhere.

I could probably add a requirement to explain that you MUST NOT use this new encoding case (0x04... / 0x05...) to reference introduction nodes, but it wouldn't make sense anyway, because a wallet will never be found in the public graph so it will never use itself as the introduction node of a blinded path, it will always use its LSP or another public node?

[TheBlueMatt]

This isn't used for the introduction node, we're only using this in encrypted_recipient_data.next_node_id.

Ah, okay, that's what I thought, that makes more sense. Was just confused by the wording!