blip-xx: BOLT 11 Invoice Blinded Path Tagged Field by ellemouton · Pull Request #1 · ellemouton/blips

ellemouton · 2024-06-20T22:04:41Z

No description provided.

ziggie1984

I like this idea of using a bLIP for the optional Blinded Path Feature for BOLT 11 invoices, at until BOLT12 is widely adopted.

ziggie1984 · 2024-06-21T21:22:27Z

+   * [`2*byte`:`cipher_text_length`]
+   * [`cipher_text_length*byte`:`cipher_text`]
+
+The `blinded_node_pubkey` of the first `blinded_hop` in a `blinded_payinfo` is


Why do we need to do it this way, meaning that although the field is called blinded, we use the real pubkey ?

it's just for the very first hop (the intro node) and is done as a way to save space. Else we would need a whole separate 33 byte field for the intro node pub key. The intro node's blinded pub key is never used.

I can add this explanation though if it is unclear 👍

The other option is of course just special casing the first hop's encoding and letting it only contain cipher text but I opted for a simpler encoding here

I think carving out the intro node's real key into its own field in the root blinded_payinfo structure is a better way to organize this so that we have full homogeneity within the blinded_hop vector. I don't think space is saved either way since any data that we include in the main message wouldn't be included in blinded_hops.

Having exceptions, asterisks, or other caveats makes the spec harder to implement correctly.

I don't think space is saved either way

space saved in the invoice itself though :) ie trying to make it still fit in a qr code.

but yeah - can change this to be more explicit if enough people agree. Just seems strange to include the intro node's blinded key when that is never used

No I mean why not omit the intro node's "hop" from blinded_hops completely, and then just include the intro node's ciphertext in its own field?

No I mean why not omit the intro node's "hop" from blinded_hops completely, and then just include the intro node's ciphertext in its own field?

IIUC it's done this way to mirror the Offers encoding.

ah ok i see what you mean now, like a separate intro_hop and intro_encrypted_data.

The only arg i see against this is that then the num_hops isnt really the true number of hops. But yeah happy to change this. I think what i'll do is leave it as is for now and then will add this note to the "discussions/questions" section for discussion.

ziggie1984 · 2024-06-21T21:39:35Z

+1. subtype: `blinded_hop`
+2. data:
+   * [`33*byte`:`blinded_node_pubkey`]
+   * [`2*byte`:`cipher_text_length`]


can we restrict the cipher_text length field to 2 bytes because we have the data_length limit anyways ? Normally the tlv length values are [bigsize: length] ?

Unless we make a custom carve out here, it'll be the BigSize encoding. Either way though, if the payload is under 253 bytes, then we can encode with only a single byte.

originally I was just mimicking what is used for onionmsg_hop defined in the Offers spec

But I think you are right in that bigsize is better for this especially since the estimated size for this is around 79 bytes (see calc below) and so with bigsize, we then dont need that 2 byte overhead in most cases 👍

ziggie1984 · 2024-06-21T21:44:04Z

+    * 8 byte `htlc_minimum_msat`
+- `allowed_features`: optional
+
+If we assume that the `allowed_features` vector is not set, then this comes to 


Maybe add a reference to the BOLT04 spec, where there is a reference that the feature vector is currently not used ?

ziggie1984 · 2024-06-21T21:44:52Z

+- `path_id`: let's assume that this is 32 bytes like the existing payment 
+   address.
+- `payment_constraints`:
+    * 4 byte `max_cltv_expiry`


still unsure why the receiver needs the payment_contraint data, it created the invoice in the first place ?

so i think the idea here is so that the recipient doesnt need to go store this expiry as a separate thing. It basically just sends this message to itself. Got the idea from the example used in the proposal doc

defs an open discussion though. Noted in the missing pieces part here: lightningnetwork/lnd#8752 (comment)

ziggie1984 · 2024-06-21T21:46:12Z

+
+The total number of bytes required for a single `blinded_hop` is:
+
+    = 33+2+len(cipher_text)


don't we need to add the padding value here or is it already included in the cipher_text.

see the ##### Cipher Text Size Estimation section above - the cipher text will already contain the padding

ziggie1984 · 2024-06-21T21:50:56Z

