[bisq-network/bisq] Support manual bitcoin node disconnection and reconnection (#4778)

Chris Beams notifications at github.com
Tue Nov 10 11:00:25 CET 2020


_The following feature request is based on a Keybase discussion between @cbeams and @ripcurlx beginning at keybase://chat/bisq#dev/3915._

## Description

Assuming a Bisq node is connected to two or more Bitcoin nodes (as seen at `Settings > Network Info > Bitcoin network`):

1. indicate to the user which node is currently live (i.e. which one is being actively used for sending and receiving data), and 
2. afford the user the option to drop the current live connection and connect to another Bitcoin node in the group.

## Rationale

The idea for this feature came up when attempting to synchronize a 2+ year-old Bisq node after deleting its SPV file. The synchronization started out just fine, receiving on the order of 20–30 blocks/sec, but this rate eventually dropped to zero. After nearly 24 hours, the synchronization attempt was aborted, and the troubleshooting process that led to this issue began. Here's what was learned:

For unknown reasons, it appears that a throttling effect occurs when attempting to download blocks from most or all of the Bisq federation of Bitcoin Core nodes. I found this was true against my own local node as well. The download rate starts out high enough, again around 20–30 block/sec, and then falls off to near-zero after a certain time.

BitcoinJ watches this throughput, and if it drops below a certain threshold (<0.78K/sec for 10 sec), BitcoinJ considers the connection to that node "stalled", drops the connection and connects to a different node in the current `PeerGroup`. When this happens, the block download rate jumps up again, and then after a while drops off to near zero.

BitcoinJ is hard-coded to perform only 3 of these "stall disconnects" (see `maxStalls` in `PeerGroup.java`), after which the behavior is disabled, and the user is stuck staying connected to the current (throttled) node. This can result in never being able to complete synchronization, and was in fact what happened in my case.

A workaround is to drop one's local network connection long enough for BitcoinJ to consider all connections lost, and then to reconnect. When reconnecting, BitcoinJ selects a peer randomly, and in my observed experience, the block/sec download rate jumps back up to normal levels. One can then repeat this workaround as many times as is necessary to complete synchronization.

Better than this would be to allow the user to force dropping and reconnecting with a button or other affordance as described above.

Ultimately, the root of the problem is the apparent throttling behavior. I've asked (in Keybase) the @bisq-network/btcnode-operators whether they have any idea what might be causing it, but even if we solve that mystery, the ability to manually drop and reconnect to Bitcoin nodes would probably be a useful troubleshooting tool.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/issues/4778
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201110/cf896941/attachment.html>


More information about the bisq-github mailing list