- test_reestablish_fake_data: add 3-attempt retry per pay_invoice call to handle
asyncio event-loop pressure on sequential payments
- test_htlc_switch_iteration_benchmark: raise timeout 2s → 5s
- test_payment_multipart_trampoline_e2e: attempts 1 → 3
- _run_trampoline_payment: default attempts 2 → 5; add outer retry loop catching
NoPathFound (raised when all fee levels fail, bypassing the attempts counter)
- test_mpp_expiry (anchor): replace fixed asyncio.sleep with a polling loop that
waits until bob has received both HTLCs before asserting MPP state
The send_queue and forward_queue loops were doing put_nowait + sleep(SLEEP_DELAY)
+ get() to re-schedule not-yet-due messages. Under asyncio scheduler pressure the
get() can stall after the item was already put back, causing test_request_and_reply
to time out. Replaced with call_later(remaining, queue.put_nowait, item) which
schedules the re-insertion at the exact due time without any polling.
Two fixes:
1. test_trampoline_mpp_consolidation: set dave.MPP_EXPIRY=120 when
test_mpp_consolidation=True. With MPP_EXPIRY=2s and sequential HTLC
commitment rounds, Dave times out before the second HTLC arrives.
2. test_reestablish_fake_data: use explicit Task references in the
payment setup phase so that loop tasks (message loops, htlc_switch)
are cancelled in a finally block regardless of whether pay() succeeds
or raises. Without this, asyncio.gather leaves orphaned tasks running
across sub-test iterations when a payment fails, causing interference
get_target(): replace hardcoded Bitcoin constants (CHUNK_SIZE, 14-day
timespan, module-level MAX_TARGET) with per-chain values from constants.net.
Handle POW_GENESIS_BITS so that chains whose genesis nBits differs from
target_to_bits(MAX_TARGET) return the correct initial difficulty for period 0.
Map checkpoint indices correctly when adj_interval != CHUNK_SIZE.
verify_chunk(): add a separate code path for chains where the retarget
interval is shorter than CHUNK_SIZE (e.g. BTCP: 120 vs 2016). In this
case multiple retargets can occur within a single chunk; because the headers
are not yet on disk during verification, reading via read_header() would
raise MissingHeader and reject the entire chunk. Fix by reading from the
in-memory data buffer via a local helper _read_hdr(), and tracking
current_target across period boundaries inline.
can_connect(), chainwork_of_header_at_height(): use adj_interval instead of
CHUNK_SIZE when computing the difficulty-period index so that BTCP's 120-block
retarget windows are respected
If a trampoline forwarder fails to find a path, it may return a list
of trampolines it knows how to reach, so that clients can add these
trampolines to their route.
The list of trampolines and fees is written in the error data of
the 'update_fail_htlc' message.
The LnAddr, lndecode and lnencode naming didn't imply that it is
bolt 11 specific, making it confusing to work with, now that there are
also bolt 12 "lnaddr".
Renaming it to *bolt11* creates a clear separation to bolt 12 things and
reduces mental load.
This commit is pure renaming (using the PyCharm IDE refactor function),
except for the removal of the `object` inheritance of LnAddr/BOLT11Addr,
this is Python 2 legacy.
When the user enters something into the ElTextArea the placeholder
text should be hidden so it doesn't conflict with the user input.
This affects e.g. the lnurl pay dialog.
Handle `TrampolineEdge` with known fees when allocating fees to
`TrampolineEdge` with `PLACEHOLDER_FEE` during trampoline route
construction.
This allows to create a mixed route from edges where we know the exact
feerates (e.g. provided through lazy trampoline) and evenly spread the
remaining budget between the edges where the fees are unknown (`PLACEHOLDER_FEE`).
Co-Authored-By: SomberNight <somber.night@protonmail.com>
Send more types of exceptions happening during daemon.load_wallet
in `ElectrumGui.start_new_window()` to the crash reporter to catch
e.g. assertion failures instead of showing them to the user as a warning
dialog.
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.
davide
SomberNight