How synhronise bitcoin core (Centos 7) for working (getbalance etc)

[avtorkoda]

Hi, i`m newbi

What I've done

1 bought VDS Centos 7
2 Run some cmd

#Installing RPM packages with rpm
$ sudo rpm -ivh  https://mirror.cryptorpms.com/cryptorpms/el8/x86_64/cryptorpms-release-1-1.noarch.rpm

#Install the GUI
$ yum install bitcoin-core

#https://www.cryptorpms.com/software/bitcoin-core/
# Install the Server
$ yum install bitcoin-server

3 config
$ mcedit ~/.bitcoin/bitcoin.conf

#printtoconsole=1
testnet=0
mainnet=1
txindex=1
server=1
rest=1
daemon=1
rpcuser=btcuser
rpcpassword=btcpass
rpcport=18332
rpcbind=127.0.0.1
rpcallowip=0.0.0.0/0
datadir=/mnt/bitcoin

4 run
$ bitcoin-cli getblockchaininfo

https://c.radikal.ru/c07/2012/e9/dcb75e61d3c6.png

result see in picture

5 get new address by command
$ bitcoin-cli getnewaddress

output address like this 1ELLk***************RUSgT2xvhxXx

6 send some BCT to address
see in pic, Confirmations>6
https://b.radikal.ru/b23/2012/bd/43d2846dd1e1.png


7 run
$ bitcoin-cli getreceivedbyaddress 1ELLk***************RUSgT2xvhxXx
and output
0.00000000

#1 WHY zero ??

#2 And WHY getblockchaininfo show zero blocks, is not update chain ? my folder /mnt/bitcoin  empty ? WHY? or How to start synhronise blockchain for retrieve balance of my addresses ?


for dev info

$ netstat -tulnp | grep bitcoind
output in pic
https://b.radikal.ru/b23/2012/8c/2803d57a625d.png

$ systemctl status bitcoin
output in pic
https://d.radikal.ru/d25/2012/60/488bec48042a.png

[1714985196]

1714985196

[1714985196]

1714985196

[1714985196]

1714985196

[1714985196]

1714985196

[ranochigo]

First of all, back up your wallet.dat file. Don't store anything on the server without a backup.

It's zero because your client isn't synchronized yet. Are you connected to any peers? Use bitcoin-cli getnetworkinfo.

Could you check how much disk space do you have? Use df -h and check if you have at least ~350GB of disk space available. Some budget VDS barely have 50GB.

[mocacinno]

First of all, back up your wallet.dat file. Don't store anything on the server without a backup.

It's zero because your client isn't synchronized yet. Are you connected to any peers? Use bitcoin-cli getnetworkinfo.

Could you check how much disk space do you have? Use df -h and check if you have at least ~350GB of disk space available. Some budget VDS barely have 50GB.

100% in agreement, i only wanted to add that IF you don't have sufficient diskspace, your coins are not lost...
You can either run a pruned node, or you can export the private key(s) of the address(es) you funded and import them in an SPV wallet (like electrum)

[LoyceV]

Quoting to show images:

$ bitcoin-cli getreceivedbyaddress 1ELLk***************RUSgT2xvhxXx

FYI: "hiding" addresses like this doesn't help if someone really wants to find the address.

100% in agreement, i only wanted to add that IF you don't have sufficient diskspace, your coins are not lost...

Follow up question @avtorkoda: is there a reason you're running this on a server?

[avtorkoda]

=It's zero because your client isn't synchronized yet. Are you connected to any peers? Use bitcoin-cli getnetworkinfo.
Maybe no.... look attach
https://b.radikal.ru/b29/2012/06/55c0f3384496.png

And space hdd
https://b.radikal.ru/b40/2012/8c/88d6ebbb20d9.png

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.8G     0  3.8G   0% /dev
tmpfs           3.8G     0  3.8G   0% /dev/shm
tmpfs           3.8G  377M  3.4G  10% /run
tmpfs           3.8G     0  3.8G   0% /sys/fs/cgroup
/dev/vda1       394G  7.0G  371G   2% /
/dev/loop0      3.9G  8.8M  3.7G   1% /tmp
tmpfs           764M     0  764M   0% /run/user/0


If, space enough, how connect to peer for update chain ?

[LoyceV]

Quoting images again:

I can't tell you why it isn't working though.

/dev/vda1       394G  7.0G  371G   2% /

That is enough space, but doesn't leave you much margin for other data and future growth of the blockchain.

[NotATether]

You're probably not getting any peers because you have this in your bitcoin.conf:

rpcbind=127.0.0.1

This causes bitcoin core to only listen on your localhost network interface, which other peers cannot discover. Remove that line, and it will listen on all your network interfaces including the one with an internet connection, and you should get peers.

[ranochigo]

You're probably not getting any peers because you have this in your bitcoin.conf:

rpcbind=127.0.0.1

This causes bitcoin core to only listen on your localhost network interface, which other peers cannot discover. Remove that line, and it will listen on all your network interfaces including the one with an internet connection, and you should get peers.

I might be mistaken but isn't the command only used for RPC interface? Like wouldn't it be the case if OP has bind=127.0.0.1 instead?

The images that OP sent appears to show that the client is listening to 0.0.0.0:8333. Even if it isn't the client should connect to other peers and it wouldn't matter in that case?

In case the advice doesn't help, I think it would be good for OP to paste the logs from debug.log and if there's any connection being dropped by the peers.

[avtorkoda]

Heh, about peers...

1 I go to https://bitnodes.io/nodes/?q=United%20States for peer IP

2 add in config two lines
addnode=66.228.49.201
connect=40.83.145.79:8333

3 and view debug!
/var/lib/bitcoin/debug.log
https://b.radikal.ru/b08/2012/26/70ff107121ae.png

failed after select? WTF?

Hmmmmm....

[NotATether]

I might be mistaken but isn't the command only used for RPC interface? Like wouldn't it be the case if OP has bind=127.0.0.1 instead?

The images that OP sent appears to show that the client is listening to 0.0.0.0:8333. Even if it isn't the client should connect to other peers and it wouldn't matter in that case?

Now that I look at the netstat logs you must be correct. That option really is only for the RPC interface.

Heh, about peers...

1 I go to https://bitnodes.io/nodes/?q=United%20States for peer IP

2 add in config two lines
addnode=66.228.49.201
connect=40.83.145.79:8333

3 and view debug!
/var/lib/bitcoin/debug.log


failed after select? WTF?

Hmmmmm....

The problem is that you are using the connect option on a node that is not connecting back to you (40.83.145.79:8333). This option means you only connect to the listed nodes, and no others. It can't be that the node is down, because an nmap scan shows that it's listening on that port:

Code:

$ nmap -Pn -p8333 40.83.145.79 66.228.49.201
Starting Nmap 7.80 ( https://nmap.org ) at 2020-12-23 21:56 UTC
Nmap scan report for 40.83.145.79
Host is up (0.16s latency).

PORT     STATE SERVICE
8333/tcp open  bitcoin

Nmap scan report for li291-201.members.linode.com (66.228.49.201)
Host is up.

PORT     STATE    SERVICE
8333/tcp filtered bitcoin

Nmap done: 2 IP addresses (2 hosts up) scanned in 1.67 seconds

You should remove that connect option and if you really insist on connecting to that node, make a second addnodes option with the node 40.83.145.79:8333. Leave "connect" unspecified and let Bitcoin Core do the work of connecting to peers by itself.

[avtorkoda]

My peer is empty, because ports 8332 / 18332 closed

iptables is solution ? yeah

$ iptables -I INPUT -p tcp --dport 8332 -m state --state NEW -j ACCEPT
$ systemctl restart iptables

But
$ iptables -L is output next below

# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8332 state NEW
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8332 state NEW

Ok,

DROP IP`s counting and counting (added), wtf ? some body attack my VDS ? )))

