No block source available - SOLVED

[saffabit]

Hello fellow bitcoiners,


This is my problem also.

I updated to the most recent Bitcoin-qt wallet version: v0.8.4-beta and it gives the "No block source available" (Ubuntu 12.04)
I use the socks 5 proxy and I run the Vidalia bundle, for safety sake. I have disable this and it now connects but the blockchain is updating slower than ever before?

But this is not a good solution for me. I need my wallet TOR'd. It is not acceptable that we drop our guard to connect to the blockchain.

What should I do to get it working as before? Do I re-install the previous version?

Please help.

A complete solution will be rewarded with $100 worth in BTC.

[saffabit]

It seems like it is only Newbies that read this section

What are the chances that a solution can be found in this part of the forums ? (rhetorical question)

I have run the v0.8.4-beta bitcoin-qt wallet on 3 machines, Ubuntu 13.04; Ubuntu 12.04 and Windows 7. All 3 have the same
response when socks 5 TOR'd ... I have taken 2 off TOR and they are updating.... very slowly, very much slower than when they
were working under TOR.

Please help with a workable solution and I will donate .736 BTC = $ 100

thank you

[gweedo]

Are you setting the port to 9050? And having it set to localhost I would use ip 127.0.0.1. Also make sure in the bitcoin-qt settings that you selected socks 5 and not 4.

[Dare]

No block source sounds like Bitcoin-Qt is failing to connect to the network; try manually adding a node using addnode.

It may also have something to do with the recent bug where Bitcoin-Qt fails to process one of the transactions in block 256818 (bug report), though that should have passed by now. Try adding --checklevel=2 to the command line.

[saffabit]

Hello Gweedo and Dare

I have this happening on 3 machines.
And this 'problem' began after upgrading bitcoin-qt v0.8.4-beta.

I can confirm that the wallet was on socks 5 (127.0.0.1) (9050)
And on the Vidalia GUI - Settings - Advanced - The address is (127.0.0.1) (9151) - I tried changing it to 9050 but it couldn't use that port.
Below comes from the Vidalia message log:
Sep 10 23:42:30.094 [Notice] Opening Socks listener on 127.0.0.1:9150
Sep 10 23:42:30.094 [Notice] Opening Control listener on 127.0.0.1:9151

All 3 wallets are not TOR'd and they are connected to 8 active connections. So my connection to peers is fine.

The only part that was changed was the wallet, everything else is exactly as it was before, the previous wallet version worked fine.

To Dare: Im too much of newbie to follow your instructions... I pressed ctrl + alt + T and tried the command line in the terminal, is this correct?

Thanks for the assistance, I await the next suggestions

[nomnomnom]

I can confirm that the wallet was on socks 5 (127.0.0.1) (9050)
[...]
Below comes from the Vidalia message log:
Sep 10 23:42:30.094 [Notice] Opening Socks listener on 127.0.0.1:9150
Sep 10 23:42:30.094 [Notice] Opening Control listener on 127.0.0.1:9151

Try setting bitcoin-qt proxy to 127.0.0.1:9150, not sure if the torbundle still does
this but sometimes the port number changed in earlier versions

The options that dare posted can also be added to the bitcoin.conf (file in the same directory like wallet.dat)
Like:

Code:

addnode=1.2.3.4
checklevel=2

To get the blockchain faster you could maybe try the bootstrap.torrent:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/

[Dare]

To Dare: Im too much of newbie to follow your instructions... I pressed ctrl + alt + T and tried the command line in the terminal, is this correct?

The easiest way to do this is by going to the menu Help->Debug Window, clicking the Console tab, then typing "addnode <node ip> add", replacing "<node ip>" with the IP address of a running node. A list of nodes recently used by blockchain.info can be found here, if you try a few at least one should still be running (if not all).

Gweedo is right about the checklevel command, I misread your question. It won't affect the problem you're having.

You can also try some of the solutions from this Bitcoin StackExchange question, but make sure you back up your wallet.dat first.

[Dare]

Hello Gweedo and Dare

I have this happening on 3 machines.
And this 'problem' began after upgrading bitcoin-qt v0.8.4-beta.

