Remove the hops data encryption from the blinded path branch of
send_onion_message_to. Our hops data is already encrypted before
and the blinded paths hops data is already encrypted by the recipient,
so this is a no-op.
Also use encrypt_hops_recipient_data in create_route_to_introduction_point,
it does the same as the existing encryption step.
Don't include first hop of the path,
this is the hop from us to the first node and we don't
need a payload for ourselves.
Also adds unittest checking this.
Factor out code from `send_onion_message_to` into a separate
function `_create_route_to_introduction_point` to make it
easier to reason about it and more testable.
This allows restricting blinded paths to channels that have sufficient receive
capacity for payment.
NOTE: this might have privacy issues, as this can be used to probe channel capacity.
Maybe randomize leeway?
@f321x: changed to use scid alias in create_blinded_path
- LNWallet no longer "is-an" LNWorker, instead LNWallet "has-an" LNWorker
- the motivation is to make the unit tests nicer, and allow writing unit tests for more things
- I hope this makes it possible to e.g. test lnsweep in the unit tests
- some stuff we would previously have to write a regtest for, maybe we can write a unit test for, now
- in unit tests, MockLNWallet now
- inherits LNWallet
- the Wallet is no longer being mocked
- check on initial_node_id as the type can in theory contain a sciddir.
- log allowed_features if present in recipient_data, with an additional comment describing
the handling of allowed_features in the future.
- document the SHOULD constraint on onion_message payload size
This renames lnmsg._{read,write}_field to lnmsg._{read,write}_primitive_field, renames
LNSerializer._{read,write}_complex_type to LNSerializer.{read,write}_field and allows
LNSerializer.{read,write}_field to handle both primitive and complex types.
Also makes these funcs public, as these encodings are used outside of lnmsg as well
(e.g. encoding blinded paths in BOLT12 invoice_request)
The name 'requestreply' do not mean anything. If something can either
be a request or a reply, perhaps we can call it 'message', instead of
introducing a new name?
In general, coming up with new names comes at a cost, because you
are forcing other developers to learn and use your terminology.
Please minimize that.
1. Do not pass request_reply_timeout and request_reply_retry_delay
to OnionMessageManager.
Arguments passed to a function are useful only if their value might
change during the execution of a program. If that is not the case,
it is preferable to define them as constants. That makes the code
easier to read, because the reader can focus on arguments that are
actually relevant.
2 . Multiply all time constants by the same factor, instead
of doing so incompletely and on a per parameter basis. (note
that before this commit, the speedup factor was not consistent)
3. Do not use util.now(), because it is rounded as integer.
With these changes, the tests can effectively run with a 100x speedup
f321x