bolts
bolts copied to clipboard
BOLT 7: Onion message support (features 38/39)
These use onion encoding for simple one-way messaging: there are no error returns.
Any reply is done with an enclosed blinded path, a-la @t-bast (in fact, this is based on #765)
Note that this defines the message system, not the contents of messages (e.g. invoice requests from offers).
Got really confused trying to understand how this proposal and https://github.com/lightningnetwork/lightning-rfc/pull/755 are related: is one a later version of the other?
Got really confused trying to understand how this proposal and #755 are related: is one a later version of the other?
Oops, they were (almost!) identical. I closed the prior one since this one has comments.
I'm rebasing on master now, having applied the typo fixes (thanks!).
My only q is whether we should drop the reply_path
and put that inside whatever the payload being delivered is. For invoice requests we already have such a field, so it would be easy, and simplify the onion message proposal markedly.
The downside is that you can't reply with an error if the payload itself is unparsable...
Trivial squash and rebase on master.
Hmm, should we give this a real feature number?
Since we're now tentatively self-assigning incremental feature numbers, I'm switching this to 38/39.
OK, this is the simplified version, FTW. I'm implementing it now: for the moment c-lightning will accept and send the old version too, to ease transition.
Thanks @TheBlueMatt !
OK, I renumbered a field and added enctlv test vectors. There should be more (particularly invalid ones!), and there should be full onion test vectors too.
OK, I squashed all the previous fixes into a single commit, and rebased on #765!
I have also renumbered it to 513 from the old number in the gossip range, and moved the message definition into BOLT 4.
You're right the old test vectors are redundant, but I'll simply update them for now, once I've updated c-lightning!
OK, minor tweaks. I've not put the meta-suggestion on how to assign payload numbers, but I've made it clear it's 64+ (we may eventually assign 1024+ for experimental I guess?).
- onion_msgpayload encrypted_data_tlv is type 4, not 10.
- enctlv in path is now called
encrypted_recipient_data
which is consistent. - Removed setting of onionmsg feature in invoices.
IMO the test vector we include here should be a complete
onion_message
over a few hops, with areply_path
and a matching responseonion_message
from the recipient. I'll sync with @thomash-acinq on that, maybe we can propose such a test vector ourselves.
@rustyrussell has already sent me such test vectors (you can see them here: https://github.com/ACINQ/eclair/pull/2065) but I think he wanted to rewrite these test vectors to use the exact same scenario as in the blinded routes test vectors.
May I also add to the spam prevention discussion that there is the article: "Point Break: A Study of Bandwidth Denial-of-Service Attacks against Tor" (paper, video presentation) which suggests that bandwidth denial of service attacks work if the attacker requests large files but does not read on the TCP-socket to the exit node. in this way the attacker can - for relatively low bandwidth cost - produce a large load on the network. I believe that the small fixed size for onion messages doesn't yield a similar risk for cheap bandwidth denial of service attacks as the attacker would have to pay roughly for the same bandwidth.
For additional context I wish to add that TOR has - as you all probably know - an entire DoS Mitigation Subsystem which is described at https://gitlab.torproject.org/legacy/trac/-/issues/24902 and https://www.mail-archive.com/[email protected]/msg11628.html
@lightning-developer thanks a lot for the route blinding review!
If it's not too annoying, could you please move the comments that are only related to route blinding to its dedicated PR (#765) so that we keep discussions here about onion messages only?
I'll gladly answer your route blinding feedback on #765
Additionally given the context of rate-limiting and spam prevention I was wondering if we should not require an existing payment channel to send / receive an onion message from a peer?
If you do this, you can't deliver an onion message directly to a destination if you don't have a channel with them. You'd need to rely on forwarding nodes being available.
Additionally given the context of rate-limiting and spam prevention I was wondering if we should not require an existing payment channel to send / receive an onion message from a peer?
If you do this, you can't deliver an onion message directly to a destination if you don't have a channel with them. You'd need to rely on forwarding nodes being available.
Oh I see the misunderstanding. I thought this was meant for forwarding and processing of onion messages. Let's say we have a channel graph A-->B-->C-->D
and A
wanted to send an onion message to D
I thought this would be possible. In particular D
SHOULD accept the message even though it is not a direct peer of A
. If we however had another node M
peering with A
with no channel I thought M
should not be able to send an onion message via A
to other nodes.
AFAIU; The proposed onion messages use an onion routing mechanism similar to the one payments use to forward HTLCs. But the flow of forwarding an onion message is not related somehow to any amount forwarding. Why would a node opt-in to this? Other nodes might eat up your bandwidth and you don't have something to earn from that.
But the flow of forwarding an onion message is not related somehow to any amount forwarding. Why would a node opt-in to this? Other nodes might eat up your bandwidth and you don't have something to earn from that.
For many reasons:
- it's extremely cheap (no storage required, low cpu costs and messages below 65kb)
- it's trivial to rate-limit (we will publish a simple and efficient scheme soon)
- it helps your node attract more payments, which will earn you fees (e.g. by helping users fetch bolt 12 invoices that they will then pay)
- it's ok if some nodes are unhappy with these trade-offs and don't turn the feature on
For many reasons:
- it's extremely cheap (no storage required, low cpu costs and messages below 65kb)
- it's trivial to rate-limit (we will publish a simple and efficient scheme soon)
- it helps your node attract more payments, which will earn you fees (e.g. by helping users fetch bolt 12 invoices that they will then pay)
- it's ok if some nodes are unhappy with these trade-offs and don't turn the feature on
All four arguments are very strong. I want to focus a bit more on the 3rd one as far as rewards go. Can you elaborate more (or possibly link to a document) on explaining this payment attraction? Does the route carrying the bolt12 invoice also bind a route for the payment?
But apart from that, if one wants to use the onion messaging to transmit data related to a use-case of their own (unrelated to any LN operation) then there is no direct compensation to the nodes forwarding that traffic. Yes this can be rate limited, but that's more of a protection measure from the side of the routing node, exposing the node sending the messages to unreliable forwarding. I also think this PR is not introducing some kind of receipt to let the message sender know if a message arrived or not, which can also help make things complicated from the sender's PoV.
So I suppose in a next iteration of onion messaging, perhaps in an attempt to make it more reliable, a reward system would have to be introduced. This would incentivize nodes not only to opt-in to this feature, but also provide very good services by e.g maintaining a very stable/fast internet connection.
Mostly I want to wrap this up by comparing two possible paths one can follow to send (generic purpose) messages (of relatively small size) over Lightning:
- Onion messaging; requires protocol update, lightweight forwarding, no forwarding reward, requires whole route to opt-in, (?) no receipt for message arrival, (?) would require introduction of a new reward system for reliability
- Messaging over payments: no protocol update, dirtyish forwarding (DBs can optimize), forwarding reward is payment reward (effectively the base fees), no need for route opt-in, preimage is receipt, costs
In case second bullet wasn't clear, I'm referring to attaching custom TLV records to the destination of a payment. One of the reasons I'm focusing so much on direct reward is because I truly believe that this will scale the adoption and make messaging more reliable, regardless of which path one chooses.
OK, rebased on latest https://github.com/lightning/bolts/pull/765, folded all previous fixes, and added a commit which addresses all previous feedback.
I need to rework the test vectors: route blinded has excellent vectors and so we just need incremental ones on that.
Rebased on the latest #765, and added three new commits:
- Rework it into a single section, rather that splitting the "onion payload" from the "onion message" itself.
- Add a quick note that we don't use associated data (unlike payments, which use the payment_hash)
- Remove old test vectors, insert shiny new complete ones in same style as blinded payment onion tests.
Rebased again! And added a final commit:
- Changed the type of reply_path to use the bolt12 type (thanks @jkczyz).
- Renamed onionmsg_path to more accurate onionmsg_hop.
Fairly trivial rebase on top of updated https://github.com/lightning/bolts/pull/765, and fixup to make test vector reproducible!
Changes applied, and rebased.
OK, I squashed into a single commit and fixed some whitespace (and changed a "MUST send an error" to "MUST ignore" for consistency).
This now applies directly onto master now blinded payments are merged!
@valentinewallace can you have a look at the latest state of the PR (and ideally the test vectors)? If everything looks good, we can (finally) merge this!
I figure that this topic has been raised somewhere, but isn't the Onion Messaging system a potential DOS vector? If that discussion was resolved, is the documentation of that discussion in a different place? I am trying to catch up on the state of this and BOLT12 and IIRC this was an open point of debate for a while.
Should onion messages get added here? https://github.com/lightning/bolts/blob/master/01-messaging.md?plain=1#L473
Agreed to merge pending @valentinewallace acking test vectors.
Merged by agreement at 31-07-2023 meeting.
adding link to spec meeting where this was merged #1098
I figure that this topic has been raised somewhere, but isn't the Onion Messaging system a potential DOS vector?
Responding to myself here to document the resolution of this. The current assessment is that the bandwidth of onion messages required for "proper usage" with BOLT12 is fairly low, and implementations are advised to implement some basic rate limiting to mitigate this. Rate-limiting strategy is left as an exercise to the implementer.