[bisq-network/bisq] Bisq disconnected from local btc node (#1823)

Oscar Guindzberg notifications at github.com
Sat Dec 15 23:27:01 UTC 2018


- I have looked at this issue a couple of weeks ago, I will leave my comments here in case anyone wants to revisit this problem.
- About “It looks like bisq remembers that localhost btc node was banned”: 
  - I don’t think so and I don’t think bitcoin core is banning bitcoinj either.
  - I searched “DoS” and “Denial of Service” in bitcoin core release notes and mailing list: nothing relevant found.
  - I did not find any signs of DoS detected nor that bitcoinJ peer was disconnected by core on bitcoin core logs. 
- Steps to reproduce the problem
  - Start a bisq node (code previous Manfred’s update of checkpoints) on a mac from intellij with an empty data dir connected to a local bitcoin core 0.17.0.1 testnet.
  - That makes bisq CPU consumption to skyrocket (over 100%). It also takes as much RAM as it can. During 1-3 minutes during and after bitcoinj blockchain sync. 
  - I think this might cause some/all the problems I will describe later.
  - Debug from intellij makes things even worse... OutOfMemoryError and desktop freezing.
  - The problem was not reproduced connecting to random peers on the bitcoin testnet network.
- I think updating the checkpoints is a patch, probably a good patch. But the problem is still there. 
  - If a new version of bisq with updated checkpoints is not released often or a user uses an old bisq version, the problem will show up again.
  - If a user uses the “recover from seed” feature with an old seed the problem will show up no matter she is using the latest bisq version.
- The real cause of the CPU/RAM spike is yet to be discovered.
  - Here are some ideas to explore...
  - jdk 10. I know Manfred says he could reproduce the bug with old bisq releases before the upgrade to jdk 10 and the problem is still there. I would double check bisq executable isn’t using operating system default jdk (ie 10) instead of the jdk embedded in the executable (ie 8).
  - Bad thread management. I am not saying deadlock, but there might be stuff on hold that should not be on hold (maybe waiting for chain sync complete when it should not).
- Then I detected other problems...
- UI chain sync progress tracker is behind bitcoinj log progress tracker. 
  - When command line log progress tracker reaches 100%, UI tracker shows a smaller % and after a “while” it says to be fully synced.
  - Theories:
    - UI tracker is updated when a new block is received
    - UI trackeris updated when bisq cpu consumption goes down and the UI thread can refresh the screen.
- “Block does not connect” printed on the logs.
  - log shows
    - AbstractBlockChain.add: Block does not connect: ...
    - AbstractBlockChain.tryConnectingOrphans: Connected orphan …
    - AbstractBlockChain.tryConnectingOrphans: Connected 1 orphan blocks.
  - Those log messages where printed because bitcoinj blockchain processed the child block first and then its parent.
  - Theories
    - bitcoinj received them on the opposite order. Then the question would be why core is sending blocks not in the right order. One thing to investigate is: during bitcoinj chain sync, if core receives a new block, does it forward it to bitcoinj? 
    - bitcoinj node receives the blocks in order but somehow it passes them to th Blockchain class in the wrong order.
    - Something related to the cpu/ram spike.
  - I have seen this behavior before on other projects that use bitcoinj too (last block processed before its parent) but I have never paid too much attention because it was harmless to my use case at the time.
- When block download completes localhost peer is disconnected and reconnected
  - This is what @iljah originally reported as a problem. Log shows “Download peer died. Picking a new one.”
  - After the chain is fully synced PeerGroup.ChainDownloadSpeedCalculator keeps running once per second.
  - For some reason (to be found out) "behindPeers" variable is still true, so it makes ChainDownloadSpeedCalculator keep running.
  - After a while, since no new blocks are received (because the blockchain is in sync) ChainDownloadSpeedCalculator thinks the peer is not sending blocks at the speed it should, prints “Chain download stalled” and disconnects the peer
  - Later, bitcoinj reconnects to the same peer.
  - Theories of why "behindPeers" variable is still true after blockchain sync is complete:
    - Nonproblematic random race conditions.
    - Something related to the cpu/ram spike.
  - Again, I remember my bitcoinj node disconnecting and reconnecting to my local QT on other projects and did not pay much attention to it at the time. 


-- 
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/1823#issuecomment-447605289
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20181215/cd109dfb/attachment.html>


More information about the bisq-github mailing list