Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delivery of offered goods #2

Open
wants to merge 9 commits into
base: guilt/offers
Choose a base branch
from

Conversation

niftynei
Copy link

Proposal for how to specify 'delivery info' for an offer.

rustyrussell and others added 9 commits April 16, 2021 14:43
These use onion encoding for simple one-way messaging: there are no error returns.

Any reply is done with an enclosed blinded path.

Note that this defines the message system, not the contents of messages
(e.g. invoice requests from offers).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we supply a reply_path, we *must not* respond if we get a message
which doesn't use it.  Similarly, we must not respond to requests via
a reply_path except the exact reply we want.
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.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Make spellchecker happy.
…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>
Provide lightweight mechanism for peer to send info about the delivery
of paid goods to the peer.

Lightly structured, with provided extensibility
@rustyrussell
Copy link
Owner

Some information might be optional, e.g. include an address if you want your free gift / emailed receipt etc. So I would use odd and even bits here.

I don't think a single proprietary thing works; there's no way to know what should go in there? They can simply define their own bits as reqd?

Finally, my original proposal had a more structure address. I did some research and there's no great common structure, but I can definitely see programatic treatment of country code being desirable.'

To pull from a v early draft for inspiration:

+1. Bits `0/1`: include `delivery_address`
+2. Bits `2/3`: include `delivery_telephone_number`
+3. Bits `4/5`: include `voucher_code`
...
+  - SHOULD gain user consent to send `delivery_` fields.
...
+   1. type: 6 (`delivery_address_name`)
+   2. data:
+	 * [`...*byte`:`name`]
+   1. type: 7 (`delivery_address1`)
+   2. data:
+	 * [`...*byte`:`address1`]
+   1. type: 8 (`delivery_address2`)
+   2. data:
+	 * [`...*byte`:`address2`]
+   1. type: 9 (`delivery_city`)
+   2. data:
+	 * [`...*byte`:`city`]
+   1. type: 10 (`delivery_state_province_or_region`)
+   2. data:
+	 * [`...*byte`:`state_province_or_region`]
+   1. type: 11 (`delivery_zip_or_postal_code`)
+   2. data:
+	 * [`...*byte`:`zip_or_postal_code`]
+   1. type: 12 (`delivery_country`)
+   2. data:
+	 * [`2*byte`:`country_code`]
+   1. type: 13 (`delivery_telephone_number`)
+   2. data:
+	 * [`...*byte`:`tel`]
+   1. type: 14 (`voucher_code`)
+   2. data:
+	 * [`...*byte`:`code`]
...
+Sender MUST use ISO 3166 alpha-2 code for `delivery_country`.
...
+Receiver MUST check `delivery_` fields.

@rustyrussell
Copy link
Owner

Also, we can use features rather define a new field, I think?

rustyrussell added a commit that referenced this pull request May 24, 2021
This is especially useful for protocols such as splicing; for
simplified commitment transactions, there is already an implied
initiator at each point, so having the negotiation at splicing
time would be redundant.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit that referenced this pull request May 24, 2021
This is especially useful for protocols such as splicing; for
simplified commitment transactions, there is already an implied
initiator at each point, so having the negotiation at splicing
time would be redundant.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@rustyrussell rustyrussell force-pushed the guilt/offers branch 5 times, most recently from 936e677 to 56ff7fa Compare July 5, 2021 06:20
rustyrussell added a commit that referenced this pull request Jul 19, 2021
This is especially useful for protocols such as splicing; for
simplified commitment transactions, there is already an implied
initiator at each point, so having the negotiation at splicing
time would be redundant.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit that referenced this pull request Sep 30, 2021
This is especially useful for protocols such as splicing; for
simplified commitment transactions, there is already an implied
initiator at each point, so having the negotiation at splicing
time would be redundant.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@rustyrussell rustyrussell force-pushed the guilt/offers branch 2 times, most recently from 83c55af to 18912bc Compare January 9, 2023 05:01
@rustyrussell rustyrussell force-pushed the guilt/offers branch 2 times, most recently from bb000fa to fe6c2c6 Compare August 14, 2023 05:08
ddustin pushed a commit that referenced this pull request Feb 13, 2024
This is especially useful for protocols such as splicing; for
simplified commitment transactions, there is already an implied
initiator at each point, so having the negotiation at splicing
time would be redundant.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit that referenced this pull request Jun 11, 2024
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>




Header from folded patch 'bolt_2__set_an_initiator_in_quiescence.patch':

BOLT #2: Set an initiator in quiescence.

This is especially useful for protocols such as splicing; for
simplified commitment transactions, there is already an implied
initiator at each point, so having the negotiation at splicing
time would be redundant.

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



Header from folded patch 'option_quiesce__feature_to_support_stfu_method.patch':

option_quiesce: feature to support stfu method.

In practice, sftu is useless unless you have something (e.g. channel_upgrade)
which uses it, but adding a feature is best practice IMHO.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit that referenced this pull request Jul 9, 2024
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>




Header from folded patch 'bolt_2__set_an_initiator_in_quiescence.patch':

BOLT #2: Set an initiator in quiescence.

This is especially useful for protocols such as splicing; for
simplified commitment transactions, there is already an implied
initiator at each point, so having the negotiation at splicing
time would be redundant.

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



Header from folded patch 'option_quiesce__feature_to_support_stfu_method.patch':

option_quiesce: feature to support stfu method.

In practice, sftu is useless unless you have something (e.g. channel_upgrade)
which uses it, but adding a feature is best practice IMHO.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants