Announcing BitcoinUnlimited v0.12.0: Experimental Release

[Christoph Bergmann]

@sickpig

ok. Thanks for the help

2016-02-26 14:40:40 Bitcoin version v0.12.0.0-aa76df5 (2016-02-23 22:35:54 -0500)
2016-02-26 14:40:40 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2016-02-26 14:40:40 Using OpenSSL version OpenSSL 1.0.1k 8 Jan 2015
2016-02-26 14:40:40 Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2016-02-26 14:40:40 Default data directory /home/christoph/.bitcoin
2016-02-26 14:40:40 Using data directory /media/christoph/3A483E88483E4345/Speicher/Blockchain
2016-02-26 14:40:40 Using config file /media/christoph/3A483E88483E4345/Speicher/Blockchain/bitcoin.conf
2016-02-26 14:40:40 Using at most 125 connections (1024 file descriptors available)
2016-02-26 14:40:40 Using 2 threads for script verification
2016-02-26 14:40:40 Using wallet wallet.dat
2016-02-26 14:40:40 init message: Verifying wallet...
2016-02-26 14:40:40 scheduler thread start
2016-02-26 14:40:40 CDBEnv::Open: LogDir=/media/christoph/3A483E88483E4345/Speicher/Blockchain/database ErrorFile=/media/christoph/3A483E88483E4345/Speicher/Blockchain/db.log
2016-02-26 14:40:40 Bound to [::]:8333
2016-02-26 14:40:40 Bound to 0.0.0.0:8333
2016-02-26 14:40:40 Cache configuration:
2016-02-26 14:40:40 * Using 2.0MiB for block index database
2016-02-26 14:40:40 * Using 32.5MiB for chain state database
2016-02-26 14:40:40 * Using 65.5MiB for in-memory UTXO set
2016-02-26 14:40:40 init message: Loading block index...
2016-02-26 14:40:40 Opening LevelDB in /media/christoph/3A483E88483E4345/Speicher/Blockchain/blocks/index
2016-02-26 14:40:40 Opened LevelDB successfully
2016-02-26 14:40:40 Using obfuscation key for /media/christoph/3A483E88483E4345/Speicher/Blockchain/blocks/index: 0000000000000000
2016-02-26 14:40:40 Opening LevelDB in /media/christoph/3A483E88483E4345/Speicher/Blockchain/chainstate
2016-02-26 14:40:41 Opened LevelDB successfully
2016-02-26 14:40:41 Using obfuscation key for /media/christoph/3A483E88483E4345/Speicher/Blockchain/chainstate: 0000000000000000
2016-02-26 14:40:45 LoadBlockIndexDB: last block file = 454
2016-02-26 14:40:45 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=18, size=17380944, heights=400119...400136, time=2016-02-26...2016-02-26)
2016-02-26 14:40:45 Checking all blk files are present...
2016-02-26 14:40:46 LoadBlockIndexDB: transaction index disabled
2016-02-26 14:40:46 LoadBlockIndexDB: hashBestChain=000000000000000001905099f923a45a8c3e9a37b96d4d7f590c6e7ee8082c88 height=400136 date=2016-02-26 14:29:18 progress=0.999994
2016-02-26 14:40:46 init message: Verifying blocks...
2016-02-26 14:40:46 Verifying last 288 blocks at level 3
2016-02-26 14:40:46 Acceptable block: ver:4 time:1456496958 size: 749077 Tx:1983 Sig:4422
[-snip-]
2016-02-26 14:42:05 Acceptable block: ver:4 time:1456321449 size: 997202 Tx:2325 Sig:4334
2016-02-26 14:42:05 No coin database inconsistencies in last 4 blocks (5723 transactions)
2016-02-26 14:42:06  block index           85509ms
2016-02-26 14:42:06 init message: Loading wallet...
2016-02-26 14:42:06 nFileVersion = 120000
2016-02-26 14:42:06 Keys: 0 plaintext, 359 encrypted, 147 w/ metadata, 359 total
2016-02-26 14:42:06  wallet                  229ms
2016-02-26 14:42:06 init message: Activating best chain...
2016-02-26 14:42:06 mapBlockIndex.size() = 400183
2016-02-26 14:42:06 nBestHeight = 400136
2016-02-26 14:42:06 setKeyPool.size() = 100
2016-02-26 14:42:06 mapWallet.size() = 319
2016-02-26 14:42:06 mapAddressBook.size() = 130
2016-02-26 14:42:06 init message: Loading addresses...
2016-02-26 14:42:06 torcontrol thread start
2016-02-26 14:42:06 Loaded 62018 addresses from peers.dat  286ms
2016-02-26 14:42:06 dnsseed thread start
2016-02-26 14:42:06 net thread start
2016-02-26 14:42:06 init message: Done loading
2016-02-26 14:42:06 opencon thread start
2016-02-26 14:42:06 msghand thread start
2016-02-26 14:42:06 addcon thread start
2016-02-26 14:42:06 AddToWallet e5f659ca1e1feb0435bd01cfe608ceb0268b62378bbaaaefc58f574e9af61423  
2016-02-26 14:42:06 AddToWallet d6fc4546315525a9c970e297cc95a1e8a2c0d8584eaeb458ab64fa9080bcdd4f  
2016-02-26 14:42:06 GUI: Platform customization: "other"
2016-02-26 14:42:06 receive version message: /libbitcoin:2.11.0/: version 70001, blocks=398827, us=0.0.0.0:0, peer=4
2016-02-26 14:42:06 GUI: PaymentServer::LoadRootCAs: Loaded  169  root certificates
2016-02-26 14:42:14 receive version message: /bitnodes.21.co:0.1/: version 70002, blocks=400136, us=5.199.179.121:8333, peer=6
2016-02-26 14:42:17 P2P peers available. Skipped DNS seeding.
2016-02-26 14:42:17 dnsseed thread exit

Connecting ...

016-02-26 14:42:18 connect() to 47.16.236.249:8333 failed after select(): Keine Route zum Zielrechner (113)
2016-02-26 14:42:32 connect() to 78.242.163.56:8333 failed after select(): Keine Route zum Zielrechner (113)
2016-02-26 14:42:38 connect() to 5.189.44.188:8333 failed after select(): Verbindungsaufbau abgelehnt (111)
2016-02-26 14:42:50 receive version message: /Snoopy:0.2.1/: version 70001, blocks=0, us=5.199.179.121:8333, peer=7
2016-02-26 14:42:50 socket recv error Die Verbindung wurde vom Kommunikationspartner zurückgesetzt (104)
2016-02-26 14:43:29 receive version message: /bitnodes.21.co:0.1/: version 70002, blocks=400136, us=5.199.179.121:8333, peer=8
2016-02-26 14:43:34 ProcessMessages: advertizing address 5.199.179.121:8333
2016-02-26 14:43:34 receive version message: /Satoshi:0.11.0/: version 70002, blocks=400136, us=5.199.179.121:51002, peer=9
2016-02-26 14:43:40 connect() to 89.107.197.106:8333 failed after select(): Verbindungsaufbau abgelehnt (111)
2016-02-26 14:43:41 ProcessMessages: advertizing address 5.199.179.121:8333
2016-02-26 14:43:41 receive version message: /Satoshi:0.12.0/: version 70012, blocks=400136, us=5.199.179.121:50877, peer=10
2016-02-26 14:44:09 connect() to 24.133.163.165:8333 failed after select(): Verbindungsaufbau abgelehnt (111)
2016-02-26 14:44:21 ProcessMessages: advertizing address 5.199.179.121:8333
2016-02-26 14:44:21 receive version message: /Satoshi:0.9.2.1/: version 70002, blocks=400136, us=5.199.179.121:50723, peer=11
2016-02-26 14:44:22 ProcessMessages: advertizing address 5.199.179.121:8333
2016-02-26 14:44:22 receive version message: /Satoshi:0.10.2/: version 70002, blocks=400136, us=5.199.179.121:51003, peer=12
2016-02-26 14:44:37 ProcessMessages: advertizing address 5.199.179.121:8333
2016-02-26 14:44:37 receive version message: /Satoshi:0.11.2/: version 70002, blocks=400061, us=5.199.179.121:34843, peer=13
2016-02-26 14:44:49 receive version message: /Snoopy:0.2.1/: version 70001, blocks=0, us=5.199.179.121:8333, peer=14
2016-02-26 14:44:54 Acceptable block: ver:4 time:1456497815 size: 934530 Tx:2295 Sig:4603
2016-02-26 14:45:15 UpdateTip: new best=0000000000000000023463892e12724c14760bb9412472230cdc6368bbc70040  height=400137  log2_work=84.189366  tx=112669917  date=2016-02-26 14:43:35 progress=0.999999  cache=11.4MiB(6290tx)
2016-02-26 14:45:15 UpdateTip: 4 of last 100 blocks above version 536870912
2016-02-26 14:45:15 ProcessMessages: advertizing address 5.199.179.121:8333
2016-02-26 14:45:15 receive version message: /Satoshi:0.11.0/: version 70002, blocks=400137, us=5.199.179.121:45847, peer=15
2016-02-26 14:45:21 ProcessMessages: advertizing address 5.199.179.121:8333
2016-02-26 14:45:21 receive version message: /Satoshi:0.11.1/: version 70002, blocks=400137, us=5.199.179.121:48554, peer=16
2016-02-26 14:45:27 connect() to 92.204.110.176:8333 failed after select(): Keine Route zum Zielrechner (113)
2016-02-26 14:45:28 ProcessMessages: advertizing address 5.199.179.121:8333
2016-02-26 14:45:28 receive version message: /Satoshi:0.11.1/: version 70002, blocks=400137, us=5.199.179.121:46693, peer=17
2016-02-26 14:46:07 receive version message: /bitnodes.21.co:0.1/: version 70002, blocks=400136, us=5.199.179.121:8333, peer=18
2016-02-26 14:46:14 receive version message: /Satoshi:0.11.0/: version 70002, blocks=375495, us=5.199.179.121:8333, peer=19
2016-02-26 14:46:26 receive version message: /bitnodes.21.co:0.1/: version 70002, blocks=400136, us=5.199.179.121:8333, peer=20
2016-02-26 14:46:57 receive version message: /BitCoinJ:0.11.2/MultiBit:0.5.19/: version 70001, blocks=400137, us=127.0.0.1:8333, peer=21
2016-02-26 14:47:36 receive version message: /bitnodes.21.co:0.1/: version 70002, blocks=400136, us=5.199.179.121:8333, peer=22
2016-02-26 14:47:40 receive version message: /bitnodes.21.co:0.1/: version 70002, blocks=400136, us=5.199.179.121:8333, peer=23
2016-02-26 14:47:50 receive version message: /Snoopy:0.2.1/: version 70001, blocks=0, us=5.199.179.121:8333, peer=24
2016-02-26 14:47:50 socket recv error Die Verbindung wurde vom Kommunikationspartner zurückgesetzt (104)
2016-02-26 14:47:50 receive version message: /BitCoinJ:0.11.3/: version 70001, blocks=400137, us=127.0.0.1:8333, peer=25
2016-02-26 14:47:58 receive version message: /bitcoinj:0.13.4/Bitcoin Wallet:4.46/: version 70001, blocks=400136, us=127.0.0.1:8333, peer=26

