Onion message follow-ups

Force users to use path_id
Enable the addition of dummy blinded hops for increased privacy
On creation, pad blinded route hops to be equal length
Support 1-hop blinded paths
Rate limit based on channel vs non-channel peers
Rate limit based on outbound peer buffer limits
Refuse to send onion messages to offline peers and drop forwards to offline peers
Config option for forwarding over channels-only
Custom TLVs, sending-side + handler on receiving side
Implement BOLT spec test vectors
Consider setting max number of hops before refusing to send
Custom get_route for finding an OM path (current get_route has a lot of custom stuff for payments)
Flip on OM feature bit (may want to conditionally flip based on whether a user has an OnionMessenger)
Refactor onion_utils::construct_onion_packet_with_init_noise to take one Vec instead of two
Minor: make onion_utils::decode_next_hop private, see Onion messages v1 #1503 (comment)
Add fuzz testing
Don't disconnect peers on garbage onion messages (cc Onion messages v1 #1503 (comment))

Support receiving onion messages to phantom nodes.

Support receiving onion messages to phantom nodes.

Need to have a fuzzer for reading/decoding/forwarding onion messages before we can ship it, I think.

Maybe clean up API a bit, re #1503 (comment)

Due to recent spec updates forcing the use of blinded paths, we'll want to support 1-hop blinded paths now too.

If nobody is working on it, I'd like to attempt adding the OM test vectors - as requested here.

We should presumably include padding (someone taking over #1771) no?

We should presumably include padding (someone taking over #1771) no?

Yeah, that would be good. That's included in the issue already, if that's what you mean.

Navigation Menu