René Pickhardt [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-20 📝 Original message: Hey Rusty, I was very ...
📅 Original date posted:2020-02-20
📝 Original message:
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 <rusty at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200220/8274f3ba/attachment.html>;
📝 Original message:
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 <rusty at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200220/8274f3ba/attachment.html>;