Maybe this helps ...

 

[freetrader]

@Christoph Bergmann : You are getting a lot of 'no route to host' connection failures. Something is wrong on the networking end of your client, I think.

Is there possibly a firewall blocking certain outgoing connections from your end?

---

about your log timestamps:

Logging in software sometimes uses UTC, that might explain a 2-hour offset from your current time.
Not sure if bitcoind does this.

The alternative is that UTC time and the timezone on the machine where it's running are not configured correctly. If it's a Ubuntu, perhaps check if you're running NTP and are correctly time-synchronised.

 

[Peter Tschipper]

yes UTC timestamps are used

 

[theZerg]

yes logs use UTC time: @Christoph Bergmann PM me your IP address and I'll configure a node to connect to you

EDIT: LOL timing

 

[sickpig]

@Christoph Bergmann

regarding your "no route to host" (Keine Route zum Zielrechner)
are you able to ping 47.16.236.249 successfully?

 

[Christoph Bergmann]

@freetrader:

now things go complicated ...
I'm not aware of a firewall. Using LinuxMint 17.2 (rafaela), have not installed anything else.

I'm on a LAN with my router, this is a fritz.box (some kind of german installation), I opened Port 8330-8334 as a http-server with tcp.

My fritz.box uses Port 443 as TCP-Port for https.

