Topic: Version 0.7.0 release candidate 3 ready for testing (Read 9745 times)

Smooth upgrade on a mac thanks guys.

Just installed the final. Nice work everyone! 

i don't understand this, why would you disconnect your internet connection?  why not just restart the bitcoin client?

the blockchain will download faster if you connect to a single peer using maxconnections=1, as long as you connect to the right peer (with connect=), you dont have to set maxconnections=1 if you dont allow incoming connections.

but if it's just some random peer, then, yes, i would say there's a 95% chance that you will be screwed

I think the current code in the client is bad at detecting a connection-loss from the node it downloads blocks or at least it takes way too much time before it switches to a more healthy node.

Dia

I suspect you don't need to suspend; just unplug the network cord for the same amount of time.
When I use a single peer, disconnect cable for a few hours and reconnect it, it says I have the 1 peer but no blocks are downloaded until I restart bitcoin-qt. I doubt this is new in 0.7.

Yes.  I didn't mention that, but if I restart the client it starts getting the new blocks almost immediately.

I  used to have this happen on occasion... would just reload the client, get new connections, and it'd be fine.  I suspect blocks are being requested from someone that is throttling their upstream or has none to begin with..

now my windows-qt shortcut just has a few addnodes, it always gets the blocks from those (presumably since they connect before any other nodes)

ed: oh, i believe the default send buffer was also lowered

I built v0.7.0rc3 from git, and have noticed on several occasions that it's very bad at catching up with the blockchain if I suspend the laptop for a few hours then resume it.

I suspended the laptop with the blockchain up to date last night.  Then today when I resumed it, the block download seems stuck at "55 blocks remaining" even though I apparently have "14 active connections to the bitcoin network".

I don't know if those are really "active" connections, or if it fact they are 14 connections which were active at the time of suspension, and which have really died out in the mean time.

I get the impression that v0.6.x was better at handling suspend/resume, but that may not actually be the case.  I'm suspending and resuming more recently than I used to, so perhaps I'm seeing a long-standing issue that's nothing to do with the 0.7.0 changes.

hmmm, I think the HTTP client internal to bitcoin did not get updated to make IPv6 connections.  Worth filing an issue at github.

Normal shortcut with a commandline of "C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe"

I removed the boost_interprocess folder just now.  

I do make use of a %appdata\roaming\bitcoin\bitcoin.conf file but it just specifies a few nodes to connect to, rpc port/pass, and the start min/min to tray.

This is the handler registry entry.  I had removed it and this is the result of the RC3 installation.


I've got my wallet.dat sitting in a truecrypt volume that is symlinked into my data directory.  You think perhaps that is what is causing it?

I compiled and started bitcoind on a dual stack machine.

Config:

My config is:

When I query the daemon, I expected it to use an IPv6 connection however the system shows that an IPv4 connection is used to query the daemon. Using "bitcoind -onlynet=IPv6 getpeerinfo" makes no difference, the communication is still using IPv4. How can I use the client to query the daemon using IPv6?

What are your command-line switches for starting your normal Bitcoin instance? What is the behaviour, when you do not start a client and then click a Bitcoin URI?
I guess you should uninstall and then try to edit the Registry and manually remove the bitcoin URI association, to be sure you have a clean registry before installing.
Also take a look into C:\ProgramData\ and remove the boost_interprocess folder and all it's contents (when no client is running).

Are you using bitcoind together with bitcoin-qt?

Dia

RC3 working fine on Windows 8.

RC2 with IE default still gives the message about the data directory lock.  Upgrading to RC3 to try thta.

rc2 running on Windows7 perfectly.Will try rc3.

Release candidate 3 binaries are up; major differences from rc2 are:

1) Fix the IPv6 RPC problem (you will get a warning in debug.log, that is expected)
2) Updated translations

------

We could use more people "gitian building" releases; if you have a machine with at least 3 gig of memory and 20 gig of disk space, you can now help reproduce the builds using LXC running inside something like VirtualBox:
  https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/README#L57 

Hello,


My system has # CONFIG_IPV6 is not set. So I was seeing this problem too.
I patched 0.7.0-rc2 with that. It seems to work, but I get the same error message (warning?) like zvs.
At least bitcoind keeps running and it is listening on port 8332 and 8333.

