Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-08 📝 Original message: ZmnSCPxj <ZmnSCPxj at ...

📅 Original date posted:2019-11-08
📝 Original message:
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.