Chain DENYIN (1 references)
target     prot opt source               destination
DROP       all  --  111.229.219.39       anywhere
DROP       all  --  106.13.123.73        anywhere
DROP       all  --  120.48.21.252        anywhere
DROP       all  --  47.88.159.100        anywhere
DROP       all  --  106.13.82.231        anywhere
DROP       all  --  165.22.75.225        anywhere
DROP       all  --  150.136.40.83        anywhere
DROP       all  --  23.97.180.45         anywhere
DROP       all  --  81.70.57.192         anywhere
DROP       all  --  152.67.35.185        anywhere
DROP       all  --  45.141.84.126        anywhere
DROP       all  --  175.24.49.95         anywhere
DROP       all  --  106.12.107.61        anywhere
DROP       all  --  srv.apeiron.global   anywhere
DROP       all  --  14.29.126.53         anywhere
DROP       all  --  82.35.33.58.broad.xw.sh.dynamic.163data.com.cn  anywhere

*
*
*
*
Chain DENYOUT (1 references)
target     prot opt source               destination
LOGDROPOUT  all  --  anywhere             111.229.219.39
LOGDROPOUT  all  --  anywhere             106.13.123.73

LOGDROPOUT  all  --  anywhere             120.48.21.252
LOGDROPOUT  all  --  anywhere             47.88.159.100
LOGDROPOUT  all  --  anywhere             106.13.82.231
LOGDROPOUT  all  --  anywhere             165.22.75.225
LOGDROPOUT  all  --  anywhere             150.136.40.83
LOGDROPOUT  all  --  anywhere             23.97.180.45
LOGDROPOUT  all  --  anywhere             81.70.57.192
LOGDROPOUT  all  --  anywhere             152.67.35.185
LOGDROPOUT  all  --  anywhere             45.141.84.126
LOGDROPOUT  all  --  anywhere             175.24.49.95
LOGDROPOUT  all  --  anywhere             106.12.107.61
LOGDROPOUT  all  --  anywhere             srv.apeiron.global

