allow enable/disable proxy without nuking proxy mode, host and port (explicit enable_proxy config setting),
move tor probe from frontend to backend code, add probe buttons for Qt and QML
- 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
add space
add gossip address field serialization, parsing and tests
fix linter
consolidate tests, fix intendation
refactor test in loops
add gossip address field serialization, parsing and tests
Adds a new test case for e2e trampoline payment, where there are multiple
Trampoline Forwarders which themselves are not directly connected.
This adds a regression test for https://github.com/spesmilo/electrum/pull/9431dffdebf778
Ideally, given an on-chain backup, after the remote force-closes, we should be able to spend our anchor output,
to CPFP the remote commitment tx (assuming the channel used OPTION_ANCHORS).
To spend the anchor output, we need to be able to sign with the local funding_privkey.
Previously we derived the funding_key from the channel_seed (which comes from os.urandom).
Prior to anchors, there was no use case for signing with the funding_key given a channel backup.
Now with anchors, we should make its derivation deterministic somehow, in a way so that it can
be derived given just an on-chain backup.
- one way would be to put some more data into the existing OP_RETURN
- uses block space
- the OP_RETURNs can be disabled via "use_recoverable_channels"
- only the initiator can use OP_RETURNs (so what if channel is in incoming dir?)
- instead, new scheme for our funding_key:
- we derive the funding_privkey from the lnworker root secret (derived from our bip32 seed)
- for outgoing channels:
- lnworker_root_secret + remote_node_id + funding_tx_nlocktime
- for incoming channels:
- lnworker_root_secret + remote_node_id + remote_funding_pubkey
- a check is added to avoid reusing the same key between channels:
not letting to user open more than one channel with the same peer in a single block
- only the first 16 bytes of the remote_node_id are used, as the onchain backup OP_RETURNs only contain that
- as the funding_privkey cannot be derived from the channel_seed anymore, it is included in the
imported channel backups, which in turn need a new version defined
- a wallet db upgrade is used to update already stored imported cbs
- alternatively we could keep the imported cbs as-is, so no new version, no new funding_privkey field, as it is clearly somewhat redundant given on-chain backups can reconstruct it
- however adding the field seems easier
- otherwise the existing code would try to derive the funding_privkey from the channel_seed
- also note: atm there is no field in the imported backups to distinguish anchor channels vs static-remotekey channels
* sets the weight of htlc transactions to zero, thereby putting a zero
fee for the htlc transactions
* add inputs to htlc-tx for fee bumping
* switches feature flags
* disable anchor test vectors, which are now partially invalid
* to_remote has now an additional csv lock of 1
* anchor outputs are added if to_local/remote outputs are present
* funder balance is reduced to accomodate anchors
* changes the htlc outputs' witness script to have a csv lock of 1
* send signatures for remote ctx with ANYONECANPAY|SINGLE
* refactor htlc weight (useful for zero-fee-htlc)
- Separation between SwapManager and its transport:
Legacy transpport uses http, Nostr uses websockets
- The transport uses a context to open/close connections.
This context is not async, because it needs to be called
from the GUI
- Swapserver fees values are initialized to None instead
of 0, so that any attempt to use them before the swap
manager is initialized will raise an exception.
- Remove swapserver fees disk caching (swap_pairs file)
- Regtests use http transport
- Android uses http transport (until QML is ready)
- Wait until HTLCs are irrevocably removed before cleaning up their
data structures (MPP and forwarding)
- keep methods maybe_cleanup_mpp and maybe_cleanup_forwarding separate
- perform cleanup in htlc_switch, so that process_unfulfilled_htlc
has less side effects
- In htlc_switch, we blank the onion_packet_hex field to signal that
an HTLC has been processed. An item of chan.unfulfilled_htlcs may
go through 4 stages:
- 1. not forwarded yet: (None, onion_packet_hex)
- 2. forwarded: (forwarding_key, onion_packet_hex)
- 3. processed: (forwarding_key, None), not irrevocably removed yet
- 4. done: (forwarding_key, None), irrevocably removed
- in test_lnpeer, an extra iteration of htlc_switch has been added to
trampoline forwarding tests
If we accept a MPP and we forward the payment (trampoline or swap),
we need to persist the payment accepted status, or we might wrongly
release htlcs on the next restart.
lnworker.received_mpp_htlcs used to be cleaned up in maybe_cleanup_forwarding,
which only applies to forwarded payments. However, since we now
persist this dict, we need to clean it up also in the case of
payments received by us. This part of maybe_cleanup_forwarding has
been migrated to lnworker.maybe_cleanup_mpp
This will be useful if we decide to ship lntransport as a separate
package. It is also a conceptual cleanup.
Notes:
- lntransport still requires crypto.py
- parsing node id from a bolt11 invoice is not supported.
```
=============================== warnings summary ===============================
tests/test_wizard.py::ServerConnectWizardTestCase::test_no_advanced
tests/test_wizard.py::ServerConnectWizardTestCase::test_proxy
tests/test_wizard.py::ServerConnectWizardTestCase::test_proxy_and_server
tests/test_wizard.py::ServerConnectWizardTestCase::test_server
tests/test_wizard.py::WalletWizardTestCase::test_2fa
tests/test_wizard.py::WalletWizardTestCase::test_create_standard_wallet_haveseed_bip39
tests/test_wizard.py::WalletWizardTestCase::test_create_standard_wallet_haveseed_electrum
tests/test_wizard.py::WalletWizardTestCase::test_create_standard_wallet_newseed
/tmp/cirrus-ci-build/.tox/py3/lib/python3.10/site-packages/_pytest/threadexception.py:82: PytestUnhandledThreadExceptionWarning: Exception in thread Plugins
Traceback (most recent call last):
File "/usr/local/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
self.run()
File "/tmp/cirrus-ci-build/electrum/plugin.py", line 360, in run
self.on_stop()
File "/tmp/cirrus-ci-build/electrum/util.py", line 430, in on_stop
loop = get_asyncio_loop()
File "/tmp/cirrus-ci-build/electrum/util.py", line 1578, in get_asyncio_loop
raise Exception("event loop not created yet")
Exception: event loop not created yet
warnings.warn(pytest.PytestUnhandledThreadExceptionWarning(msg))
```