I can confirm that the wallet was on socks 5 (127.0.0.1) (9050)
And on the Vidalia GUI - Settings - Advanced - The address is (127.0.0.1) (9151) - I tried changing it to 9050 but it couldn't use that port.
Below comes from the Vidalia message log:
Sep 10 23:42:30.094 [Notice] Opening Socks listener on 127.0.0.1:9150
Sep 10 23:42:30.094 [Notice] Opening Control listener on 127.0.0.1:9151

All 3 wallets are not TOR'd and they are connected to 8 active connections. So my connection to peers is fine.

The only part that was changed was the wallet, everything else is exactly as it was before, the previous wallet version worked fine.

To Dare: Im too much of newbie to follow your instructions... I pressed ctrl + alt + T and tried the command line in the terminal, is this correct?

Thanks for the assistance, I await the next suggestions

Then change the wallet to port 9051 that is probably the issue if your tor is on port 9051 make sure bitcoin-qt is.

Acutally, I believe the port you want Bitcoin-Qt to be using is 9150, since that's the Socks listener (and what the Tor Browser uses as its proxy port). If your Bitcoin-Qt is trying to connect to a Socks proxy on 9050, then that's probably the source of your problem; you're not connecting to the proxy (and through it, the bitcoin network) since the proxy's on port 9150.

To fix the problem, to the menu Settings->Options and click the Network tab, then set the IP to 127.0.0.1 (if it isn't already) and the port to 9150, and make sure the SOCKS Version is still set to 5. (I suspect you already know this since you configured it in the first place, but the next person who finds this thread looking for help might not.)

I just tested this myself, and it worked fine, though it took slightly longer to connect than usual (about 1-2 minutes, compared to a few seconds, to reach 8 connections).

[saffabit]

Hello all,

Thank you for all the inputs...

The first solution that worked was nomnomnom, thank you again.

So it is solved! I changed the port number on bitcoin-qt to 9150 and it is working fine!

Would you please accept the .736 btc as reward for the help.


saffabit

[nomnomnom]

Hello,

Hello all,

Thank you for all the inputs...

The first solution that worked was nomnomnom, thank you again.

So it is solved! I changed the port number on bitcoin-qt to 9150 and it is working fine!

Would you please accept the .736 btc as reward for the help.


saffabit

good to see you got it working

I would be happy to accept your reward, you can send tip to: 1EE7Xi67cDXzyxLadQTqicBg6PzDQSnBD1

Greetings

[alexseitcha]

I have core 0.9.1 -
and I made sure it was port 9150 not 9050... I also added 4 more US nodes in the console/ debug (working ones as posted on http://blockchain.info/ip-log per your suggestion...)
my network settings are: 127.0.0.1 with 9150 and socks 5

Now I am reporting 29 hours behind... and no solve in sight.
and NO BLOCK SOURCE AVAILABLE.

clearly THAT was NOT the issue and whatever solved the other persons Problem is NOT the above parameters.
it's something else....  coincidence that it worked for you? or .... something else.


------my original post to this forum was: ----->
I loaded Bitcoin core 64bit (win7) several days ago... it had to completely start from scratch and build the Blockchain data base.
(which is over 23 gigs)
I was specifically installing it to overlay with Masterchest Safecoin wallet
which requires txindex=1 argument
and RPC access.

Well anyway- the Bitcoin core completely loaded it took about three days to completely load over 400 weeks of transactions
Which it did so just fine. and once it was finished (a couple days ago)  I had the go ahead to overlay with masterchest.

BUT when the txindex argument is applied through a bitcoin.config file in root directory
the Bitcoin core MUST rebuild the entire transaction chain.
(I was already -sigh- prepared for this to happen...)

Well it started rebuilding a couple days ago and went through hundreds of weeks no problem....
right up until the last 27 hours...
rebooting has done nothing...
uninstalling and re-installing has done nothing...
installing WITHOUT the command argument has done nothing...
In fact I thought it was just ME... something was wrong with my connection.
WHen I searched online and found this thread with the EXACT IDENTICAL NUMBER OF HOURS BEHIND with NO BLOCK ACCESS...
I KNEW it wasn't ME and it is NOT MY CONFIG FILE.<--------