Skip to content

Delivery of offered goods#2

Open
niftynei wants to merge 9 commits intorustyrussell:guilt/offersfrom
niftynei:nifty/offers-delivery
Open

Delivery of offered goods#2
niftynei wants to merge 9 commits intorustyrussell:guilt/offersfrom
niftynei:nifty/offers-delivery

Conversation

@niftynei
Copy link

@niftynei niftynei commented May 11, 2021

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

rustyrussell commented May 11, 2021

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

rustyrussell commented May 13, 2021

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