+- Does it make sense to add an experimental tagged field range for BOLT 11 in 
+  the bLIP2 spec or would this be over-kill since BOLT 11 is in any-case being 
+  phased out?
+- Would a new experimental feature bit (in the `I` context) make sense here so 


I think this is a good idea, adding a new feature bit for the bolt11 blinded path case.

Seconded. Fail fast.

Yeah, it should be a required feature bit.

ziggie1984 · 2024-06-21T21:54:35Z

+  the bLIP2 spec or would this be over-kill since BOLT 11 is in any-case being 
+  phased out?
+- Would a new experimental feature bit (in the `I` context) make sense here so 
+  that the reader can fail fast instead of attempting to find a node that does 


Should we include some test-vectors for the invoice with a blinded path, I think we have them ready in the LND PR I think ?

ah indeed - good idea. Will add

ProofOfKeags · 2024-06-24T20:57:58Z

+- MUST not contain the `s` field type since a payment address in the context of
+  blinded payments does not make sense since the recipient is able to use the
+  `path_id` in the `encrypted_recipient_data` for the same purpose.
+- SHOULD sign the invoice with a private key that is not the same as their 


Maybe a dumb question but what's the point of signing the data if we don't have a key to validate against?

well we do have the random key in the "destination" field. so we can atleast verify that "invoice hasnt been changed since original creation", ie, no-one was able to take the invoice that looks like it is coming from you but then quickly sneak their own blinded paths to themselves in it.

Perhaps could do something fancier like: the sig is the n-of-n musig2 combo created by combining sigs from all the final blinded pubkeys in the n blinded paths the invoice contains ...?

Hypothetically you could just craft an entirely new invoice though and sign it with a random privkey. So maybe it guards against a super naive tampering but even a modestly intentional tampering is still possible, no? Maybe I'm not understanding completely (I haven't read BOLT11 end-to-end).

Yeah this came up in the spec meeting the other week. I think some plan to use this key in a sort of "address book" entry. It doesn't need to be your actual node's public key, and you can rotate it, but it can be useful as a pseudonym on the network.

The signature lets us verify the integrity of the invoice (nothing has been tampered with). As for authentication, when dealing with hop hints, it's already the case today that the public key included won't be in the public graph, so you don't have a way to verify that the node actually "exists".

ProofOfKeags · 2024-06-24T21:02:04Z

+   * [`2*byte`:`cipher_text_length`]
+   * [`cipher_text_length*byte`:`cipher_text`]
+
+The `blinded_node_pubkey` of the first `blinded_hop` in a `blinded_payinfo` is


I think carving out the intro node's real key into its own field in the root blinded_payinfo structure is a better way to organize this so that we have full homogeneity within the blinded_hop vector. I don't think space is saved either way since any data that we include in the main message wouldn't be included in blinded_hops.

Having exceptions, asterisks, or other caveats makes the spec harder to implement correctly.

ProofOfKeags · 2024-06-24T21:12:35Z

+This proposal is a temporary measure that will allow users to start making use
+of blinded paths in the context of payments and thereby taking advantage of the 
+potential privacy and payment success rate benefits that in they will in theory 
+provide. Once the Offers protocol along with its new invoice format has been 


link Offers

cool can add - tbh my assumption was always that if you've linked something once then you dont need to link it again so as not to litter the doc with blue links? but happy to update - just had this assumption

ProofOfKeags · 2024-06-24T21:16:41Z

+- Does it make sense to add an experimental tagged field range for BOLT 11 in 
+  the bLIP2 spec or would this be over-kill since BOLT 11 is in any-case being 
+  phased out?
+- Would a new experimental feature bit (in the `I` context) make sense here so 


Seconded. Fail fast.

saubyk · 2024-06-25T03:12:28Z

+useful tool for privacy and potentially more reliable payment delivery and so 
+this document proposes a carve-out to the existing [BOLT 11] invoice format so 
+that advantage can be taken of the blinded paths protocol in the context of 
+payments in a sooner time frame. This will be done by adding a new tagged-field 


nit: in a quick time frame

saubyk · 2024-06-25T03:20:32Z

+
+Another soft maximum value to keep in mind is the maximum number of bytes that
+can fit into a [QR code][qr] which is 2,953 bytes. This is a soft maximum 
+because this only applies if the invoice is in fact being transmitted via QR 


