[Lightning-dev] Strawman BOLT11 static "offer" format using probes.
Rusty Russell
rusty at rustcorp.com.au
Sat Nov 17 23:20:56 UTC 2018
René Pickhardt <r.pickhardt at googlemail.com> 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.
More information about the Lightning-dev
mailing list