[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

> 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...


More information about the Lightning-dev mailing list