*
*
*

And I press BREAK on keyoard, that stop listing

Today my conf is

#printtoconsole=1
testnet=0
mainnet=1
txindex=1
server=1
daemon=1
rest=1
listen=1
addnode=104.237.131.138
addnode=151.80.205.132
addnode=192.155.82.123
addnode=74.220.255.190
addnode=80.100.203.151
rpcuser=****
rpcpassword=****
rpcport=18332
rpcbind=127.0.0.1
#rpcallowip=127.0.0.1
rpcallowip=0.0.0.0/0
datadir=/mnt/bitcoin

Debug
# tail /var/lib/bitcoin/debug.log
2020-12-25T18:14:14Z msghand thread start
2020-12-25T18:14:14Z init message: Done loading
2020-12-25T18:14:15Z connect() to 104.237.131.138:8333 failed after select(): Connection refused (111)
2020-12-25T18:14:17Z connect() to 151.80.205.132:8333 failed after select(): Connection refused (111)
2020-12-25T18:14:18Z connect() to 192.155.82.123:8333 failed after select(): Connection refused (111)
2020-12-25T18:14:20Z connect() to 74.220.255.190:8333 failed after select(): Connection refused (111)
2020-12-25T18:14:21Z connect() to 80.100.203.151:8333 failed after select(): Connection refused (111)
2020-12-25T18:14:25Z Loading addresses from DNS seed seed.bitcoin.sprovoost.nl
2020-12-25T18:14:26Z Loading addresses from DNS seed seed.bitcoin.jonasschnelli.ch
2020-12-25T18:14:26Z Loading addresses from DNS seed dnsseed.bitcoin.dashjr.org

[ranochigo]

My peer is empty, because ports 8332 / 18332 closed

No. 8332 (18332 for testnet) is for your RPC, as you've specified. Please don't open that port, people tend to scan those ports to find Bitcoin RPC to bruteforce.

Peers typically connect through 8333 but that is not necessary to be opened unless you need people to connect to you. Is there anything blocking any outgoing connection to other peers either by your local firewall rule or your service provider rules? How does the node function after attempting to get IPs from the DNS seeds?

[avtorkoda]

thx
--

# tail /var/lib/bitcoin/debug.log
2020-12-25T18:32:34Z Bound to 0.0.0.0:8333
2020-12-25T18:32:34Z init message: Loading P2P addresses...
2020-12-25T18:32:34Z Loaded 1986 addresses from peers.dat  5ms
2020-12-25T18:32:34Z init message: Starting network threads...
2020-12-25T18:32:34Z net thread start
2020-12-25T18:32:34Z addcon thread start
2020-12-25T18:32:34Z dnsseed thread start
2020-12-25T18:32:34Z init message: Done loading
2020-12-25T18:32:34Z opencon thread start
2020-12-25T18:32:34Z msghand thread start

Bolded is good news ?

[avtorkoda]

WOW!

FIRST

