ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-16 📝 Original message: Good morning Rene, Not ...
📅 Original date posted:2018-11-16
📝 Original message:
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
📝 Original message:
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