Skip to content

Feature/electrum tor routing - #3

Open
atesfurkan wants to merge 18 commits into
masterfrom
feature/electrum-tor-routing
Open

atesfurkan wants to merge 18 commits into
masterfrom
feature/electrum-tor-routing

Conversation

@atesfurkan

Copy link
Copy Markdown
Owner

compile yap lan bunları , eror falan verme

binarybaron and others added 18 commits October 6, 2026 10:38
…llet#1218)

libp2p-rendezvous 0.14 loses the length prefix when a discover response
arrives in multiple reads, so mainnet discovery (~9.6 KB response) fails
with Unavailable. 0.15 uses the fixed quick-protobuf-codec 0.3.1.

Co-authored-by: binarybaron <user@mbp-von-user.speedport.ip>
…et#1212)

The EnvFilter directive built in init_tracing() reads "rendezvous_server=..."
but the package (and therefore the crate target tracing filters match
against) is named rendezvous-node / rendezvous_node. Because the directive
name never matches, EnvFilter silently drops every info/warn log the binary
itself emits in main.rs (PeerRegistered, DiscoverServed, etc.) while the
other correctly-named directives (swap_p2p, libp2p, ...) keep working, so
there is no visible error -- the binary just runs with its own events
invisible.

Verified on our own deployment: before this change, we saw zero "Peer
registered" / "Discovery served" lines despite the ASB successfully
registering against it. After rebuilding with the one-line fix, both lines
appeared on the very next restart.

(Testing/drafting assisted by Claude Code; the bug, fix and verification
above are our own.)

Co-authored-by: Pattayaguy <pattayaguy-stack@users.noreply.github.com>
eigenwallet#1222)

The discovery behaviour scheduled the next discovery request inside the
loop over the addresses of each registration. If the rendezvous point
returned no registrations, no next request was scheduled, and we never
asked that rendezvous point again until refresh() or a restart.

Schedule the next request once per answer, after the loop. Add a test in
which the first answer is empty and a maker registers afterwards.

Co-authored-by: binarybaron <mohan.gautam@staticlabs.de>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…nwallet#1224)

The event loop keeps an entry in registered_swap_handlers after the
swap's SwapEventLoopHandle is dropped (swap suspended, finished or
failed). A transfer proof for such a swap failed to send to the closed
channel, and the event loop then skipped the database checks. The proof
was not buffered, and a retried proof for a finished swap was not
acknowledged.

If the send fails, remove the stale entry and take the returned proof
through the same database checks as a swap without a handler.

Co-authored-by: binarybaron <mohan.gautam@staticlabs.de>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants