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.

Sign up for GitHub

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

Jump to bottom

Delivery of offered goods #2

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

Delivery of offered goods #2

wants to merge 9 commits into 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
@rustyrussell
BOLT 7: variable message onion message support.
b47c545 
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>
@rustyrussell
BOLT 4: More notes on blinding, and a general matching requirement.
1006d88 
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.
@rustyrussell
BOLT 1: add bip340sig type.
b49e2a4 
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@rustyrussell
BOLT 1: Add utf8 type.
669ad39 
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>
@rustyrussell
tools/spellcheck.sh: more generally ignore things inside ``.
65643ea 
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@rustyrussell
BOLT 12: offers, third draft
c564643 
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>
@rustyrussell
fixup! BOLT 12: offers, third draft
41b5680 
Make spellchecker happy.
@rustyrussell
BOLT 12: allow replacement of previous invoices, make signature on in…
fc8aab7 
…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>
@niftynei
offers: add scheme for required delivery info
f5cb170 
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
@rustyrussell
BOLT #2: Set an initiator in quiescence.
99c0499 
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
@rustyrussell
BOLT #2: Set an initiator in quiescence.
b96218b 
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
@rustyrussell
BOLT #2: Set an initiator in quiescence.
65f98ff 
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
@rustyrussell
BOLT #2: Set an initiator in quiescence.
9832e17 
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
@rustyrussell @ddustin
BOLT #2: Set an initiator in quiescence.
b126536 
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
@rustyrussell
BOLT 2: quiescence protocol.
dc8728a 
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
@rustyrussell
BOLT 2: quiescence protocol.
5dd9d9c 
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
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@niftynei @rustyrussell