# tail /var/lib/bitcoin/debug.log
2020-12-25T18:32:45Z Loading addresses from DNS seed seed.bitcoinstats.com
2020-12-25T18:32:45Z Loading addresses from DNS seed seed.bitcoin.jonasschnelli.ch
2020-12-25T18:32:45Z Loading addresses from DNS seed seed.bitcoin.sprovoost.nl
2020-12-25T18:32:56Z Loading addresses from DNS seed dnsseed.bluematt.me
2020-12-25T18:32:56Z Loading addresses from DNS seed dnsseed.bitcoin.dashjr.org
2020-12-25T18:32:56Z Loading addresses from DNS seed seed.bitcoin.sipa.be
2020-12-25T18:33:07Z Loading addresses from DNS seed dnsseed.emzy.de
2020-12-25T18:33:07Z Loading addresses from DNS seed seed.btc.petertodd.org
2020-12-25T18:33:07Z 188 addresses found from DNS seeds
2020-12-25T18:33:07Z dnsseed thread exit

SECOND

# bitcoin-cli getpeerinfo
[
  {
    "id": 0,
    "addr": "79.146.37.169:8333",
    "addrlocal": "185.145.130.248:56434",
    "addrbind": "185.145.130.248:56434",
    "services": "0000000000000409",
    "servicesnames": [
      "NETWORK",
      "WITNESS",
      "NETWORK_LIMITED"
    ],
    "relaytxes": true,
    "lastsend": 1608921553,
    "lastrecv": 1608921554,
    "bytessent": 277490,
    "bytesrecv": 44773490,
    "conntime": 1608921516,
    "timeoffset": 1,
    "pingtime": 0.059366,
    "minping": 0.059366,
    "version": 70015,
    "subver": "/Satoshi:0.20.1/",
    "inbound": false,
    "addnode": false,
    "startingheight": 662946,
    "banscore": 0,
    "synced_headers": 662947,
    "synced_blocks": 544,
    "inflight": [
      842,
      844,
      846,
      848,
      849,
      850,
      851,
      852,
      853,
      854,
      855,
      856,
      857,
      858,
      859,
      860
    ],
    "whitelisted": false,
    "permissions": [
    ],
    "minfeefilter": 0.00001000,
    "bytessent_per_msg": {
      "feefilter": 32,
      "getaddr": 24,
      "getdata": 3529,
      "getheaders": 273601,
      "ping": 32,
      "pong": 32,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126
    },
    "bytesrecv_per_msg": {
      "addr": 30082,
      "block": 11510,
      "feefilter": 32,
      "getheaders": 1053,
      "headers": 44719452,
      "inv": 3534,
      "ping": 32,
      "pong": 32,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126
    }
  },
  {
    "id": 2,
    "addr": "43.225.62.107:8333",
    "addrbind": "185.145.130.248:55066",
    "services": "0000000000000409",
    "servicesnames": [
      "NETWORK",
      "WITNESS",
      "NETWORK_LIMITED"
    ],
    "relaytxes": true,
    "lastsend": 1608921554,
    "lastrecv": 1608921554,
    "bytessent": 21953,
    "bytesrecv": 2797391,
    "conntime": 1608921519,
    "timeoffset": 1,
    "pingtime": 0.558297,
    "minping": 0.558297,
    "version": 70015,
    "subver": "/Satoshi:0.20.1/",
    "inbound": false,
    "addnode": false,
    "startingheight": 662946,
    "banscore": 0,
    "synced_headers": 662947,
    "synced_blocks": 685,
    "inflight": [
      900,
      902,
      904,
      906,
      908,
      909,
      910,
      913,
      914,
      917,
      920,
      923,
      926,
      929,
      931
    ],
    "whitelisted": false,
    "permissions": [
    ],
    "minfeefilter": 0.00001000,
    "bytessent_per_msg": {
      "feefilter": 32,
      "getaddr": 24,
      "getdata": 2467,
      "getheaders": 19431,
      "ping": 32,
      "pong": 32,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126
    },
    "bytesrecv_per_msg": {
      "addr": 30027,
      "block": 7948,
      "feefilter": 32,
      "getheaders": 1053,
      "headers": 2754565,
      "inv": 3462,
      "ping": 32,
      "pong": 32,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126
    }
  },
  {
    "id": 4,
    "addr": "188.68.217.63:8333",
    "addrlocal": "185.145.130.248:33998",
    "addrbind": "185.145.130.248:33998",
    "services": "0000000000000409",
    "servicesnames": [
      "NETWORK",
      "WITNESS",
      "NETWORK_LIMITED"
    ],
    "relaytxes": true,
    "lastsend": 1608921554,
    "lastrecv": 1608921554,
    "bytessent": 210921,
    "bytesrecv": 26338330,
    "conntime": 1608921520,
    "timeoffset": 0,
    "pingtime": 0.056522,
    "minping": 0.056522,
    "version": 70015,
    "subver": "/Satoshi:0.20.1/",
    "inbound": false,
    "addnode": false,
    "startingheight": 662946,
    "banscore": 0,
    "synced_headers": 662947,
    "synced_blocks": 685,
    "inflight": [
      896,
      897,
      898,
      899,
      901,
      903,
      905,
      907,
      911,
      915,
      918,
      921,
      924,
      927,
      930,
      932
    ],
    "whitelisted": false,
    "permissions": [
    ],
    "minfeefilter": 0.00001071,
    "bytessent_per_msg": {
      "feefilter": 32,
      "getaddr": 24,
      "getdata": 41898,
      "getheaders": 168663,
      "ping": 32,
      "pong": 32,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126
    },
    "bytesrecv_per_msg": {
      "addr": 55,
      "block": 169500,
      "feefilter": 32,
      "getheaders": 1053,
      "headers": 26163187,
      "inv": 4199,
      "ping": 32,
      "pong": 32,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126
    }
  },
  {
    "id": 5,
    "addr": "173.255.204.124:8333",
    "addrlocal": "185.145.130.248:44828",
    "addrbind": "185.145.130.248:44828",
    "services": "0000000000000409",
    "servicesnames": [
      "NETWORK",
      "WITNESS",
      "NETWORK_LIMITED"
    ],
    "relaytxes": true,
    "lastsend": 1608921554,
    "lastrecv": 1608921554,
    "bytessent": 100736,
    "bytesrecv": 14485427,
    "conntime": 1608921521,
    "timeoffset": 1,
    "pingtime": 0.244784,
    "minping": 0.244784,
    "version": 70015,
    "subver": "/Satoshi:0.20.1/",
    "inbound": false,
    "addnode": false,
    "startingheight": 662946,
    "banscore": 0,
    "synced_headers": 662947,
    "synced_blocks": 681,
    "inflight": [
      879,
      881,
      883,
      884,
      885,
      886,
      887,
      888,
      889,
      891,
      912,
      916,
      919,
      922,
      925,
      928
    ],
    "whitelisted": false,
    "permissions": [
    ],
    "minfeefilter": 0.00000100,
    "bytessent_per_msg": {
      "feefilter": 32,
      "getaddr": 24,
      "getdata": 7433,
      "getheaders": 92943,
      "ping": 32,
      "pong": 32,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126
    },
    "bytesrecv_per_msg": {
      "addr": 30082,
      "block": 26859,
      "feefilter": 32,
      "getheaders": 1053,
      "headers": 14420509,
      "inv": 6588,
      "ping": 32,
      "pong": 32,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126
    }
  }
]

AAAAAAAAAAAND

# bitcoin-cli getblockchaininfo
{
  "chain": "main",
  "blocks": 96508,
  "headers": 662947,
  "bestblockhash": "000000000006d7fb6ea7d0ac5a7e57fbe3682376d0ab0efde5472fe04a0d7087",
  "difficulty": 8078.195257925088,
  "mediantime": 1291837049,
  "verificationprogress": 0.0003445196698115549,
  "initialblockdownload": true,
  "chainwork": "000000000000000000000000000000000000000000000000039eff23d72b7959",
  "size_on_disk": 66366950,
  "pruned": false,
  "softforks": {
    "bip34": {
      "type": "buried",
      "active": false,
      "height": 227931
    },
    "bip66": {
      "type": "buried",
      "active": false,
      "height": 363725
    },
    "bip65": {
      "type": "buried",
      "active": false,
      "height": 388381
    },
    "csv": {
      "type": "buried",
      "active": false,
      "height": 419328
    },
    "segwit": {
      "type": "buried",
      "active": false,
      "height": 481824
    }
  },
  "warnings": ""
}


Yahoo!
ok
try to get balance

Now is 0, ok. waiting

[NotATether]

My peer is empty, because ports 8332 / 18332 closed

No. 8332 (18332 for testnet) is for your RPC, as you've specified. Please don't open that port, people tend to scan those ports to find Bitcoin RPC to bruteforce.

Peers typically connect through 8333 but that is not necessary to be opened unless you need people to connect to you. Is there anything blocking any outgoing connection to other peers either by your local firewall rule or your service provider rules? How does the node function after attempting to get IPs from the DNS seeds?

