Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-20 📝 Original message: Hi all! It seems that ...
📅 Original date posted:2020-02-20
📝 Original message:
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>
📝 Original message:
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>