window.run_coroutine_from_thread starts a coroutine on the asyncio loop,
which, when finishing, pops from the dict.
The for loop in clean_up is running on the Qt thread.
fixes https://github.com/spesmilo/electrum/issues/7983
ThomasV had libffi installed via brew, and this side-effected the built electrum dmg.
`('libffi.8.dylib', '/usr/local/opt/libffi/lib/libffi.8.dylib', 'BINARY')`
this was the cause of 019d213325
Before this commit, partial results were yielded before we had
examined the whole split configuration.
I think the correct behaviour is to create all the routes for the
current configuration, then to yield them. If there is an exception,
we should try the next one.
Upon receiving UNKNOWN_NEXT_PEER, TEMPORARY_NODE_FAILURE
or TEMPORARY_CHANNEL_FAILURE, remember the trampoline route
that was used, and try other routes before raising the
trampoline fee.
Before this commit, we used to raise the trampoline fee
upon receiving any error message, in order to ensure
termination of the payment loop.
Note that we will still retry failing routes after we have
raised the trampoline fee. This choice is questionable, it
is unclear if doing so significantly increases the probability
of success.
Tests: add a test for trampoline handling of UNKNOWN_NEXT_PEER
(This was added in 3a7f5373ac. Not sure what the reason is, but
it triggers UNKNOWN_NEXT_PEER errors, that in turn affect routing
choices, e.g. fallback to single trampoline route)
Replace get_key_for_outgoing_invoice, get_key_for_incoming_request
with Invoice.get_id()
When a new request is created, reuse addresses of expired requests (fixes#7927)
The API is changed for the following commands:
get_request, get_invoice,
list_requests, list_invoices,
delete_request, delete_invoice
`wallet.make_unsigned_transaction` can raise NotEnoughFunds or NoDynamicFeeEstimates.
These are "expected" exceptions that need to be handled or worked around. Added a note
of this in the docstring now.
We now handle NoDynamicFeeEstimates by allowing a static fallback fee in
`wallet.can_pay_onchain` and `lnworker.suggest_funding_amount`. It should be
fine to have a static fallback in these cases, as the user still has a chance
to set their own fee later in the flow.
(though ofc the static fallback might be too high in some mempool conditions,
in which case e.g. can_pay_onchain might return a false-negative, but this
is still an improvement over raising I believe)
fixes https://github.com/spesmilo/electrum/issues/5784
SomberNight
ThomasV
Arian Ventura Rodríguez
Sander van Grieken
Jamie C. Driver