increase read timeouts when tor is configured
What changed, and why it matters
This commit adjusts network waiting periods when Sparrow Wallet connects to a Bitcoin server through the Tor privacy network. It gives Tor connections slightly more time before retrying, likely to reduce false failures caused by Tor's slower routing. There is no indication this fixes an exploitable security flaw.
No security action required. Treat as a routine reliability/usability improvement. Users on Tor may experience fewer spurious connection timeouts.
Security signals we found
No memory-unsafe operations, cryptographic changes, or input parsing changes
No authentication, authorization, or validation logic modified
Change is purely a network-timeout tuning adjustment
No vendor statement or advisory describes this as a security fix
Evidence from the diff
The change introduces a new TOR_READ_TIMEOUT_SECS array ({5, 10, 20, 34}) and selects it whenever a proxy is configured, while keeping SLOW_READ_TIMEOUT_SECS for direct Bitcoin Core onion connections and BASE_READ_TIMEOUT_SECS for non-proxy connections. The logic is otherwise unchanged; only timeout values are tuned.
Changed components
src/main/java/com/sparrowwallet/sparrow/net/TcpTransport.javaInspect captured patch +10 / −2
diff --git a/src/main/java/com/sparrowwallet/sparrow/net/TcpTransport.java b/src/main/java/com/sparrowwallet/sparrow/net/TcpTransport.java
index 8ba70ff..99da1f7 100644
--- a/src/main/java/com/sparrowwallet/sparrow/net/TcpTransport.java
+++ b/src/main/java/com/sparrowwallet/sparrow/net/TcpTransport.java
@@ -32,6 +32,7 @@ public class TcpTransport implements CloseableTransport, TimeoutCounter {
public static final int DEFAULT_MAX_TIMEOUT = 34;
private static final int[] BASE_READ_TIMEOUT_SECS = {3, 8, 16, DEFAULT_MAX_TIMEOUT};
+ private static final int[] TOR_READ_TIMEOUT_SECS = {5, 10, 20, DEFAULT_MAX_TIMEOUT};
private static final int[] SLOW_READ_TIMEOUT_SECS = {34, 68, 124, 208};
public static final long PER_REQUEST_READ_TIMEOUT_MILLIS = 50;
public static final int SOCKET_READ_TIMEOUT_MILLIS = 5000;
@@ -71,8 +72,15 @@ public class TcpTransport implements CloseableTransport, TimeoutCounter {
this.server = server;
this.socketFactory = (proxy == null ? SocketFactory.getDefault() : new ProxySocketFactory(proxy));
- int[] timeouts = (Config.get().getServerType() == ServerType.BITCOIN_CORE && Protocol.isOnionAddress(Config.get().getCoreServer()) ?
- Arrays.copyOf(SLOW_READ_TIMEOUT_SECS, SLOW_READ_TIMEOUT_SECS.length) : Arrays.copyOf(BASE_READ_TIMEOUT_SECS, BASE_READ_TIMEOUT_SECS.length));
+ int[] baseTimeouts;
+ if(Config.get().getServerType() == ServerType.BITCOIN_CORE && Protocol.isOnionAddress(Config.get().getCoreServer())) {
+ baseTimeouts = SLOW_READ_TIMEOUT_SECS;
+ } else if(proxy != null) {
+ baseTimeouts = TOR_READ_TIMEOUT_SECS;
+ } else {
+ baseTimeouts = BASE_READ_TIMEOUT_SECS;
+ }
+ int[] timeouts = Arrays.copyOf(baseTimeouts, baseTimeouts.length);
if(Config.get().getMaxServerTimeout() > timeouts[timeouts.length - 1]) {
timeouts[timeouts.length - 1] = Config.get().getMaxServerTimeout();
}
Why this scored 21/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.