Question: How is this limit being used in this proposal? Is it enforced in anyway to limit the data which can be included?

Given that this constraint is applicable only if the invoice is being displayed as a QR code, would it make sense to add an explicit logic to indicate modality of invoice transmission and enforce the limits based on that?

How is this limit being used in this proposal?

It's not. It's just informative. This is purely for implementation help.

add an explicit logic to indicate modality of invoice transmission and enforce the limits based on that

That is really up to the implementation I'd say

ellemouton

Thanks for taking a look y'all! 🙏

Pushed up some changes. Gonna post this to delving now to get the broader discussion going. I'll add test vectors for the actual bLIP PR 👍

ellemouton · 2024-06-25T21:34:54Z

+1. subtype: `blinded_hop`
+2. data:
+   * [`33*byte`:`blinded_node_pubkey`]
+   * [`2*byte`:`cipher_text_length`]


originally I was just mimicking what is used for onionmsg_hop defined in the Offers spec

But I think you are right in that bigsize is better for this especially since the estimated size for this is around 79 bytes (see calc below) and so with bigsize, we then dont need that 2 byte overhead in most cases 👍

ellemouton · 2024-06-25T23:02:56Z

+   * [`2*byte`:`cipher_text_length`]
+   * [`cipher_text_length*byte`:`cipher_text`]
+
+The `blinded_node_pubkey` of the first `blinded_hop` in a `blinded_payinfo` is


ah ok i see what you mean now, like a separate intro_hop and intro_encrypted_data.

The only arg i see against this is that then the num_hops isnt really the true number of hops. But yeah happy to change this. I think what i'll do is leave it as is for now and then will add this note to the "discussions/questions" section for discussion.

ellemouton · 2024-06-25T23:17:06Z

+    * 8 byte `htlc_minimum_msat`
+- `allowed_features`: optional
+
+If we assume that the `allowed_features` vector is not set, then this comes to 


ellemouton · 2024-06-25T23:18:40Z

+- `path_id`: let's assume that this is 32 bytes like the existing payment 
+   address.
+- `payment_constraints`:
+    * 4 byte `max_cltv_expiry`


defs an open discussion though. Noted in the missing pieces part here: lightningnetwork/lnd#8752 (comment)

ellemouton · 2024-06-25T23:25:31Z

+
+The total number of bytes required for a single `blinded_hop` is:
+
+    = 33+2+len(cipher_text)


see the ##### Cipher Text Size Estimation section above - the cipher text will already contain the padding

ellemouton · 2024-06-25T23:27:51Z

+This proposal is a temporary measure that will allow users to start making use
+of blinded paths in the context of payments and thereby taking advantage of the 
+potential privacy and payment success rate benefits that in they will in theory 
+provide. Once the Offers protocol along with its new invoice format has been 


cool can add - tbh my assumption was always that if you've linked something once then you dont need to link it again so as not to litter the doc with blue links? but happy to update - just had this assumption

ellemouton · 2024-07-08T11:18:55Z

closing here & opening on the upstream repo - let's continue discussion their 🙏

ziggie1984 reviewed Jun 21, 2024

View reviewed changes

ProofOfKeags reviewed Jun 24, 2024

View reviewed changes

ellemouton mentioned this pull request Jun 24, 2024

[1/4] Route Blinding Receives: Groundwork lightningnetwork/lnd#8752

Merged

saubyk suggested changes Jun 25, 2024

View reviewed changes

ellemouton force-pushed the bolt11-blinded-path branch from 57b87c1 to 8c3f40a Compare June 25, 2024 23:55

ellemouton commented Jun 25, 2024

View reviewed changes

ellemouton force-pushed the bolt11-blinded-path branch from 8c3f40a to 4803947 Compare June 26, 2024 00:02

blip-39: BOLT 11 Invoice Blinded Path Tagged Field

d4e6787

ellemouton force-pushed the bolt11-blinded-path branch from 98ea720 to d4e6787 Compare July 8, 2024 11:18

ellemouton closed this Jul 8, 2024


		The total number of bytes required for a single `blinded_hop` is:

		= 33+2+len(cipher_text)

Conversation

ellemouton commented Jun 20, 2024

Uh oh!

ziggie1984 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!