[Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

Rusty Russell rusty at rustcorp.com.au
Fri Nov 8 02:55:17 UTC 2019


ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> First, please confirm my understanding of the message flow.
> Suppose I have a donation offer on my website and Rusty wants to donate to me.
> Then:
>
>          ZmnSCPxj                      Rusty
>             |                            |
>             +---------- `lno` ---------->+ (via non-Lightning communication channel e.g. https)
>             |                            |
>             +<---- `invoice_request` ----+ (via a normal Rusty->ZmnSCPxj payment)
>             |                            |
>             +---- `invoice_or_error` --->| (by failing the above payment and embedding in the failure blob)
>             |                            |
>             +<------- `sendpay` ---------+ (via a normal Rusty->ZmnSCPxj payment)
>
> Is it approximately correct?

Sorry for delayed response; yes, this is correct.

>> gets an invoice request (`lni...`), and sends the invoice over the
>> lightning network, retreiving an empty reply.
>
> Here are completely pointless counterproposals for the offer and invoice-request HRPs:
>
> * Offers:
>   * `lnpayme`
>   * `lnbuyit`
>   * `lnforsale`
> * Invoice Requests:
>   * `lnpaying`
>   * `lnbuying`
>   * `lnshutupandtakemymoney`
>
> `lno` and `lni` feel wrong to me.
> Their juxtaposition implies `lno` == output and `lni` == input to me, due to the use of `o` and `i`, though `lno` is where you get money in exchange for product and `lni` is the request-for-service.

lnx and lny?  Nobody can interpret them at all, that way :)
>>     3.  type: 2 (`description`)
>>     4.  data:
>>         -   [`...*byte`:`description`]
>
> UTF-8?
> Null-terminated?

I was thinking UTF-8 like current field.

>> -   MUST include `amount` if it includes `recurrence`.
>> -   if it includes `amount`:
>>     -   MUST specify `currency` as the ISO 4712 or BIP-0173, padded with zero bytes if required
>
> I cannot find ISO 4712, but could find ISO 4217.

Oops, I fixed my typo wrong.  Thanks.

> BIP-173 does not have a list of currencies, but refers to SLIP-0173.
> Some of the listed currencies there seem to have more than 4 characters.

Oh, I'd never seen SLIP-0173.  Cool, I increased it to 5; SLIP-0173 has
no limit but I find it hard to care about any of them anyway.

> Should I assume encoding is ASCII?
> We will "never" see a non-ASCII currency code?

Not really, but if you don't understand it you can't do much, ASCII or
no.

>> The "default offer" of a node is a nominal offer used to send
>> unsolicited payments. It is generally not actually sent, but can be
>> used by any other node as if it has been. It has the following
>> fields:
>>
>> -   `offer_idenfitier`: zero-length
>> -   `d`: any
>> -   `n`: the node id of the recipient.
>
> In essence, this is an implicitly-existing offer that never expires, and which can be used by any node at any time to construct an invoice request?

Yep!

>> The `refund_proof` refers to a previous invoice paid by the sender for
>> the specific case of a `refund_for` offer. It provides proof of
>> payment (the `payment_preimage` and also a signature of the
>> `payment_hash` from the `key` which requested the being-refunded
>> invoice (which does not have to be the same as this `key`!).
>
> An earlier requirement mentions that writers of offers or invoice request MUST have `paths` in some condition.
> The below does not have `paths`, but there is a "human-readable" alternate encoding which *does* have `paths`.
> It might be better to clarify this point.

The in-wire one doesn't have paths, since you respond by reply; you
don't need (and should not be able to) find the sender.

The non-wire one needs a path, since you need to initiate a reply.

>> The `directed` and `directed_reply` Messages
>>
>> ---------------------------------------------
>>
>> 1.  type: 384 (`directed`) (`option_directed_messages`)
>> 2.  data:
>>     -   [`chain_hash`:`chain_hash`]
>>     -   [`u64`:`id`]
>>     -   [`1366*byte`:`onion_routing_packet`]
>> 3.  type: 384 (`directed_reply`) (`option_directed_messages`)
>> 4.  data:
>>     -   [`chain_hash`:`chain_hash`]
>>     -   [`u64`:`id`]
>>     -   [`u16`:`len`]
>>     -   [`len*byte`:`reply`]
>
> This new `directed` message will be the mechanism for sending invoice requests and receiving invoice request responses?

Yes.

> What incentive is there for a forwarding node to actually forward a `directed` message?

It's a strong liveness indicator to the sender, so they're likely to use
the same path for the actual payment.

Cheers,
Rusty.


More information about the Lightning-dev mailing list