Add test for offers #6

thomash-acinq · 2022-07-20T15:41:03Z

Adds examples of offers, invoice requests and invoices.
Uses mandatory blinded paths (#4) and full keys (#5).

Route blinding allows a recipient to provide a blinded route to potential payers. Each node_id in the route is tweaked, and dummy hops may be included. This is an alternative to rendezvous to preserve recipient anonymity. It has a different set of trade-offs: onions are re-usable, but the privacy guarantees are a bit weaker and require more work (e.g. when handling errors).

These use onion encoding for simple one-way messaging: there are no error returns. However, every onion uses route blinding *even if it doesn't need to*. You can prove what path was used to reach you by including `path_id` in the encrypted_data_tlv. Note that this doesn't actually define the payload we're transporting: that's explictly defined to be payloads in the 64-255 range. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

It's not really a gossip message. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Feedback from t-bast and joostjager. - onion_msgpayload encrypted_data_tlv is type 4, not 10. - enctlv in path is now called encrypted_recipient_data which is consistent. - Removed setting of onionmsg feature in invoices. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

It's far easier to validate these on parsing than to hand-validate them elsewhere. I didn't turn `alias` or `error` into this, though they're similar (`alias` can have a nul terminator). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

A BOLT11 "invoice" has proven too low-level for human use in many scenarios. Efforts like lnurl have covered the gap, but integrating some of such higher layers into the lightning protocol itself has many advantages. This draft defines three new things: 1. A new invoice format. I know, this is painful, but it maps almost 1:1 to the current format (though signatures are very different), is easier to implement, and easier to send via the lightning network itself. 2. Formats for an "offer", which for all intents and purposes serves as the new, persistent invoice for users. It can also be a "send_invoice" offer, which is an offer to send money (refund, withdrawl). 3. Format for an "invoice_request": this is a message sent via the lightning network itself to receive the real invoice. I need to thank everyone who gave detailed feedback, particularly: 1. Thomas H of ACINQ (https://github.com/thomash-acinq) 2. Joost Jager https://github.com/joostjager 3. Anon https://github.com/animatedbarber 4. Aditya Sharma https://github.com/adi2011 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…voice_request compulsory We can ask the vendor to discard the previous invoice in the case of stuck payments: this discarded invoice gets mirrored into the new invoice, so if they actually don't do it and take both payments we can prove it. We need a signature using payer_key here, otherwise someone else could cancel our invoice. We previously only needed that signature for recurrence; now we rename it and make it always present for simplicity. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

It was pointed out that often low-end camera resolutions can be limited, so I thought hard about how to shrink offers. This is by far the largest field, and does not seem required (the invoice, of course, is signed). It weakens the case to omit the bech32m checksum though. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Rene Pickhardt points out that this improves payment success, and it makes perfect sense. It's an odd field, since it's harmless to ignore and/or not implement. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

It's spelled "payer_note" but it's *pronounced* "chicken taunt"! Again, it's an odd field, since it's harmless to ignore and/or not implement. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

@t-bast

At the recommendation of @t-bast, I'm stripping recurrence from the initial version of the spec. This can be re-added later (possibly with changes) once the rest has been agreed on. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

1. Make it clear that when we say "signature TLV" we are referring to "signature TLV elements" between 240 and 1000 (i.e. the unsigned parts!) 2. Rename payer_signature field in invoices to signature; though the key is different (payer_key vs node_id) it's otherwise identical, and having two names for the same field number (240) is wrong.[1] 3. Reorder TLV fields into ascending order. 4. `min_final_cltv_expiry` cannot be > 64k; make it tu16.[2] 5. Omit gratuitous `num` counter in `fallbacks`.[3] Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> [1] Compat break. c-lighting will continue to use the old fieldname (which appears in the signature tag) for now, but accept both. [2] Not a compat break, unless you tried to put > 64k in there. [3] Only a small compat break because c-lightning doesn't create them yet.

The c-lightning tooling doesn't hand this yet, but we can fix that. Suggested-by: ThomasH Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Nothing earthshattering, but some typos and more explicit requirements for the `chain` field. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

@t-bast

Bastien points out that a single value which applies across all hops in the path is less revealing than per-hop information, and it's simpler. In practice, it can be argued that any extra cost would be an issue for the recipient (they would accept less, for privacy) if it turns out to be signficant. Also makes the `blinded_capacities` language match. Suggested-by: @t-bast Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

@bluematt

…nels. Suggested-by: @bluematt Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Use " not ` for string literals. And remove merkle test which used now-removed fields. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

You're either making up the node_id anyway, or you don't need to blind it. Saves some space. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

The reader can do it, and this avoids having to separately specify the `first_node_id`. Also clarify when using the path is mandatory. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

rustyrussell

Thanks for doing these! Proved useful to make sure we're in sync already!

rustyrussell · 2022-08-03T03:02:15Z

bolt12/offer-test.json

+[
+    {
+	"comment": "Minimal offer for tips",
+        "node key": "48c6e5fcf499f50436f54c3b3edecdb0cb5961ca29d74bea5ab764828f08bf47",


I get "024ff5317f051c7f6eac0266c5cceaeb6c5775a940fab9854e47bfebf6bc7a0407"?

This seems OK, but node key is completely different?

$ ./devtools/bolt12-cli --allow-deprecated-apis=false decode lno1pg9k66twd9kkzmpqw35hq83pqf8l2vtlq5w87m4vqfnvtn82adk9wadfgratnp2wg7l7ha4u0gzqw description: minimal tip node_id: 024ff5317f051c7f6eac0266c5cceaeb6c5775a940fab9854e47bfebf6bc7a0407 offer_id: d281dad93b431939cad48471219735db71224fd2b323670c2f0106deea317f39

rustyrussell · 2022-08-03T03:36:17Z

bolt12/offer-test.json

@@ -6,7 +6,7 @@
        "preimage": "317d1fd8fec5f3ea23044983c2ba2a8043395b2a0790a815c9b12719aa5f1516",
 	"offer": "lno1pg9k66twd9kkzmpqw35hq83pqf8l2vtlq5w87m4vqfnvtn82adk9wadfgratnp2wg7l7ha4u0gzqw",
        "request": "lnr1qvsxlc5vp2m0rvmjcxn2y34wv0m5lyc7sdj7zksgn35dvxgqqqqqqqqyyrfgrkke8dp3jww26jz8zgvhxhdhzgj062ejxecv9uqsdhh2x9lnjzqrkudsqf3qrm6y88mr3y2du7fzqjpamgedldayx8nenfwwtfmy877hpvs33e80qszhudm9rdk99qpnzktv6emdwq3gda2l77c6av7nn542sl3uhzq5yau26508s7n0mf3ztpnwr6f8vlxhjrlhc34w6sehs9jwydpxhxnws",
-        "invoice": "lni1qvsxlc5vp2m0rvmjcxn2y34wv0m5lyc7sdj7zksgn35dvxgqqqqqqqqyyrfgrkke8dp3jww26jz8zgvhxhdhzgj062ejxecv9uqsdhh2x9lnjzqrkudsqzstd45ku6tdv9kzqarfwqg8sqj075ch7pgu0ah2cqnxchxw46mv2a66js86hxz5u3ala0mtc7syqupyrp8cxgf355un0gqnfhgqtnde9xqaazd4fcsrd5khlm4rns5v4aqpqd7aj6ja7pmk34s4llfjeju5y2lkuegn2dvjvnktkqvkxz05qvdjgqqjhfax8gmt6fgfunnhj99m3xk60auwvys7qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpdcmqqqqqqqqrcssynl4x9ls28rld6kqyek9en4wkmzhwk55p74es48y00lt76785pq8ycspaazrna3cj9x70y3qfq7a5vklk7jrreue5h895ajrl0tskggcun3gq33ds9tg9gsgtlj8vuulq6aca20u59mx5xzdg84pksgxgnahfamrsnnup8ck4lpwqgqpduzqrvfdar6jwu6c66w93stjn3qute7tgser2geyyadl0p5u0t4p08523c2tk9jlj9l2j5q47qdpta0rqtndwwdsqdfajpskxkrfrcqk4jc"
+        "invoice": "lni1qvsxlc5vp2m0rvmjcxn2y34wv0m5lyc7sdj7zksgn35dvxgqqqqqqqqyyrfgrkke8dp3jww26jz8zgvhxhdhzgj062ejxecv9uqsdhh2x9lnjzqrkudsqzstd45ku6tdv9kzqarfwqg8sqj075ch7pgu0ah2cqnxchxw46mv2a66js86hxz5u3ala0mtc7syqupdypsecj08jzgq82kzfmd8ncs9mufkaea9dr305na9vccycmjmlfspqvxsr2nmet6yjwzmjtrmqspxnyt9wl9jv46ep5t49amw3xpj82hk6qqjy0yn6ww6ektzyys7qrm6zcul88r27ysuqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpdcmqqqqq83pqf8l2vtlq5w87m4vqfnvtn82adk9wadfgratnp2wg7l7ha4u0gzqwf3qrm6y88mr3y2du7fzqjpamgedldayx8nenfwwtfmy877hpvs33e8zsprzmlnns23qshlyweee7p4m365legtkdgvy6s02rdqsv38mwnmk8p88cz03dt7zuqsqzmcyqvpkh2g4088w2xu7uvu6zvsxwrh2vgvppgnmf0vyqhqwqv6w8lgeulalcq6xznps7gw9h0rtfpwxftz4l7j2nnuzj3gpy86kg34awtdq"


Still invalid: CLTV is a tu16, but you encoded it non-minimally using 2 bytes instead of one?

rustyrussell · 2022-08-03T03:41:56Z

bolt12/offer-test.json

+        "payer key": "d817e8896c67d0bcabfdb93da7eb7fc698c829a181f994dd0ad866a8eda745e8",
+        "preimage": "317d1fd8fec5f3ea23044983c2ba2a8043395b2a0790a815c9b12719aa5f1516",
+	"offer": "lno1pg9k66twd9kkzmpqw35hq83pqf8l2vtlq5w87m4vqfnvtn82adk9wadfgratnp2wg7l7ha4u0gzqw",
+        "request": "lnr1qvsxlc5vp2m0rvmjcxn2y34wv0m5lyc7sdj7zksgn35dvxgqqqqqqqqyyrfgrkke8dp3jww26jz8zgvhxhdhzgj062ejxecv9uqsdhh2x9lnjzqrkudsqf3qrm6y88mr3y2du7fzqjpamgedldayx8nenfwwtfmy877hpvs33e80qszhudm9rdk99qpnzktv6emdwq3gda2l77c6av7nn542sl3uhzq5yau26508s7n0mf3ztpnwr6f8vlxhjrlhc34w6sehs9jwydpxhxnws",


Looks like this uses the old "payer_signature" name to calculate the signature, not "signature"? Should be easy to fix...

$ ./devtools/bolt12-cli --allow-deprecated-apis=false decode lnr1qvsxlc5vp2m0rvmjcxn2y34wv0m5lyc7sdj7zksgn35dvxgqqqqqqqqyyrfgrkke8dp3jww26jz8zgvhxhdhzgj062ejxecv9uqsdhh2x9lnjzqrkudsqf3qrm6y88mr3y2du7fzqjpamgedldayx8nenfwwtfmy877hpvs33e80qszhudm9rdk99qpnzktv6emdwq3gda2l77c6av7nn542sl3uhzq5yau26508s7n0mf3ztpnwr6f8vlxhjrlhc34w6sehs9jwydpxhxnws chain: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f payer_key: 021ef4439f638914de79220483dda32dfb7a431e799a5ce5a7643fbd70b2118e4e offer_id: d281dad93b431939cad48471219735db71224fd2b323670c2f0106deea317f39 amount: 0.00012000000bc signature: INVALID payer_signature: 57e37651b6c5280331596cd676d702286f55ff7b1aeb3d39d2aa87e3cb88142778ad51e787a6fda6225866e1e92767cd790ff7c46aed43378164e23426b9a6e8

t-bast and others added 24 commits November 9, 2021 12:25

BOLT 4,7: move onion_message from BOLT7 to 4, renumber to 513.

3fc2d15

It's not really a gossip message. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

More fixups

6e99c5f

Feedback from t-bast and joostjager. - onion_msgpayload encrypted_data_tlv is type 4, not 10. - enctlv in path is now called encrypted_recipient_data which is consistent. - Removed setting of onionmsg feature in invoices. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT 1: add bip340sig type.

82ecb6d

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT 1: Add utf8 type.

8d43d59

It's far easier to validate these on parsing than to hand-validate them elsewhere. I didn't turn `alias` or `error` into this, though they're similar (`alias` can have a nul terminator). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT 1: add point32 type.

18841fe

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

tools/spellcheck.sh: more generally ignore things inside ``.

c95cbb6

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT 12: add optional capacity notes for each blinded path.

9447193

Rene Pickhardt points out that this improves payment success, and it makes perfect sense. It's an odd field, since it's harmless to ignore and/or not implement. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT 12: add optional payer_note.

11254c5

It's spelled "payer_note" but it's *pronounced* "chicken taunt"! Again, it's an odd field, since it's harmless to ignore and/or not implement. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT12: Add merkle test vectors.

d752a8a

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT 12: remove recurrence from first version.

2b923a0

At the recommendation of @t-bast, I'm stripping recurrence from the initial version of the spec. This can be re-added later (possibly with changes) once the rest has been agreed on. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT 4: don't use byte type, use tlv type directly.

26a2c94

The c-lightning tooling doesn't hand this yet, but we can fix that. Suggested-by: ThomasH Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT 12: feedback from @bjarnemagnussen and @ellemouton

27fbff0

Nothing earthshattering, but some typos and more explicit requirements for the `chain` field. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT 12: add desthint workaround for pre-blinded-payment private chan…

d0f1593

…nels. Suggested-by: @bluematt Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT 12: more feedback from @bjarnemagnussen

60550f9

Use " not ` for string literals. And remove merkle test which used now-removed fields. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT 12: allow omitting node_id if we can extract from a blinded path.

64a9f06

You're either making up the node_id anyway, or you don't need to blind it. Saves some space. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT 12: don't blind first hop on blinded_path.

e79bc18

The reader can do it, and this avoids having to separately specify the `first_node_id`. Also clarify when using the path is mandatory. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Add test

158f9bd

thomash-acinq mentioned this pull request Jul 20, 2022

Offers lightning/bolts#798

Merged

Fix u32 -> u16

fe3b1d3

rustyrussell force-pushed the guilt/offers branch from f316a0f to f451fa8 Compare August 1, 2022 05:31

rustyrussell requested changes Aug 3, 2022

View reviewed changes

rustyrussell force-pushed the guilt/offers branch from 7019d66 to da2db2b Compare September 15, 2022 02:06

rustyrussell force-pushed the guilt/offers branch from 1b0d41e to eb979fb Compare October 5, 2022 00:50

rustyrussell force-pushed the guilt/offers branch from a085528 to 3e8add3 Compare October 17, 2022 02:16

rustyrussell force-pushed the guilt/offers branch 2 times, most recently from 83c55af to 18912bc Compare January 9, 2023 05:01

rustyrussell force-pushed the guilt/offers branch from 8360695 to d4c8b6c Compare April 2, 2023 23:58

rustyrussell force-pushed the guilt/offers branch 2 times, most recently from bb000fa to fe6c2c6 Compare August 14, 2023 05:08

rustyrussell force-pushed the guilt/offers branch from 5773075 to db73bbb Compare September 10, 2024 04:02

rustyrussell force-pushed the guilt/offers branch from 1197302 to f4d74a9 Compare September 24, 2024 08:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add test for offers #6

Add test for offers #6

thomash-acinq commented Jul 20, 2022

rustyrussell left a comment

rustyrussell Aug 3, 2022

rustyrussell Aug 3, 2022

rustyrussell Aug 3, 2022

Add test for offers #6

Are you sure you want to change the base?

Add test for offers #6

Conversation

thomash-acinq commented Jul 20, 2022

rustyrussell left a comment

Choose a reason for hiding this comment

rustyrussell Aug 3, 2022

Choose a reason for hiding this comment

rustyrussell Aug 3, 2022

Choose a reason for hiding this comment

rustyrussell Aug 3, 2022

Choose a reason for hiding this comment