That's all I can say.

@sickpig

I'm really no expert, neither with networking nor with linux. But that's what I got in the terminal

PING 47.16.236.249 (47.16.236.249) 56(84) bytes of data.
64 bytes from 47.16.236.249: icmp_seq=1 ttl=238 time=105 ms
[-snip-]
64 bytes from 47.16.236.249: icmp_seq=37 ttl=238 time=107 ms
--- 47.16.236.249 ping statistics ---
37 packets transmitted, 35 received, 5% packet loss, time 36051ms
rtt min/avg/max/mdev = 103.938/109.685/136.272/9.261 ms

 

[freetrader]

@Christoph Bergmann :

Hmm, Fritz Box should be no problem per se , this guy had what looked like a similar problem:
https://www.reddit.com/r/Bitcoin/comments/44c4z1/fullnode_set_up_but_only_8_connections_port_8333/

Note the imgur image that post links to? -- his mistake is the "An Port" field set to 80 - it should be 8333.
Oh, and there's no good reason IMHO to open a wider incoming range than 8333-8333 for the standard client, not that it would make a difference to the functioning.

Since you mentioned http-server in your previous post, please double-check your Fritz Box config.

Once you are confident the Fritz Box is set up ok, you should check using bitnodes.21.co that your node's port 8333 is reachable from the outside.

Let me know if you need more detailed instructions.

 

[sickpig]

so your able to ping even if with a fairly high percentage of packet loss.

I've just checked the tree failed connection you had at the beginning of your log, all of them has no service responding to TCP 8333 port (78.242.163.56, 78.156.107.88, 47.16.236.249).

So it's not a problem related to your network.

What's the precise command you're using to execute your bitcoin-qt instance?

 

[sgbett]

ok gang. I have added both theZerg and Christoph's nodes to my bitcoin.conf and restarted. Which i figure makes me good to go.

my nodes are all fixed IP (all AWS but different availability zones) and I planning on running them for the foreseeable future.

great work. I think BU is absolutely way forward.

 

[Christoph Bergmann]

It's great if we connect our nodes, since our network in the network should save bandwith and allow our nodes to build up more connections .-

@sgbett
I see one of your nodes --

@sickpig

Thanks, that was the information I always wanted to share. I run it following the instruction for ubuntu on the bitcoin unlimited website: I unpacked the file in a folder, cd in this directory and type "nohup ./bitcoin-qt &"

My .conf and wallet.dat etc. are in another folder, home/.bitcoin, and my blockchain is on another harddisk.

 

[freetrader]

@sickpig - I could connect to 78.156.107.88 on port 8333.

@Christoph Bergmann : does bitnodes.21.co show your node as reachable when you type your home IP address in the "CHECK NODE" field?

 

[sickpig]

@Christoph Bergmann

try this instead

nohup ./bitcoin-qt -conf=/full/path/to/your/bitcoin.conf -data=/full/path/to/your/datadir &

 

[Christoph Bergmann]

@sickpig - I could connect to 78.156.107.88 on port 8333.

@Christoph Bergmann : does bitnodes.21.co show your node as reachable when you type your home IP address in the "CHECK NODE" field?

Ah, I forgot: yes
[doublepost=1456503016][/doublepost]

@Christoph Bergmann

try this instead

nohup ./bitcoin-qt -conf=/full/path/to/your/bitcoin.conf -data=/full/path/to/your/datadir &

Yeah! It's working. I'm immediately connected to 7 unlimited nodes.

Thank you!

 

[Christoph Bergmann]

... aaand here he is

2016-02-26 16:33:05 Requesting Thinblock 00000000000000000652675d5e609e51efbd92535fe1109e369ede777ac9ac7b from peer 169.45.95.196 (8)
2016-02-26 16:33:06 Received thinblock 00000000000000000652675d5e609e51efbd92535fe1109e369ede777ac9ac7b from peer 169.45.95.196 (8). Size 369923 bytes.
2016-02-26 16:33:06 thinblock waiting for: 0, unnecessary: 0, txs: 1376 full: 342
2016-02-26 16:33:06 Reassembled thin block for 00000000000000000652675d5e609e51efbd92535fe1109e369ede777ac9ac7b (979158 bytes). Message was 369923 bytes, compression ratio 2.65

I officially saved ~600 kb bandwidth!

Edit @moderator: Wouldn't it be better to move the instruction to my first thinblock in another thread an replace it by a link in this thread?

 

[Peter Tschipper]

@Christoph Bergmann well done, thanks for working through the issues.

 

[sickpig]

@Christoph Bergmann

I'm glad it's working.

Aiming to properly understand what was the problem, would you mind to share the actual command you have used to make it work?

i'm asking because based on information you provided it should have worked even without specifying the conf file and the datadir explicitly on the command line.

Also providing the content of the bitcoin.conf specified with -conf parameter would be helpful to understand what happened.

One last thing: you said that datadir is on a path different than the path where your wallet and bitcoin.conf file are stored.

Do you happen to have a second bitcoin.conf in the datadir path?

 

[theZerg]

@Christoph Bergmann... its a beta release. I think that a good place for feedback is the release announce thread... or good enough anyway...

 

[Christoph Bergmann]

@Christoph Bergmann

I'm glad it's working.

Aiming to properly understand what was the problem, would you mind to share the actual command you have used to make it work?

i'm asking because based on information you provided it should have worked even without specifying the conf file and the datadir explicitly on the command line.

Also providing the content of the bitcoin.conf specified with -conf parameter would be helpful to understand what happened.

One last thing: you said that datadir is on a path different than the path where your wallet and bitcoin.conf file are stored.

Do you happen to have a second bitcoin.conf in the datadir path?

I typed in exactly the command line you recommended

nohup ./bitcoin-qt -conf=/full/path/to/your/bitcoin.conf -data=/full/path/to/your/datadir &

Do you happen to have a second bitcoin.conf in the datadir path?

Hell, yes. It was empty beside some armory-stuff. I deleted it. Do you think this file did, after things moved to datadir, dominated my configuration?

 

[sickpig]

@Christoph Bergmann

This the only plausible explanation (a second bitcoin.conf)

Still there are missing pieces to complete the puzzle.

Why bitcoin-qt looked at the values stored in your 2nd bitcoin.conf placed in your datadir rather than keeping the value specified in the default one?

maybe there's a bug in the algo that determine conf precedence...

 

[Christoph Bergmann]

I noticed in core 0.12 it is not possible to send a transaction to yourself. I wanted to try the fee management improvements by sending a transaction to one of my addresses. But it doesn't propagate the transaction, just says "Eigenüberweisung".

I don't like this. It's an obstacle in structuring your balances. Do you think it is worth the work to enable those transactions again?

.--


Other thing.

When I started my node today it was unable to find the unlimited nodes whose IPs I recently wrote in my .conf. With this configuration my client tends to not search for peers by itself, even if the number of peers goes down when some peer disconnects.

I noticed this before, as the number of outgoing peers fall from intiatlly 8 to 5 and 4. As I started in today I didn't find more than 1 or 2 peers. So I searched for some unlimited 0.12 peers and wrote their IP in my .conf. I thought: more is more and made 20 entries.

Now I'm connected to most of you, with a focus on europe. But I think my slot are full and I don't get incoming peers.

Anybody knows how to solve this?