DROP IP`s counting and counting (added), wtf ? some body attack my VDS ? )))

Yes it's an attempted attack. There's an automated botnet going around logging into everyone's SSH servers and trying common usernames and passwords. Usually each IP only makes one or two guesses but there are hundreds of IP addresses every day. They are even trying to attack my own servers, from checking my SSH logs. But if you are using a randomized password or are logging in using a private key then you are safe.

It seems that your server provider has already installed fail2ban, or you installed that yourself, which'll automatically detect these SSH login attempts and blacklist their IP addresses via iptables after a retry limit. So your server is already protected.

My peer is empty, because ports 8332 / 18332 closed

iptables is solution ? yeah

$ iptables -I INPUT -p tcp --dport 8332 -m state --state NEW -j ACCEPT
$ systemctl restart iptables

But
$ iptables -L is output next below

# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8332 state NEW
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8332 state NEW

Your iptables firewall was set to drop traffic from all ports except for 8332, that's why you couldn't get connections from 8333. You probably fixed this though since it works now.

# tail /var/lib/bitcoin/debug.log
2020-12-25T18:32:34Z Bound to 0.0.0.0:8333
2020-12-25T18:32:34Z init message: Loading P2P addresses...
2020-12-25T18:32:34Z Loaded 1986 addresses from peers.dat  5ms
~snip

Bolded is good news ?

The peers.dat file contains the addresses of all the bitcoin nodes that it knows. For various reasons some of these may no longer be online so it's picking peers to connect to that are already online. That's why your getpeerinfo output lists you have 5 peers so far but this number is going to grow over time the longer you leave bitcoind running.

try to get balance

Now is 0, ok. waiting

Your balance is 0 because your node is still in Initial Block Download mode (initialblockdownload=true in getblockchaininfo) and it hasn't downloaded the blocks that contain transactions for your addresses yet. You just have to wait for it to synchronize.

[avtorkoda]

I'm out of luck
--
I`m STUCK

{
  "chain": "main",
  "blocks": 576820,
  "headers": 663021,
  "bestblockhash": "000000000000000000040dd6cced9764e196756fbfe6c9da3627537e3d198031",
  "difficulty": 6704632680587.417,
  "mediantime": 1558299525,
  "verificationprogress": 0.6982350103156203,
  "initialblockdownload": true,
  "chainwork": "0000000000000000000000000000000000000000064b45e709a359e7c317012f",
  "size_on_disk": 249975786025,
  "pruned": false,

IBD=true, ok
But, verificationprogress is frozen/ and no new blocks loaded to my server. What happens ?

Today my config

txindex=1
server=1
daemon=1
rest=1
rpcuser=****
rpcpassword=****
rpcport=8332
rpcbind=127.0.0.1
rpcallowip=127.0.0.1
datadir=/mnt/bitcoin

[NotATether]

Please post your debug.log so we can have a better idea about your problem.

IBD=true, ok
But, verificationprogress is frozen/ and no new blocks loaded to my server. What happens ?

You can try some of the suggestions in What can I do when the blockchain synchronization is stuck at a specific block? depending on the state of the node.

If you don't have a lot of peers or even no peers, then it suggests deleting peers.dat and restarting Bitcoin Core:

Delete $HOME/.bitcoin/peers.dat
Restart bitcoind
Afterwards, new compatible peers will be found, and hopefully, you'll start processing blocks as expected again.

If you don't have a problem with peers, another answer suggests reindexing the blockchain with -reindex in case you are stuck on an orphaned block:

I had a similar problem, but the -rescan option didn’t help.

In my case, there were a lot of lines referring to orphan blocks in my debug.log file (not 100 % sure it’s related but it may):

~

Finally, I tried to restart the client with the -reindex option which fixed my problem (but took 100 % of my CPU usage for several hours while reprocessing the blockchain).

So if the rescan option don’t work, don’t give up, try the reindex option!

[avtorkoda]

debug there https://drive.google.com/file/d/1MlMv7o0X3jS1Di3FEfHaE7k6NfRfXeLz/view?usp=sharing

Ohhhh


$ bitcoind -reindex
Error: Config setting for -rpcbind only applied on test network when in [test] section.

I modify to

$ bitcoind -reindex -rpcbind=127.0.0.1 -rpcport=8332 -datadir=/mnt/bitcoin -conf=/etc/bitcoin/bitcoin.conf

not affected.... no re-index, nothing to-do...

Ok, try

$ bitcoind -reindex -rpcbind=127.0.0.1 -rpcport=8332 -datadir=/mnt/bitcoin

ouput

2020-12-28T21:36:40Z Bitcoin Core version v0.20.1.0-g7ff64311bee570874c4f0dfa18f518552188df08 (release build)
2020-12-28T21:36:40Z Assuming ancestors of block 0000000000000000000f2adce67e49b0b6bdeb9de8b7c3d7e93b21e7fc1e819d have valid signatures.
2020-12-28T21:36:40Z Setting nMinimumChainWork=00000000000000000000000000000000000000000e1ab5ec9348e9f4b8eb8154
2020-12-28T21:36:40Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
2020-12-28T21:36:40Z Using RdSeed as additional entropy source
2020-12-28T21:36:40Z Using RdRand as an additional entropy source
2020-12-28T21:36:40Z Default data directory /root/.bitcoin
2020-12-28T21:36:40Z Using data directory /mnt/bitcoin
2020-12-28T21:36:40Z Config file: /mnt/bitcoin/bitcoin.conf (not found, skipping)
2020-12-28T21:36:40Z Command-line arg: datadir="/mnt/bitcoin"
2020-12-28T21:36:40Z Command-line arg: rescan=""
2020-12-28T21:36:40Z Command-line arg: rpcbind=****
2020-12-28T21:36:40Z Command-line arg: rpcport="8332"
2020-12-28T21:36:40Z Using at most 125 automatic connections (1024 file descriptors available)
2020-12-28T21:36:40Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2020-12-28T21:36:40Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2020-12-28T21:36:40Z Script verification uses 3 additional threads
2020-12-28T21:36:40Z scheduler thread start
2020-12-28T21:36:40Z WARNING: option -rpcbind was ignored because -rpcallowip was not specified, refusing to allow everyone to connect
2020-12-28T21:36:40Z libevent: getaddrinfo: address family for nodename not supported
2020-12-28T21:36:40Z Binding RPC on address ::1 port 8332 failed.
2020-12-28T21:36:40Z Binding RPC on address 127.0.0.1 port 8332 failed.
2020-12-28T21:36:40Z Unable to bind any endpoint for RPC server
2020-12-28T21:36:40Z Error: Unable to start HTTP server. See debug log for details.
Error: Unable to start HTTP server. See debug log for details.
2020-12-28T21:36:40Z Shutdown: In progress...
2020-12-28T21:36:40Z scheduler thread

I`m copied conf file to /mnt/bitcoin/ and try again

$ bitcoind -reindex -rpcbind=127.0.0.1 -rpcport=8332 -datadir=/mnt/bitcoin
>Bitcoin Core starting

Hm. after try not re-index. Arrrr

[HCP]

Have you checked the free disk space on the server again using the "df -h" command? It's possible that your server has simply run out of space for new blocks.

From your earlier screenshots, it had something like 370gigs free before it had started downloading any blocks at all... my Bitcoin datadir folder is now pushing 400gigs... as I have txindex=1 set as well, and the tx indexes are taking up something like 28gigs on their own.

[NotATether]

Ok, try

$ bitcoind -reindex -rpcbind=127.0.0.1 -rpcport=8332 -datadir=/mnt/bitcoin

ouput

.......
2020-12-28T21:36:40Z Binding RPC on address ::1 port 8332 failed.
2020-12-28T21:36:40Z Binding RPC on address 127.0.0.1 port 8332 failed.
2020-12-28T21:36:40Z Unable to bind any endpoint for RPC server
2020-12-28T21:36:40Z Error: Unable to start HTTP server. See debug log for details.
Error: Unable to start HTTP server. See debug log for details.
2020-12-28T21:36:40Z Shutdown: In progress...
2020-12-28T21:36:40Z scheduler thread

You are getting this error because you are trying to run a second bitcoind on the same port 8332. Terminate the other bitcoind process before you run this one and the reindexing should work.

Have you checked the free disk space on the server again using the "df -h" command? It's possible that your server has simply run out of space for new blocks.

From your earlier screenshots, it had something like 370gigs free before it had started downloading any blocks at all... my Bitcoin datadir folder is now pushing 400gigs... as I have txindex=1 set as well, and the tx indexes are taking up something like 28gigs on their own.

It appears that OP has 114GB of disk space free in the data partition where the blockchain is being stored.