bitcoind connection lost during syncing #116

k3tan172 · 2022-05-30T08:39:31Z

Below is a comment I received.

"I keep getting bitcoind connection lost during syncing. Is this normal, and should I continue to let this run? It will now only process a height once every hour or so. Has anyone else had this issue, and if so what do you do in this situation? This is my 5th attempt at installing Fulcrum. Any help would be greatly appreciated."

May 30 06:55:00 sovereign1 Fulcrum[1686]: [2022-05-30 06:55:00.771] <Controller> Task errored: Task.DL 361020 -> 738534, error: bitcoind connection lost
May 30 06:55:00 sovereign1 Fulcrum[1686]: [2022-05-30 06:55:00.772] <Controller> Failed to synch blocks and/or mempool
May 30 06:55:00 sovereign1 Fulcrum[1686]: [2022-05-30 06:55:00.772] <Controller> Initial sync ended, flushing and deleting UTXO Cache ...
May 30 06:55:00 sovereign1 Fulcrum[1686]: [2022-05-30 06:55:00.772] <Controller> Storage UTXO Cache: Flushing to DB ...
May 30 06:55:03 sovereign1 Fulcrum[1686]: [2022-05-30 06:55:03.926] <Controller> Block height 738537, downloading new blocks ...
May 30 06:55:03 sovereign1 Fulcrum[1686]: [2022-05-30 06:55:03.926] <Controller> fast-sync: Enabled; UTXO cache size set to 7000000000 bytes (available physical RAM: 12080082944 bytes)
May 30 07:22:31 sovereign1 Fulcrum[1686]: [2022-05-30 07:22:31.534] <BitcoinD.3> Lost connection to bitcoind, will retry every 5 seconds ...
May 30 07:22:32 sovereign1 Fulcrum[1686]: [2022-05-30 07:22:31.534] <Task.DL 361303 -> 738537> 730515: FAIL: bitcoind connection lost
May 30 07:22:32 sovereign1 Fulcrum[1686]: [2022-05-30 07:22:31.534] <Task.DL 361303 -> 738537> 730518: FAIL: bitcoind connection lost
May 30 07:22:32 sovereign1 Fulcrum[1686]: [2022-05-30 07:22:31.534] <BitcoinD.2> Lost connection to bitcoind, will retry every 5 seconds ...
May 30 07:22:32 sovereign1 Fulcrum[1686]: [2022-05-30 07:22:31.535] <Task.DL 361303 -> 738537> 730517: FAIL: bitcoind connection lost
May 30 07:22:36 sovereign1 Fulcrum[1686]: [2022-05-30 07:22:36.534] <BitcoinD.1> Lost connection to bitcoind, will retry every 5 seconds ...
May 30 07:22:36 sovereign1 Fulcrum[1686]: [2022-05-30 07:22:36.534] <Task.DL 361303 -> 738537> 730519: FAIL: bitcoind connection lost

The text was updated successfully, but these errors were encountered:

cculianu · 2022-05-30T12:52:55Z

Hmm. No this is not normal nor is it ideal.

What is the setup? I presume bitcoind is local on the same box as Fulcrum? That is, this is via localhost connection? What bitcoind version?

Pasting (a possibly redacted) version of the fulcrum.conf here would help ...

Techeavy33 · 2022-05-31T01:28:54Z

Thanks for replying. Yes, bitcoind is running locally on the same box as fulcrum. bitcoin core version 23.0. Currently the sync is at 54.8%.

cculianu · 2022-05-31T01:59:05Z

Very strange. It's as if bitcoind is dropping conn itself. You can ignore this since Fulcrum reconnects of course and proceeds anyway -- however I am curious WHY it's happening. If you can reliably reproduce it or if it happens often can you try running Fulcrum with -d (debug) to see some debug printing? Maybe it would offer a clue as to why...

Also is this on HDD or SSD? What hardware? RPi? x86 desktop PC? What OS? Etc, etc, etc...

Techeavy33 · 2022-05-31T02:15:02Z

Im using a HDD / Ubuntu server 22.04 / VM. Would it be helpful if I spun up a dedicated server just for Fulcrum and point it to bitcoind? bitcoind is also running on Ubuntu server 22.04.

Techeavy33 · 2022-05-31T02:18:54Z

I was told that when syncing was completed fulcrum_db should be at least 105GB. Im currently at 55.2% and fulcrum_db is only at 20GB.
May 31 02:07:18 sovereign1 Fulcrum[2628]: [2022-05-31 02:07:18.415] Processed height: 408000, 55.2%, 28.4 blocks/min, 656.8 txs/sec, 2061.6 addrs/sec

@SOVEREIGN1: /fulcrum_db$ du -h

2.3G ./txhash2txnum
1.4G ./scripthash_unspent
4.3M ./undo
3.4G ./utxoset
6.7M ./meta
19M ./blkinfo
8.9G ./scripthash_history
20G .

cculianu · 2022-05-31T02:39:25Z

Im using a HDD

Hmm. I wonder if bitcoind is taking so long to read and respond to a backlog of block requests that Fulcrum times out (because HDD)? Please run with -d and paste the log before the timeout occurs if you want to further diagnose. If you want it to maybe not happen, maybe try to run Fulcrum with --bd-timeout 300 (sets bitcoind timeout to 300 seconds from the default of 30). It may mitigate the problem.

Would it be helpful if I spun up a dedicated server just for Fulcrum and point it to bitcoind? bitcoind is also running on Ubuntu server 22.04.

To be clear Fulcrum and bitcoind ideally should run on the same machine. As to whether or not you want to spin up a dedicated server -- that's up to you. I run my Fulcrum/bitcoind combo on a server I use for other things without any problems. In fact, I run bitcoind + Fulcrum for 3 coins: BTC, BCH, and LTC, and for each coin I run mainnet & testnet. That's 6 instances of bitcoind and 6 instances of Fulcrum on the same box, without issue.

I'm currently at 55.2% and fulcrum_db is only at 20GB.

That "55.2%" is by block height. You are 55.2% into the blocks by height. Later blocks on the chain are full, so data consumption will increase as you get to the later blocks. You should probably reach the 100GB mark or beyond...

Techeavy33 · 2022-05-31T12:31:35Z

First i just want to say thank you for taking the time to help troubleshoot this with me...your work is much appreciated.

Im starting fulcrum by using the systemctl command to start the service with this command provided by the tutorial: sudo systemctl start fulcrum.service. In order to use the (--bd-timeout 300) command, who is this command entered?
Here are logs from bicoind that may be causing the problem:

- Tor host failing

2022-05-31T02:30:19Z UpdateTip: new best=000000000000000000073ef06543252dce1cc24c9e31a6d6848d892ffc824f71 height=738656 version=0x20000000 log2_work=93.549238 tx=737714334 date='2022-05-31T02:30:02Z' progress=1.000000 cache=51.2MiB(325658txo)
2022-05-31T02:30:55Z Socks5() connect to hvkw32wuysp55b5klwheodr7l62luxtz66jzr5dcwsmvzhadvvq4goad.onion:8333 failed: host unreachable
2022-05-31T02:35:24Z Socks5() connect to 4mmdc3emkbcpb56f7lz466shtzoks3ik5ahnfo3ubod7hjwtsilhvcid.onion:8333 failed: host unreachable
2022-05-31T02:36:07Z Socks5() connect to 6kdnn5ugenrmnxagtlkcoooq5z53bay7d3jnkjwfk4f3vhjsflpti4qd.onion:8333 failed: host unreachable
2022-05-31T02:37:33Z Socks5() connect to axorwj42azd6sedg7q2opxjtfazufezjowicekje6ok7qng33j64bcad.onion:8333 failed: host unreachable
2022-05-31T02:39:08Z Socks5() connect to fxlvzqk5d3s72k6u26kgtfcyq7qavlf4ee4yqlu64kcr63pqmzjl3eyd.onion:8333 failed: host unreachable
2022-05-31T02:40:58Z Socks5() connect to nqtxpcbn6jdbtl7aqrafm2psvfwugntmx73sdhu434ptws3kbmvoaiyd.onion:8333 failed: host unreachable
2022-05-31T02:45:25Z Socks5() connect to scxho4jriapar3z5r4az6kzuxodrh337eqayca2habiqrygijoslnpyd.onion:8333 failed: host unreachable
2022-05-31T02:46:15Z UpdateTip: new best=00000000000000000001b5734989aa5d43bd7a6266b560306e62fad9e5fe5633 height=738657 version=0x2acc2000 log2_work=93.549251 tx=737716555 date='2022-05-31T02:45:52Z' progress=1.000000 cache=52.6MiB(336400txo)
2022-05-31T02:49:32Z Socks5() connect to hlh4pn7dnlpuw2typm3uuaptaxekmo6cgzscnvbwvzhekdbh54fmlhad.onion:8333 failed: host unreachable
2022-05-31T03:09:07Z New outbound peer connected: version: 70016, blocks=738657, peer=1269 (block-relay-only)

**- Request rejections**

2022-05-31T05:32:41Z WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting
2022-05-31T05:32:41Z WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting
2022-05-31T05:32:41Z WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting
2022-05-31T05:32:43Z WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting
2022-05-31T05:32:43Z WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting
2022-05-31T05:32:43Z WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting
2022-05-31T05:32:46Z WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting
2022-05-31T05:32:46Z WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting
2022-05-31T05:32:46Z WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting
2022-05-31T05:32:48Z WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting
2022-05-31T05:32:48Z WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting
2022-05-31T05:32:48Z WARNING: request rejected because http work queue depth exceeded, it can be increased with the -rpcworkqueue= setting

I think your explanation regarding the fact that I am using HDD is causing the problem. I will try using the (--bd-timeout 300) command, but Im not sure how to use it being that I learned to start fulcrum by using the systemctl command via the tutorial. If the timeout command does not work I will have to purchase a SSD and rebuild everything, which is no problem.

Again thanks for all of your help.

DanielPX1 · 2022-05-31T13:01:27Z

Hi, can confirm this bug as well, just wanted to report it.
Running: Raspberry pi 4 (4GB), Bitcoin core 23.0, Samsung QVO SSD 1TB

Fulcrum loses connection sometimes, wonder why. It sometimes takes up to 10+ minutes to reconnect, which slows down the sync quite significantly when it happens several times a day. Can it be caused by settings in fulcrum/bitcoin core? However in btccore I use default settings. These are my changes in fulcrum file - should optimize syncing for raspberry:

bitcoind_timeout = 300
bitcoind_clients = 1
worker_threads = 1
db_mem=1024
db_max_open_files=200
fast-sync = 1024

Error:
May 31 13:47:00 rasp Fulcrum[1266]: [2022-05-31 13:47:00.474] Storage UTXO Cache: Flushing to DB ...
May 31 14:05:56 rasp Fulcrum[1266]: [2022-05-31 14:05:56.103] Storage UTXO Cache: Flushing to DB ...
May 31 14:06:25 rasp Fulcrum[1266]: [2022-05-31 14:06:25.113] <BitcoinD.1> Lost connection to bitcoind, will retry every 5 seconds ...
May 31 14:13:38 rasp Fulcrum[1266]: [2022-05-31 14:13:38.979] Processed height: 682000, 92.3%, 36.0 blocks/min, 1044.3 txs/sec, 6210.7 addrs/sec
May 31 14:15:46 rasp Fulcrum[1266]: [2022-05-31 14:15:46.810] Storage UTXO Cache: Flushing to DB ...
May 31 14:27:50 rasp Fulcrum[1266]: [2022-05-31 14:27:50.434] Storage UTXO Cache: Flushing to DB ...
May 31 14:37:38 rasp Fulcrum[1266]: [2022-05-31 14:37:38.501] Storage UTXO Cache: Flushing to DB ...
May 31 14:44:46 rasp Fulcrum[1266]: [2022-05-31 14:44:46.128] Processed height: 683000, 92.5%, 32.1 blocks/min, 904.5 txs/sec, 5440.0 addrs/sec
May 31 14:49:14 rasp Fulcrum[1266]: [2022-05-31 14:49:14.136] Storage UTXO Cache: Flushing to DB ...
May 31 14:50:55 rasp Fulcrum[1266]: [2022-05-31 14:50:55.556] <BitcoinD.1> Lost connection to bitcoind, will retry every 5 seconds ...

cculianu · 2022-05-31T13:08:53Z

@Techeavy33 Ok so a few things you asked about, I will try to get to them all:

Ah, if you are using systemctl you can edit the file in /etc/systemd/system/fulcrum.service or whatever the actual path is, or you can modify the ocnfig file and add bitcoind_timeout = 300 on a line by itself to have the same effect.
It does appear bitcoind isn't keeping up. You can try modifying your bitcoin.conf and adding rpcworkqueue=128 (the default is 16) or something but I am afraid that may not necessarily be enough (although it may be).

@DanielPX1 . This program was designed actually for higher performance hardware... . the fact that it works on Rpi as well as it does is fortunate but not a guarantee always. Perhaps you can try some of the above things too?

cculianu · 2022-05-31T13:10:48Z

Hmm. An option I have I guess is to "guesstimate" reasonable values for systems on HDD and Rpi (at least for Fulcrum). But if bitcoind rpcworkqueue can't keep up that is troublesome. (Although one thing would be to throttle it better to not ask for so many blocks in a row if HDD.. hmm).

cculianu · 2022-06-01T04:41:22Z

Hmm I did find some deficiencies in Fulcrum's code/logic when bitcoind is slow to respond. I'm working on a fix. I do think this is a fixable problem in Fulcum.. working on it. In the meantime yeah --bd-timeout 600 and/or bitcoind_timeout = 600 might be a decent way to mitigate the issue.

Techeavy33 · 2022-06-01T22:00:29Z

Hi @cculianu. The changes in the config file didn't work for me. I see you added a bug and are working on this. I will just wait to try and install fulcrum again after the bug fixes after your investigation reveals anything. Thank you again. Hey if you need me to run any tests or provide you with any feedback whatsoever I am more then happy to help. Just FYI i am still learning a lot with everything and Im am not an expert, but I would love you help you in anyway that I can to further your project. Thanks again man.

cculianu · 2022-06-01T22:08:37Z

Hey if you need me to run any tests or provide you with any feedback whatsoever I am more then happy to help.

Hey yeah since you are having the problem -- when I have the issue resolved I will let you know and some testing would be appreciaed!

Techeavy33 · 2022-06-03T22:59:38Z

Yeah no problem man. Just let me know, and Im willing to help out in anyway I can. Thanks!

…r on HDD STILL A WIP AAAHHH!! --- This commit should fix #116. This commit also addresses the poor performance seen in the recent Bitcoin Verde BCHN Scaling report. It also makes running Fulcrum for BCH ScaleNet more performant with default settings. What was fixed and how: - There was a slight bug with how the "ping timer" mechanism to BitcoinD worked in that it was too likely to conclude the connection was stale in some cases when doing initial synch, if the timer fired at the wrong times. This could lead to spurious disconnect/reconnect cycles sometimes during synch. - This has been addressed.by making the pingTimer use a "CoarseTimer" (as opposed to a "VeryCoarseTimer") and also adding some +/- 100 msec fuzz to when the pings should fire and when we conclude bitcoind is "stale". We made the stale threshold also be 3 ping cycles instead of 2. - Additionally, there was a bug when downloading very large blocks (hundreds of MB) or when bitcoind was otherwise slow to return blocks for whatever reason (such as if using HDD). In some cases requests for blocks would "time out" after 30 seconds during initial synch, causing a disconnect and reconnect cycle to occur, slowing down synch tremendously. - This has been addressed by anticiapting that requests for later blocks in a prefetch burst of 100 or 1000 blocks should have timeouts longer than 30 seconds. In addition this commit has some additional debug prints (off at compile time but can be re-enabled during dev testing) to be able to troubleshoot the above in the future, if need be.

… or with huge blocks + misc fixes (#120) This commit should fix issue #116. It also addresses the Bitcoin Verde Scaling Report dated May 2022 which revealed that Fulcrum has some issues downloading very large blocks (256MB+) in a series. The two issues are related, and are basically because the following could happen on a slow HDD system or with a bitcoind that is serving up very large blocks:

cculianu · 2022-06-05T18:19:41Z

Hi @Techeavy33 and/or @DanielPX1 -- are either of you able to test latest master and tell me if the situation has improved? Let me know if you want me to build a binary for you for Linux64 or Arm64 and I can put it up somewhere if you can't build latest master.

I think the latest commit I just pushed should fix this.

cculianu · 2022-06-06T11:58:22Z

Update: The new release 1.7.0 has the fixes Let me know if it performs better...

Techeavy33 · 2022-06-07T03:06:23Z

ok will do. I'll have to work on it this weekend work is crazy this week. Thanks for the update will be in touch this weekend.

cculianu · 2022-06-07T04:39:30Z

Yeah no rush. I tested it extensively -- raping a slow HDD system (compiling in another terminal tab while synching). It seemed to hold up well and never a dropped conn. Without the fix it definitely would drop conn and restart the synch.

I am hoping my fix is enough for all systems. Technically if bitcoind takes longer than 10 minutes to return a getblock it will still restart the synch... Hopefully 10 mins is enough!

DanielPX1 · 2022-06-10T22:08:20Z

Hi @Techeavy33 and/or @DanielPX1 -- are either of you able to test latest master and tell me if the situation has improved? Let me know if you want me to build a binary for you for Linux64 or Arm64 and I can put it up somewhere if you can't build latest master.

I think the latest commit I just pushed should fix this.

Sorry for not answering. I plan into playing with fulcrum more so I might test it later, however now I am fully synced and trying to use it with different wallets - so far successfully:)
Synced on raspberry pi 4 4GB and works like a charm

cculianu · 2022-06-10T23:39:29Z

Ok no worries. We are all volunteers here! It's good to hear you are happy with it and that it's working like a charm. I'm going to go ahead and close this in the interests of keeping the open issues list lighter. Feel free to write in here if you do have further trouble guys... I am pretty sure the issue is solved in my testing I was both able to reproduce it by simulating a slowdown problem on an HDD (I had the system overloaded with lots of I/O) while doing a synch, and it definitely dropped conn when bitcoind took "long-ish" to respond. The new fixes definitely address this behavior/bug.

Closing..

chrisBonGit · 2023-04-09T13:16:47Z

Hi, sorry if I'm bringing this back from the dead / closed list. I hope it's just user error but I'm seeing this issue. Again I'm running on a RPi4, raspiblitz (v1.8.0), bitcoin v23.0.0, 8GB RAM, 1Tb SSD (powered from raspi)
fulcrum-1.7.0
fulcrum.conf was not changed from install script packaged with this v of raspiblitz (i.e. I just used config.scripts/bonus.fulcrum.sh on) and has;

'bitcoind_timeout = 600'
and
'# for 4GB RAM'
'db_max_open_files=200'
'fast-sync = 1024'

● fulcrum.service - Fulcrum
Loaded: loaded (/etc/systemd/system/fulcrum.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2023-04-03 19:46:56 BST; 5 days ago
Main PID: 3957927 (Fulcrum)
Tasks: 21 (limit: 9353)
CPU: 10h 18min 4.892s
CGroup: /system.slice/fulcrum.service
└─3957927 /home/fulcrum/Fulcrum-1.7.0-arm64-linux/Fulcrum /home/fulcrum/.fulcrum/fulcrum.conf

after 5 days I'm at 48.3%, here's the end of the journal, showing the most recent occurrence of bitcoind request time out.
Apr 09 12:35:58 raspberrypi Fulcrum[3957927]: [2023-04-09 12:35:58.813] Task errored: Task.DL 351553 -> 784211, error: bitcoind request timed out
Apr 09 12:35:59 raspberrypi Fulcrum[3957927]: [2023-04-09 12:35:59.364] Failed to synch blocks and/or mempool
Apr 09 12:35:59 raspberrypi Fulcrum[3957927]: [2023-04-09 12:35:59.367] Initial sync ended, flushing and deleting UTXO Cache ...
Apr 09 12:35:59 raspberrypi Fulcrum[3957927]: [2023-04-09 12:35:59.367] Storage UTXO Cache: Flushing to DB ...
Apr 09 12:54:52 raspberrypi Fulcrum[3957927]: [2023-04-09 12:54:52.116] Block height 784633, downloading new blocks ...
Apr 09 12:54:52 raspberrypi Fulcrum[3957927]: [2023-04-09 12:54:52.130] fast-sync: Enabled; UTXO cache size set to 1024000000 bytes (available physical RAM: 3154145280 bytes)
Apr 09 13:08:38 raspberrypi Fulcrum[3957927]: [2023-04-09 13:08:38.558] Processed height: 377000, 48.0%, 1.00 blocks/sec, 840.0 txs/sec, 3321.4 addrs/sec
Apr 09 13:17:19 raspberrypi Fulcrum[3957927]: [2023-04-09 13:17:19.133] Processed height: 378000, 48.2%, 1.92 blocks/sec, 1748.5 txs/sec, 6693.0 addrs/sec
Apr 09 13:31:34 raspberrypi Fulcrum[3957927]: [2023-04-09 13:31:34.885] Processed height: 379000, 48.3%, 1.17 blocks/sec, 1041.3 txs/sec, 4210.4 addrs/sec

checking on memory
admin@...redacted...: /home/fulcrum ₿ free -h
total used free shared buff/cache available
Mem: 7.7Gi 5.3Gi 328Mi 0.0Ki 2.1Gi 2.3Gi
Swap: 12Gi 3.2Gi 9.4Gi

I found that someone has a successful sync on much the same RPi set up as mine, except they powered the SSD externally to the RPi. See following link for details; raspiblitz/raspiblitz#2924 (comment)

I'll see if I can find a USB data / power splitting cable to do the same & will report back what I find out (if/when I find what I'm looking for).

cculianu · 2023-04-09T16:31:44Z

I think you're running out of RAM and the RPi is swapping like mad, thus freezing the system.

I wouldn't use --fast-sync at all. It eats RAM and is not suitable for a constrained system.
To conserve even more memory: Try using the following jemalloc option, as an ENV var: MALLOC_CONF=tcache:false

chrisBonGit · 2023-04-09T17:48:59Z

Thanks for your quick support, I'll give that a go (have now read up how to set ENV variables).

Might be a bit of delay, currently making negative progress, can't even get the RPi to reboot (giving it 10mins - now I've used cli to attempt to stop bitcoind - and will then pull power).
Will keep you posted when I'm able to restart fulcrum (at least I stopped this service cleanly before re-routing SDD into RPi via a powered hub - no idea if that helps, as have not been able to sync to blockchain since)

cculianu · 2023-04-09T20:18:22Z

Yeah not sure about the power thing since I'm no RPi power user but I can imagine if the SSD draws too much power during periods of heavy activity it might fail. No idea to be honest .. but sounds plausible at least from 10,000ft view. Good luck!

chrisBonGit · 2023-04-10T12:47:54Z

