running a watchtower requires to be able to run a daemon with the
watchtower plugin enabled. If users succeed at doing that, we
can expect them to be able to configure theclient using the
command line.
(that would not work with QML, though. maybe QML could use an
advanced config editor)
- if we show error for LN request, we should also show error for LN-only bip21 URI
follow-up af0ac40478
- for LN request, show better error msg if don't have any channels
closes https://github.com/spesmilo/electrum/issues/9413
note: would be nice if qml GUI could reuse this logic (wallet.get_help_texts_for_receive_request)
- 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
