René Pickhardt <r.pickha...@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. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev