Is it fair to compare the decision body responsible for forking a blockchain as ‘escrow officers’? How can users of the blockchain network dare to the treat the distributed ledger as immutable as long as forking (ledger tampering) exists as a corrective measure? Who are these people and how who holds them accountable?
Currently I’m reading a great book Mastering Bitcoin and the author on his first articles suggests to the reader build from the source Bitcoin Core environment and down load the whole blockchain ledger (about 60Gb) to my local storage to be able perform common queries. But it’s to long way for me.
So, is there any where on Internet already exist an online
bitcoin-cli command line tool where I could practice?
I I have a GekkoScience Compac BM1384 bitcoin miner that I am trying to get working with CGMiner on my Raspberry Pi. It is really annoying though, as it doesnt detect any devices on startup. However, when I go into USB management and select I it lists my bitcoin miner and it says “inactive”. But when I try to enable it it says “invalid selection’.
Bumping my VPS to 1GB of physical RAM stopped the crashing issue… UNTIL said VPS ran out of disc space.
prune=10240 to my
~/.bitcoin/bitcoin.conf file such that the blockchain file would start pruning transaction history upon reaching 10GB filesize (1024 MB * 10 = 10GB).
This seems to be a memory issue, not a VPN networking issue. I turned OpenVPN off and restarted
bitcoind only to see it silently crash again.
I’ve now added a 1GB swapfile to expand the available memory space (risk is this will cause performance issues for the OS). Will update once again if this solves the issue. If not, I will probably end up trying to upgrade the VPS instance to 1GB of physical RAM from 512MB.
Found some interesting stuff in the log relating to tor…
root@sf-vps:~# cat ~/.bitcoin/debug.log | grep tor -i
2016-11-13 16:52:21 Default data directory /root/.bitcoin
2016-11-13 16:52:21 Using data directory /root/.bitcoin
2016-11-13 16:52:21 Using at most 125 connections (1024 file descriptors available)
2016-11-13 16:52:29 torcontrol thread start
2016-11-13 17:08:43 Default data directory /root/.bitcoin
2016-11-13 17:08:43 Using data directory /root/.bitcoin
2016-11-13 17:08:43 Using at most 125 connections (1024 file descriptors available)
2016-11-13 17:08:50 torcontrol thread start
2016-11-13 17:08:50 tor: Error connecting to Tor control socket
2016-11-13 17:08:50 tor: Not connected to Tor control port 127.0.0.1:9051, trying to reconnect
2016-11-13 17:08:51 tor: Error connecting to Tor control socket
2016-11-13 17:08:51 tor: Not connected to Tor control port 127.0.0.1:9051, trying to reconnect
2016-11-13 17:08:52 tor: Error connecting to Tor control socket
2016-11-13 17:08:52 tor: Not connected to Tor control port 127.0.0.1:9051, trying to reconnect
I’ve installed the Bitcoin software on Ubuntu 16.04. I’m able to run
bitcoind -daemon for a few minutes, but after a while the process crashes.
Interestingly, I don’t see any reasons in
~/.bitcoin/debug.log explaining why the program might have terminated.
I suspect a couple of things:
- Not enough disc space to store the entire blockchain. However, I don’t think this is the case as running
df - hshows a combined total of only ~41% disc consumption:
root@sf-vps:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 241M 0 241M 0% /dev
tmpfs 50M 3.1M 47M 7% /run
/dev/vda1 20G 6.3G 13G 34% /
tmpfs 247M 0 247M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 247M 0 247M 0% /sys/fs/cgroup
tmpfs 50M 0 50M 0% /run/user/0
- Server is not able to receive inbound messages as I’m running a VPN. Is it possible that I’m experiencing a networking issue, e.g. inbound traffic to port 8333 (the default for
bitcoind) is not being allowed through my VPN? I can’t remember how to change the VPN config to allow connections on specific ports, but that’s where I’m looking next…
root@sf-vps:~# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 188.8.131.52 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.12.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
184.108.40.206 0.0.0.0 255.255.240.0 U 0 0 0 eth0
Thanks in advance for your help 🙂
I have two specific questions:
How does a new user realizes which is the correct copy of the ledger to be used when initially updating(downloading) the ledger, and why is it that a user cannot deceive it by broadcasting its ledgers manytimes. (there by giving the system a pseudo idea that that is indeed the majority ledger)
How does one understand if the two ledgers are the same? Does the hash function change with the last transaction? My specific doubt would be that considering that the hash will change with the guesses too even if the last block info is the same then how does the system realize that these are from the same block even if their final values are diff.
I’m trying to setup my own Bitcoin node on
Ubuntu 16.04.1 LTS.
Right now, I’ve stuck with blockchain synchronization. I’m letting
bitcoind to run every day for at least 10-12 hours while I work and it already takes three days to download 83% of the entire data.
I have very good Internet connection, it should take no more than two hours to download 80 GB of data, however, it’s taking at least 30 hours already. My connection is practically free from other downloads most of the time.
I’ve googled this problem: some people say that current version of the
bitcoind is so fast that it doesn’t matter how blockchain is downloaded throught the Bitcoin network or by torrent. Other people say, that it takes a week to download the entire blockchain.
Is there a way to optimize my setup to make it download blockchain much-much faster?
Or do I better download it via some torrent and then synchronize the differences from the network? What is the best place to find such torrent file or magnet link? Also, is it safe to download blockchain from some third-party, will bitcoind validate it?
SO, generally speaking, what is the best way to download the blockchain in order to setup a working up-to-date Bitcoin node?
$ cat /etc/issue Ubuntu 16.04.1 LTS \n \l $ uname -a Linux destiny 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux $ bitcoind -version Bitcoin Core Daemon version v0.13.1.0-g03422e5