ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-20 📝 Original message: Good morning Rusty, A ...
📅 Original date posted:2020-02-20
📝 Original message:
Good morning Rusty,
A concern I have brought up in the past is that if this is more than just a single request-response, i.e. if this is a conversation where Alice sends to Bob, Bob sends back to Alice, Alice sends back to Bob, and so on, then if the same path is used each time Alice sends to Bob, the timing from Bob response to Alice to the next Alice sends to Bob can help an intermediate node guess how far away Alice is from itself.
Obviously the timing from Alice sending to Bob and Bob replying gives a hint as well as to the distance the intermediate node is to Bob already.
It may be good to at least recommend that direct messages use different paths if they are part of a larger conversation between the two parties.
Would it not be better to create a circular path?
By this I mean, Alice constructs an onion that overall creates a path from herself to Bob and back, ensuring different nodes on the forward and return directions.
The onion hop at Bob reveals that Bob is the chosen conversation partner, and Bob forwards its reply via the onion return path (that Alice prepared herself to get back to her via another path).
After Alice receives the first message from Bob the circular "circuit" is established and they can continue to communicate using the same circuit: timing attacks are now "impossible" since Alice and Bob can be anywhere along the circle, even if two of the nodes in the circuit are surveillors cooperating with each other, the timing information they get is the distance between the surveillor nodes.
Of course, if a node in the circular path drops the circuit is disrupted, so any higher-level protocols on top of that should probably be willing to resume the conversation on another circular circuit.
I believe I even tied this to an HTLC in an attempt to provide a spam-limit as well: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002294.html
Finally: what does this improve over, say, requiring that all Lightning nodes have a Tor .onion address and just doing direct messaging over Tor?
Regards,
ZmnSCPxj
> 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)
> - 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)
> - - Routing (types `256`-`511`): messages containing node and channel announcements, as well as any active route exploration (described in BOLT #7)
>
> - - Routing (types `256`-`511`): messages containing node and channel announcements, as well as any active route exploration or forwarding (described in BOLT #7)
> - 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
> - TLV Payload Format
> - Basic Multi-Part Payments
> - - Directed Messages
>
> - Accepting and Forwarding a Payment
> - Payload for the Last Node
> - Non-strict Forwarding
> @@ -62,6 +63,7 @@ A node:
>
> - Returning Errors
> - Failure Messages
> - Receiving Failure Codes
>
> - - Directed Message Replies
> - Test Vector
> - Returning Errors
> - 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
> - Pruning the Network View
> - Recommendations for Routing
>
> - - Directed Messages
> - 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). Like gossip messages,
> +they are not associated with a particular local channel. Like HTLCs,
> +they use BOLT 4 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 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</a>
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
Good morning Rusty,
A concern I have brought up in the past is that if this is more than just a single request-response, i.e. if this is a conversation where Alice sends to Bob, Bob sends back to Alice, Alice sends back to Bob, and so on, then if the same path is used each time Alice sends to Bob, the timing from Bob response to Alice to the next Alice sends to Bob can help an intermediate node guess how far away Alice is from itself.
Obviously the timing from Alice sending to Bob and Bob replying gives a hint as well as to the distance the intermediate node is to Bob already.
It may be good to at least recommend that direct messages use different paths if they are part of a larger conversation between the two parties.
Would it not be better to create a circular path?
By this I mean, Alice constructs an onion that overall creates a path from herself to Bob and back, ensuring different nodes on the forward and return directions.
The onion hop at Bob reveals that Bob is the chosen conversation partner, and Bob forwards its reply via the onion return path (that Alice prepared herself to get back to her via another path).
After Alice receives the first message from Bob the circular "circuit" is established and they can continue to communicate using the same circuit: timing attacks are now "impossible" since Alice and Bob can be anywhere along the circle, even if two of the nodes in the circuit are surveillors cooperating with each other, the timing information they get is the distance between the surveillor nodes.
Of course, if a node in the circular path drops the circuit is disrupted, so any higher-level protocols on top of that should probably be willing to resume the conversation on another circular circuit.
I believe I even tied this to an HTLC in an attempt to provide a spam-limit as well: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002294.html
Finally: what does this improve over, say, requiring that all Lightning nodes have a Tor .onion address and just doing direct messaging over Tor?
Regards,
ZmnSCPxj
> 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)
> - 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)
> - - Routing (types `256`-`511`): messages containing node and channel announcements, as well as any active route exploration (described in BOLT #7)
>
> - - Routing (types `256`-`511`): messages containing node and channel announcements, as well as any active route exploration or forwarding (described in BOLT #7)
> - 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
> - TLV Payload Format
> - Basic Multi-Part Payments
> - - Directed Messages
>
> - Accepting and Forwarding a Payment
> - Payload for the Last Node
> - Non-strict Forwarding
> @@ -62,6 +63,7 @@ A node:
>
> - Returning Errors
> - Failure Messages
> - Receiving Failure Codes
>
> - - Directed Message Replies
> - Test Vector
> - Returning Errors
> - 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
> - Pruning the Network View
> - Recommendations for Routing
>
> - - Directed Messages
> - 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). Like gossip messages,
> +they are not associated with a particular local channel. Like HTLCs,
> +they use BOLT 4 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 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</a>
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev