rich1.0Rusty Russell [ARCHIVE] (npub1zw…hkhpx)https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://yabu.me📅 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.