Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.
René Pickhardt writes: > Dear Rusty, > > I am not getting this proposal (maybe I am lacking some technical basic > understandings) however I decided to ask more questions in order to > complete my onboarding process faster and hope this is fine. > > My problem starts with the fact that I can't find the term "lightning probe > message" in the current BOLTs (actually the term probe only occures two > times and these seem unrelated to what you are talking about) so I am > confused what this is. It would be a new message. We don't have an equivalent at the moment, though one was proposed for liveness testing of routes pre-payment: Use probing with short latency constraints (ex” must reply within 100 ms) to check that a route is usable before payment is actually sent https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001484.html > As far as I understand your proposal from a high level the payer is > supposed to create an onion package which triggers the offering of HTLCs > with some additional metadata so that the receipient of the final onion can > answer with a BOLT11 invoice. What I don't get is the fact that a payment > hash needs to be known in order to offer HTLCs. No, there's a new message, which looks like: 1. type: 260 (`fetch_invoice`) 2. data: * [`32`:`channel_id`] * [`1366`:`onion_routing_packet`] (The onion doesn't need some of the current fields, TBD). > In general I was wondering (already during the summit) why we don't include > a connection oriented communication layer on top of the current protocol > which would allow payer and payee to communicate more efficiently about > payment and routing process and to negotiate stuff like spontaneos > payments. This is HORNET; I recommend reading the paper. I admit that this message is the camel's nose in the tent, but we're building a payment network, not a generalized communication network. And until we figure out how to pay-per-message without haemorrhaging privacy, we shouldn't build such a thing. > I see two reasons against this: 1.) more synchronous > communication makes stuff more complicated to implement and 2.) privacy > concerns. 3) Lack of incentives. Nodes forward because they want a functioning payment network, and they hope to be rewarded for it. At the moment you can get spammed quite badly and never get paid; I'd like to make that more difficult, not bake it into the protocol! Someone may build such a thing on top of lightning, but lightning nodes are not generalized bandwidth providers. > Am I missing something here? (and sorry for splitting the topic but I > didn't want to start a new one when it actually seems to fit to this > proposal. This is a can of worms I don't want to open for 1.1... Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.
Dear Rusty, I am not getting this proposal (maybe I am lacking some technical basic understandings) however I decided to ask more questions in order to complete my onboarding process faster and hope this is fine. My problem starts with the fact that I can't find the term "lightning probe message" in the current BOLTs (actually the term probe only occures two times and these seem unrelated to what you are talking about) so I am confused what this is. As far as I understand your proposal from a high level the payer is supposed to create an onion package which triggers the offering of HTLCs with some additional metadata so that the receipient of the final onion can answer with a BOLT11 invoice. What I don't get is the fact that a payment hash needs to be known in order to offer HTLCs. Though I imagine you ment it differently I would not see a problem with the payer to know the preimage in advance as he is creating the entire onion on his behalf and sponanious without invoice anyway. However I don't get why a returned BOLT11 invoice is needed then. I assume that my previouse statement is wrong anyway since you don't mention anywhere how the preimage would be send from the payer to the payee. In general I was wondering (already during the summit) why we don't include a connection oriented communication layer on top of the current protocol which would allow payer and payee to communicate more efficiently about payment and routing process and to negotiate stuff like spontaneos payments. I see two reasons against this: 1.) more synchronous communication makes stuff more complicated to implement and 2.) privacy concerns. Am I missing something here? (and sorry for splitting the topic but I didn't want to start a new one when it actually seems to fit to this proposal. best Rene On Thu, Nov 15, 2018 at 4:57 AM Rusty Russell wrote: > Hi all, > > I want to propose a method of having reusable BOLT11 "offers" which > provide almost-spontaneous payments as well as not requiring generating > a BOLT11 invoice for each potential sale. > > An "offer" has a `p` field of 26 bytes (128 bits assuming top two are 0) > (which is ignored by existing nodes). The payer uses a new lightning > probe message using the current onion format we use for HTLCs to > retreive the complete invoice. > > The format of the final-hop lightning onion would contain: > > [whatever-marker-we-need?][128-bit-`p`-field][[type,len,data]+] > > We would probably define a few optional types to start: > > 1. quantity: for ordering multiple of an item, default 1. > 2. delivery-address: steal from > https://www.w3.org/TR/vcard-rdf/#Delivery_Addressing_Properties ? > 3. signature: basically a blob so payer can prove it was them. > > The return lightning message would contain a new bolt11 invoice (perhaps > we optimize some fields by copying from the bolt11 offer if they don't > appear?), and an additional field: > > `m` (27) `data_length` 52. Merkle hash of fields payer provided > in onion msg above, and the offer `p` value. > > The payer checks the signature is correct, `m` is correct, and uses the > invoice to pay as normal. The bolt11 offer + fields-from-onion + bolt11 > invoice + preimage is the complete proof of payment. > > Refinements > --- > > We can generate alternate leaves for the merkle tree (using > SHA256(shared-secret | leafnum)) so revealing the `m` value doesn't risk > revealing your delivery-address for example. > > The return needs to list the fields it *didn't* include in the merkle > because it didn't accept them (the merchant doesn't want to be bound to > conditions it doesn't understand!). > > We could add a `k` field to the bolt11 offer to allow the final invoice > to delegated to a separate key. > > The default `x` (expiry) field for an offer which does not have an > old-style 53-byte `p` field (ie. a "pure" offer) could be infinite. > > We could merkelize the delivery-address too :) > > I've handwaved a bit over the detailed format, because there are other > things we want to put in the onion padding, and because the return is > similar to the "soft-error"/"partial payment ack" proposals. > > Results > --- > > This gives us static invoicing, and a single static invoice (without an > amount field) can thus be used to approximate "spontaneous" donations, > while still providing proof of payment; indeed, providing > non-transferrable proof-of-payment since the invoice now commits to the > payer-provided signature. > > It also provides a platform for recurring payments: while we can do this > with preimage-is-next-payment_hash, that requires pre-generation and > isn't compatible with static invoices. > > I apologize that this wasn't fleshed out before the summit, but I > overestimated the power of Scriptless Scripts so had mentally deferred > this. > > Thanks! > Rusty. > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org >
Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.
Good morning Rene, Not Rusty, but I shall spam the list as for my normal habit anyway. >My problem starts with the fact that I can't find the term "lightning probe >message" in the current BOLTs (actually the term probe only occures two >times and these seem unrelated to what you are talking about) so I am >confused what this is. This is basically, generating a `payment_hash` from random data, whose preimage it is very unlikely the payee knows, and then sending it to the payee. Since the payee does not know the preimage, it cannot actually claim the funds. I believe, somebody in the summit pointed out that this mechanism could, today, be used to stream anime. The payee does not actually get paid, but has to return an error for why it cannot claim the HTLC. The error from the payee can contain a short section of an anime movie file instead of an error message, which the payer then watches instead of worrying about why they cannot pay. Rather than using this mechanism to stream anime, we use this mechanism to stream invoices, which is much more sensible use for a payment network. >As far as I understand your proposal from a high level the payer is >supposed to create an onion package which triggers the offering of HTLCs >with some additional metadata so that the receipient of the final onion can >answer with a BOLT11 invoice. What I don't get is the fact that a payment >hash needs to be known in order to offer HTLCs. As mentioned, this mechanism basically has the putative payer generate a random hash. The error response then contains the "real" BOLT11 invoice, plus some extra data as described by Rusty in the initial post. >Though I imagine you ment it differently I would not see a problem with the >payer to know the preimage in advance as he is creating the entire onion on >his behalf and sponanious without invoice anyway. However I don't get why a >returned BOLT11 invoice is needed then. Since the probe will fail, the payee does not get actually paid. Instead the payee returns the **real** `payment_hash`, encoded (presumably) as part of a BOLT11 invoice. (or we encode the BOLT11 invoice fields in binary instead of BECH32 for compression, and so on, but basically, the payer can now generate a BOLT11 invoice it can pay using normal Lightning payment methods; this is my reasoning for proposing to add these "offers" as a separate BOLT, e.g. BOLT15. A BOLT15 offer lets you get any number of BOLT11 invoices.) >In general I was wondering (already during the summit) why we don't include >a connection oriented communication layer on top of the current protocol >which would allow payer and payee to communicate more efficiently about >payment and routing process and to negotiate stuff like spontaneos >payments. I believe this was the reason for pushing for HORNET implementation on Lightning. HORNET is basically the connection communication layer being proposed, with improved privacy because HORNET. For myself, I think that we should attach payments for each HORNET-style messaging system, and impose a `update_fail_htlc` limit so that only errors and a short text message can be returned for errors. As to why not HORNET... >I see two reasons against this: 1.) more synchronous >communication makes stuff more complicated to implement and 2.) privacy >concerns. Mostly complexity, and concerns that people will abuse the network capacity (as in bytes capacity of TCP/IP connections, not satoshis capacity of channels). That is why I think that if we *do* implement HORNET, then a payment or forwarding fee should be attached to each such message. Attaching payments to the faithful delivery of HORNET-level messages is needed, but I am uncertain if it is feasible to do so. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.
Good morning Rusty, > > > I apologize that this wasn't fleshed out before the summit, but I > > > overestimated the power of Scriptless Scripts so had mentally deferred > > > this. > > > > My understanding is that SS is as powerful as we thought, at least for some > > of the applications we were hoping to use it for. > > However, implementing SS is hard without Schnorr, because script magic with > > `OP_CODESEPARATOR` is magic, and we essentially stalled out and said "maybe > > wait for Schnorr instead". > > No, we don't get static invoices. That was my hope; that we could do > static invoicing without an extra interaction. At first I thought it was possible, but on reflection, you are correct. We need some way for the payee to dynamically provide a new payment hash (or payment point under SS). This is because our proof-of-payment essentially means the payer learns a secret. So we cannot commit to a fixed secret if we want the static invoice to be shareable among multiple payers. So the payee does need to generate new secrets each time it wants to be paid, and give a unique secret to the payer as separate unique proofs-of-payment. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.
ZmnSCPxj writes: >> I apologize that this wasn't fleshed out before the summit, but I >> overestimated the power of Scriptless Scripts so had mentally deferred >> this. > > My understanding is that SS *is* as powerful as we thought, at least for some > of the applications we were hoping to use it for. > However, implementing SS is hard without Schnorr, because script magic with > `OP_CODESEPARATOR` is magic, and we essentially stalled out and said "maybe > wait for Schnorr instead". No, we don't get static invoices. That was my hope; that we could do static invoicing without an extra interaction. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.
Good morning Rusty, No particular comment on static offer invoices, but instead various bikeshedding. > > The format of the final-hop lightning onion would contain: > > [whatever-marker-we-need?][128-bit-`p`-field][[type,len,data]+] I think a separate BOLT for the type,len,data would be useful, and might also document various consistent designs of messages (such as var-length fields using a prefixed 16-bit length measuring number of items in the field). BOLT #13: type,len,data standard (I should probably move this to a new thread). > I apologize that this wasn't fleshed out before the summit, but I > overestimated the power of Scriptless Scripts so had mentally deferred > this. My understanding is that SS *is* as powerful as we thought, at least for some of the applications we were hoping to use it for. However, implementing SS is hard without Schnorr, because script magic with `OP_CODESEPARATOR` is magic, and we essentially stalled out and said "maybe wait for Schnorr instead". Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Strawman BOLT11 static "offer" format using probes.
Hi all, I want to propose a method of having reusable BOLT11 "offers" which provide almost-spontaneous payments as well as not requiring generating a BOLT11 invoice for each potential sale. An "offer" has a `p` field of 26 bytes (128 bits assuming top two are 0) (which is ignored by existing nodes). The payer uses a new lightning probe message using the current onion format we use for HTLCs to retreive the complete invoice. The format of the final-hop lightning onion would contain: [whatever-marker-we-need?][128-bit-`p`-field][[type,len,data]+] We would probably define a few optional types to start: 1. quantity: for ordering multiple of an item, default 1. 2. delivery-address: steal from https://www.w3.org/TR/vcard-rdf/#Delivery_Addressing_Properties ? 3. signature: basically a blob so payer can prove it was them. The return lightning message would contain a new bolt11 invoice (perhaps we optimize some fields by copying from the bolt11 offer if they don't appear?), and an additional field: `m` (27) `data_length` 52. Merkle hash of fields payer provided in onion msg above, and the offer `p` value. The payer checks the signature is correct, `m` is correct, and uses the invoice to pay as normal. The bolt11 offer + fields-from-onion + bolt11 invoice + preimage is the complete proof of payment. Refinements --- We can generate alternate leaves for the merkle tree (using SHA256(shared-secret | leafnum)) so revealing the `m` value doesn't risk revealing your delivery-address for example. The return needs to list the fields it *didn't* include in the merkle because it didn't accept them (the merchant doesn't want to be bound to conditions it doesn't understand!). We could add a `k` field to the bolt11 offer to allow the final invoice to delegated to a separate key. The default `x` (expiry) field for an offer which does not have an old-style 53-byte `p` field (ie. a "pure" offer) could be infinite. We could merkelize the delivery-address too :) I've handwaved a bit over the detailed format, because there are other things we want to put in the onion padding, and because the return is similar to the "soft-error"/"partial payment ack" proposals. Results --- This gives us static invoicing, and a single static invoice (without an amount field) can thus be used to approximate "spontaneous" donations, while still providing proof of payment; indeed, providing non-transferrable proof-of-payment since the invoice now commits to the payer-provided signature. It also provides a platform for recurring payments: while we can do this with preimage-is-next-payment_hash, that requires pre-generation and isn't compatible with static invoices. I apologize that this wasn't fleshed out before the summit, but I overestimated the power of Scriptless Scripts so had mentally deferred this. Thanks! Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
