Hey Rusty, I was very delighted to read your proposal. But I don't see how you prevent message spam. If I understand you correctly you suggest that I can communicate to any node along a path of peer connections (not necessarily backed by payment channels but kind of only known through channel announcements of gossip) via onions and these onions which are send within a new gossip message are not bound to any fees or payments.
Let's assume I just missed some spam prevention mechanism or that we can fix them. Do I understand the impact of your suggestion correctly that I could use this protocol to 1.) create a fee free rebalancing protocol? Because I could also attach a new lightning message inside the onions that would allow nodes without direct peer connection to set up a circular rebalancing path. 2.) have the ability to communicate with nodes further away than just my peers - for example to exchange information for pathfinding and / or autopilots? With kind regards Rene Rusty Russell <ru...@rustcorp.com.au> schrieb am Do., 20. Feb. 2020, 10:37: > Hi all! > > It seems that messaging over lightning is A Thing, and I want to > use it for the offers protocol anyway. So I've come up with the > simplest proposal I can, and even implemented it. > > Importantly, it's unreliable. Our implementation doesn't > remember across restarts, limits us to 1000 total remembered forwards > with random drop, and the protocol doesn't (yet?) include a method for > errors. > > This is much friendlier on nodes than using an HTLC (which > requires 2 round trips, signature calculations and db commits), so is an > obvious candidate for much more than just invoice requests. > > The WIP patch is small enough I've pasted it below, but it's > also at https://github.com/lightningnetwork/lightning-rfc/pull/748 > > diff --git a/01-messaging.md b/01-messaging.md > index 40d1909..faa5b18 100644 > --- a/01-messaging.md > +++ b/01-messaging.md > @@ -56,7 +56,7 @@ The messages are grouped logically into five groups, > ordered by the most signifi > - Setup & Control (types `0`-`31`): messages related to connection > setup, control, supported features, and error reporting (described below) > - Channel (types `32`-`127`): messages used to setup and tear down > micropayment channels (described in [BOLT #2](02-peer-protocol.md)) > - Commitment (types `128`-`255`): messages related to updating the > current commitment transaction, which includes adding, revoking, and > settling HTLCs as well as updating fees and exchanging signatures > (described in [BOLT #2](02-peer-protocol.md)) > - - Routing (types `256`-`511`): messages containing node and channel > announcements, as well as any active route exploration (described in [BOLT > #7](07-routing-gossip.md)) > + - Routing (types `256`-`511`): messages containing node and channel > announcements, as well as any active route exploration or forwarding > (described in [BOLT #7](07-routing-gossip.md)) > - Custom (types `32768`-`65535`): experimental and application-specific > messages > > The size of the message is required by the transport layer to fit into a > 2-byte unsigned int; therefore, the maximum possible size is 65535 bytes. > diff --git a/04-onion-routing.md b/04-onion-routing.md > index 8d0f343..84eff9a 100644 > --- a/04-onion-routing.md > +++ b/04-onion-routing.md > @@ -51,6 +51,7 @@ A node: > * [Legacy HopData Payload Format](#legacy-hop_data-payload-format) > * [TLV Payload Format](#tlv_payload-format) > * [Basic Multi-Part Payments](#basic-multi-part-payments) > + * [Directed Messages](#directed-messages) > * [Accepting and Forwarding a > Payment](#accepting-and-forwarding-a-payment) > * [Payload for the Last Node](#payload-for-the-last-node) > * [Non-strict Forwarding](#non-strict-forwarding) > @@ -62,6 +63,7 @@ A node: > * [Returning Errors](#returning-errors) > * [Failure Messages](#failure-messages) > * [Receiving Failure Codes](#receiving-failure-codes) > + * [Directed Message Replies](#directed-message-replies) > * [Test Vector](#test-vector) > * [Returning Errors](#returning-errors) > * [References](#references) > @@ -366,6 +368,13 @@ otherwise meets the amount criterion (eg. some other > failure, or > invoice timeout), however if it were to fulfill only some of them, > intermediary nodes could simply claim the remaining ones. > > +### Directed Messages > + > +Directed messages have an onion with an alternate `hop_payload` > +format. If this node is not the intended recipient, the payload is > +simply a 33-byte pubkey indicating the next recipient. Otherwise, the > +payload is the message for this node. > + > # Accepting and Forwarding a Payment > > Once a node has decoded the payload it either accepts the payment > locally, or forwards it to the peer indicated as the next hop in the > payload. > @@ -1142,6 +1151,11 @@ The _origin node_: > - MAY use the data specified in the various failure types for debugging > purposes. > > +## Directed Message Replies > + > +Directed message replies are encoded the same way as failure messages, > +except the contents is a directed message for the originator. > + > # Test Vector > > ## Returning Errors > diff --git a/07-routing-gossip.md b/07-routing-gossip.md > index ec1a8f0..4c2b836 100644 > --- a/07-routing-gossip.md > +++ b/07-routing-gossip.md > @@ -1,4 +1,4 @@ > -# BOLT #7: P2P Node and Channel Discovery > +# BOLT #7: P2P Node and Channel Discovery and Directed Messages > > This specification describes simple node discovery, channel discovery, > and channel update mechanisms that do not rely on a third-party to > disseminate the information. > > @@ -31,6 +31,7 @@ multiple `node_announcement` messages, in order to > update the node information. > * [HTLC Fees](#htlc-fees) > * [Pruning the Network View](#pruning-the-network-view) > * [Recommendations for Routing](#recommendations-for-routing) > + * [Directed Messages](#directed-messages) > * [References](#references) > > ## Definition of `short_channel_id` > @@ -1103,6 +1104,37 @@ A->D's `update_add_htlc` message would be: > And D->C's `update_add_htlc` would again be the same as B->C's direct > payment > above. > > +# Directed Messages > + > +Directed messages allow peers to use existing connections to query for > +invoices (see [BOLT 12](12-offer-encoding.md)). Like gossip messages, > +they are not associated with a particular local channel. Like HTLCs, > +they use [BOLT 4](04-onion-routing.md#directed-messages) protocol for > +end-to-end encryption. > + > +Directed messages are unreliable: in particular, they are designed to > +be cheap and not to need to be committed to a database (though an > +implementation may choose to). Each one has an optional reply, which > +is [onion encoded](04-onion-routing.md#directed-message-replies) 0just > +like HTLC errors. > + > +## The `directed` and `directed_reply` Messages > + > +1. type: 385 (`directed`) (`option_directed_messages`) > +2. data: > + * [`1366*byte`:`onion_routing_packet`] > + > +1. type: 386 (`directed_reply`) (`option_directed_messages`) > +2. data: > + * [`sha256`:`onion_routing_packet_hash`] > + * [`u16`:`len`] > + * [`len*byte`:`reply`] > + > +## Requirements > + > +FIXME: similar to update_add_htlc and update_fail_htlc. > +FIXME: define reasonable timeout after which you can forget if not > replied? > + > ## References > > 1. <a id="reference-1">[RFC 1950 "ZLIB Compressed Data Format > Specification version 3.3](https://www.ietf.org/rfc/rfc1950.txt)</a> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