At the risk of tempting fate...
With the above changes (& I turned off every service that wasn't essential), Fulcrum has now been running for ~12hrs with no bitcoind request time outs.
If the rate of sync were to stay constant (and I've read / expect it will take longer as the blocks become much more utilised in later blocks) then it would take about another 13hrs to complete... (from 50% complete by blockheight)
So I'll report back in a few weeks!
In the meantime I'm looking in to running it on my NAS (I see you've provided a container image for docker, thanks, I just need to learn LOTs about how to plumb it together so my networked devices can reach the fulcrum server without creating some security risk). So far I've got bitcoin core up and running there - so I'm learning loads.

cculianu · 2023-04-10T14:42:05Z

Great. Ok yeah I think results will be better now.

cculianu added the Requires Investigation Not clear if bug here or bug outside of Fulcrum label May 30, 2022

cculianu added bug Something isn't working and removed Requires Investigation Not clear if bug here or bug outside of Fulcrum labels Jun 1, 2022

cculianu mentioned this issue Jun 5, 2022

Blocks DL: Improve reliability of bitcoind connection on slow systems or with huge blocks + misc fixes #120

Merged

cculianu closed this as completed Jun 10, 2022

cculianu added the Fixed label Jun 10, 2022

RequestPrivacy mentioned this issue Jul 2, 2023

Intermittent connections to bitcoind #183

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

bitcoind connection lost during syncing #116

bitcoind connection lost during syncing #116

k3tan172 commented May 30, 2022

cculianu commented May 30, 2022 •

edited

Loading

Techeavy33 commented May 31, 2022

cculianu commented May 31, 2022

Techeavy33 commented May 31, 2022

Techeavy33 commented May 31, 2022 •

edited

Loading

cculianu commented May 31, 2022 •

edited

Loading

Techeavy33 commented May 31, 2022

DanielPX1 commented May 31, 2022 •

edited

Loading

cculianu commented May 31, 2022

cculianu commented May 31, 2022

cculianu commented Jun 1, 2022

Techeavy33 commented Jun 1, 2022

cculianu commented Jun 1, 2022 •

edited

Loading

Techeavy33 commented Jun 3, 2022

cculianu commented Jun 5, 2022

cculianu commented Jun 6, 2022

Techeavy33 commented Jun 7, 2022

cculianu commented Jun 7, 2022

DanielPX1 commented Jun 10, 2022 •

edited

Loading

cculianu commented Jun 10, 2022 •

edited

Loading

chrisBonGit commented Apr 9, 2023 •

edited

Loading

cculianu commented Apr 9, 2023

chrisBonGit commented Apr 9, 2023

cculianu commented Apr 9, 2023

chrisBonGit commented Apr 10, 2023

cculianu commented Apr 10, 2023

bitcoind connection lost during syncing #116

bitcoind connection lost during syncing #116

Comments

k3tan172 commented May 30, 2022

cculianu commented May 30, 2022 • edited Loading

Techeavy33 commented May 31, 2022

cculianu commented May 31, 2022

Techeavy33 commented May 31, 2022

Techeavy33 commented May 31, 2022 • edited Loading

cculianu commented May 31, 2022 • edited Loading

Techeavy33 commented May 31, 2022

DanielPX1 commented May 31, 2022 • edited Loading

cculianu commented May 31, 2022

cculianu commented May 31, 2022

cculianu commented Jun 1, 2022

Techeavy33 commented Jun 1, 2022

cculianu commented Jun 1, 2022 • edited Loading

Techeavy33 commented Jun 3, 2022

cculianu commented Jun 5, 2022

cculianu commented Jun 6, 2022

Techeavy33 commented Jun 7, 2022

cculianu commented Jun 7, 2022

DanielPX1 commented Jun 10, 2022 • edited Loading

cculianu commented Jun 10, 2022 • edited Loading

chrisBonGit commented Apr 9, 2023 • edited Loading

cculianu commented Apr 9, 2023

chrisBonGit commented Apr 9, 2023

cculianu commented Apr 9, 2023

chrisBonGit commented Apr 10, 2023

cculianu commented Apr 10, 2023

cculianu commented May 30, 2022 •

edited

Loading

Techeavy33 commented May 31, 2022 •

edited

Loading

cculianu commented May 31, 2022 •

edited

Loading

DanielPX1 commented May 31, 2022 •

edited

Loading

cculianu commented Jun 1, 2022 •

edited

Loading

DanielPX1 commented Jun 10, 2022 •

edited

Loading

cculianu commented Jun 10, 2022 •

edited

Loading

chrisBonGit commented Apr 9, 2023 •

edited

Loading