executed a Gangnam Style compile using the latest github pull and https://github.com/sipa/bitcoin/commit/c1d79812f428860e6f624835851d6f3ecd86bbb3

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 22
model name      : Intel(R) Celeron(R) CPU          220  @ 1.20GHz
stepping        : 1
microcode       : 0x36
cpu MHz         : 1199.859
cache size      : 512 KB

fast, like ninja


09/12/12 16:33:17 Bitcoin version v0.7.0rc2-29-gd078739-dirty-beta (2012-09-12 10:20:46 -0400)
09/12/12 16:33:17 Using OpenSSL version OpenSSL 1.0.0e 6 Sep 2011
09/12/12 16:33:17 Default data directory /home/zevus/.bitcoin
09/12/12 16:33:17 Used data directory /home/zevus/.bitcoin
09/12/12 16:33:17 Error: Couldn't open socket for incoming connections (socket returned error 97)                            (<------- jaja)
09/12/12 16:33:17 Bound to 0.0.0.0:8333
09/12/12 16:33:17 Loading block index...
09/12/12 16:33:17 dbenv.open LogDir=/home/zevus/.bitcoin/database ErrorFile=/home/zevus/.bitcoin/db.log
09/12/12 16:33:36 LoadBlockIndex(): hashBestChain=0000000000000581f901  height=198463  date=09/12/12 15:56:02
09/12/12 16:33:36 Verifying last 2500 blocks at level 1
09/12/12 16:34:05  block index           47752ms
09/12/12 16:34:05 Loading wallet...
09/12/12 16:34:05 nFileVersion = 70002
09/12/12 16:34:05  wallet                   66ms
09/12/12 16:34:05 Loading addresses...
09/12/12 16:34:05 Loaded 12605 addresses from peers.dat  132ms
09/12/12 16:34:05 mapBlockIndex.size() = 198468
09/12/12 16:34:05 nBestHeight = 198463
09/12/12 16:34:05 setKeyPool.size() = 1
09/12/12 16:34:05 mapWallet.size() = 0
09/12/12 16:34:05 mapAddressBook.size() = 1
09/12/12 16:34:05 Done loading
09/12/12 16:34:05 ThreadRPCServer started
09/12/12 16:34:05 send version message: version 60002, blocks=198463, us=0.0.0.0:0, them=0.0.0.0:0, peer=127.0.0.1:0
09/12/12 16:34:05 AddLocal(ww.xx.yy.zz:8333,1)
09/12/12 16:34:05 IPv4 eth0: ww.xx.yy.zz
09/12/12 16:34:05 ThreadMessageHandler started
09/12/12 16:34:05 ThreadOpenConnections started
09/12/12 16:34:05 ThreadOpenAddedConnections started
09/12/12 16:34:05 trying connection 1.3.3.7:8333 lastseen=346518.8hrs
09/12/12 16:34:05 ThreadSocketHandler started
09/12/12 16:34:05 accepted connection z.y.x.w:55240
09/12/12 16:34:05 ThreadIRCSeed exited
09/12/12 16:34:05 ThreadDNSAddressSeed started
09/12/12 16:34:05 Loading addresses from DNS seeds (could take a while)
09/12/12 16:34:05 connected 1.3.3.7:8333
09/12/12 16:34:05 send version message: version 60002, blocks=198463, us=ww.xx.yy.zz:8333, them=1.3.3.7:8333, peer=1.3.3.7:8333
09/12/12 16:34:05 GetMyExternalIP() received [ww.xx.yy.zz] ww.xx.yy.zz:0
09/12/12 16:34:05 GetMyExternalIP() returned ww.xx.yy.zz
09/12/12 16:34:05 AddLocal(ww.xx.yy.zz:8333,5)
09/12/12 16:34:05 send version message: version 60002, blocks=198463, us=ww.xx.yy.zz:8333, them=z.y.x.w:55240, peer=z.y.x.w:55240
09/12/12 16:34:05 Added time data, samples 2, offset -30 (+0 minutes)
09/12/12 16:34:05 Flushed 12605 addresses to peers.dat  140ms
09/12/12 16:34:05 receive version message: version 50300, blocks=197392, us=ww.xx.yy.zz:8333, them=z.y.x.w:8333, peer=z.y.x.w:55240
09/12/12 16:34:05 accepted alert 1016, AppliesToMe()=0



worked!   though it looked a bit odd

i'll test it, it'll be a bit though since this kimsufi is godawful slow

Regarding the IPv6 RPC issue, can you guys test whether pull request #1822 fixes the problem?

I can create a build of that, if necessary.