Sending onion_message using HTLCs

[yyforyongyu]

Not sure if this has been discussed elsewhere, while onion_message is cool as it enables BOLT12 invoice, it treats every node in the network as a "free" resource when it comes to forwarding OMs, hence opening a new DoS attack vector. Instead of allowing any node to send an OM, we should restrict it from being sent over a connection that has a channel open. Moreover, this onion_message should be sent using HTLCs to pay the forwarding nodes via fees.

This means the BOLT12 now has the following workflow,

1. The merchant publishes an offer.
2. The user sends an OM that contains the invoice request wrapped inside an HTLC to the merchant.
3. The merchant replies with an invoice using an OM wrapped inside an HTLC to the user.

The HTLC amount can be very small, i.e., only enough sats to pay the routing fees. The disk size of this HTLC will be larger, but forwarding nodes can quickly remove the OM once done. By using HTLCs to forward OMs there are several advantages,

1. LN is made for this - we use micropayments to price the forwarding actions and reduce spam.
2. OMs are more reliable since forwarding nodes are paid, and we can use the existing pathfinding algorithms for OMs.
3. It's a better layering - we don't need to question/prevent the potential DoS vector and it's deduced into the HTLC level.

The downside,

1. The end nodes can choose to not settle the HTLCs after extracting the OMs - this could be mitigated by channel jamming?
2. The size of HTLCs will be increased - the OMs could be dropped once forwarded.
3. It now requires inbound liquidity to send BOLT12 payments.

Thoughts?

[yyforyongyu]

Apparently this idea is not new😂

[TheBlueMatt]

hence opening a new DoS attack vector.

[citation needed]

Moreover, this onion_message should be sent using HTLCs to pay the forwarding nodes via fees.

This wastes like three orders of magnitude more resources. No.

[t-bast]

Agreed with Matt here, this was already raised a few times in the past, and is IMO a bad idea. Onion messages are very cheap to process, it's trivial to restrict them to pairs of nodes that have a channel and rate-limit them, and we have a very simple proposal for statistically limiting spam: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003623.html