<p>Questions like these are always leading to an opinionated response and are a little bit tough to answer. I will give it a shot though.</p>

<p>First of all I think youelf already answered your question to an important degree. Forwarding messages via the SPHINX protocol yield the possibility of message length attacks.</p>

<p>I think Another reason was the goal to be simple in the beginning. I know there is a lot of discussion to extend onion routing to HORNET which would create a connection oriented encrypted communication layer on top of the lightning network and routing protocol. This obviously yield some advantages but also complexity and possibilities to introduce exploits.
Let us remember that sphinx mix format was created to send and receive messages / emails and we "abuse" it for lightning. So I guess we liked at the core feature we needed. </p>

<p>I think the main reason for using the EOB field in spontaneous payments is that it was easy to implement this in the current system without too many changes. But to be sure roasbeef might give the exact reason. </p>

CC BY-SA 4.0
2019-04-26T19:05:02.980Z
2019-04-26T19:05:02.980Z
Rene Pickhardt
<p>It is useful to send some additional information with a payment in LN. For example, spontaneous payments in LND send a <code>payment_preimage</code> to the destination of a payment. LND uses a non-trivial <a href="https://github.com/lightningnetwork/lightning-onion/pull/31" rel="nofollow noreferrer">EOB</a> format to try and encode this information into the <code>hops_data</code>. The <code>hops_data</code> must be a fixed size to prevent intermediary nodes knowing where they are in a route, which limits the size of information which can be forwarded.</p>

<p>The <a href="https://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf" rel="nofollow noreferrer">Sphinx</a> protocol on which LN's onion routing is based already supports forwarding encrypted messages as a separate field. The notation <code>(M,δ)</code> is used for an onion message, where the <code>M</code> corresponds to the <code>onion_packet</code> format in <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#packet-structure" rel="nofollow noreferrer">BOLT4</a>. <code>δ</code> is the encrypted payload, which can be of arbitrary size, and is not used.</p>

<p>Would it not make more sense to utilize this message forwarding rather than trying to overcomplicate the protocol with the <code>EOB</code> format, which gains us a trivial number of bytes?</p>

<p>I can see that arbitrary size may be an issue for an attacker monitoring traffic flows. Perhaps <code>δ</code> can be made a fixed size and padded such that each <code>update_add_htlc_with_payload</code> remains a fixed size. We could potentially transfer larger and more useful information to the destination (in particular, I would like to be able to embed a refund invoice in the payment).</p>

<p>Are there any other issues with forwarding a separate encrypted payload which I'm unaware of?</p>

<lightning-network><lightning-network-daemon><sphinx>
Why are Sphinx forward messages not used in Lightning's onion packets?
Mark H
# Why are Sphinx forward messages not used in Lightning's onion packets?

(Asked by: username_0 on 2019-04-26)

It is useful to send some additional information with a payment in LN. For example, spontaneous payments in LND send a `payment_preimage` to the destination of a payment. LND uses a non-trivial [EOB](https://github.com/lightningnetwork/lightning-onion/pull/31) format to try and encode this information into the `hops_data`. The `hops_data` must be a fixed size to prevent intermediary nodes knowing where they are in a route, which limits the size of information which can be forwarded.

The [Sphinx](https://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf) protocol on which LN's onion routing is based already supports forwarding encrypted messages as a separate field. The notation `(M,δ)` is used for an onion message, where the `M` corresponds to the `onion_packet` format in [BOLT4](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#packet-structure). `δ` is the encrypted payload, which can be of arbitrary size, and is not used.

Would it not make more sense to utilize this message forwarding rather than trying to overcomplicate the protocol with the `EOB` format, which gains us a trivial number of bytes?

I can see that arbitrary size may be an issue for an attacker monitoring traffic flows. Perhaps `δ` can be made a fixed size and padded such that each `update_add_htlc_with_payload` remains a fixed size. We could potentially transfer larger and more useful information to the destination (in particular, I would like to be able to embed a refund invoice in the payment).

Are there any other issues with forwarding a separate encrypted payload which I'm unaware of?

**Tags:** lightning-network, lightning-network-daemon, sphinx


---

## 1 answers

### Answer by username_1 on 2019-04-26. Score: 1

Questions like these are always leading to an opinionated response and are a little bit tough to answer. I will give it a shot though.

First of all I think youelf already answered your question to an important degree. Forwarding messages via the SPHINX protocol yield the possibility of message length attacks.

I think Another reason was the goal to be simple in the beginning. I know there is a lot of discussion to extend onion routing to HORNET which would create a connection oriented encrypted communication layer on top of the lightning network and routing protocol. This obviously yield some advantages but also complexity and possibilities to introduce exploits.
Let us remember that sphinx mix format was created to send and receive messages / emails and we "abuse" it for lightning. So I guess we liked at the core feature we needed.

I think the main reason for using the EOB field in spontaneous payments is that it was easy to implement this in the current system without too many changes. But to be sure roasbeef might give the exact reason.


---

