Bitcoin Forum

Bitcoin version 0.7.0 release candidate 3 is now available for download at:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.0/test/

Unless another critical bug is found, this should be the final 0.7.0 release.

How to Upgrade
--------------

If you are running an older version, shut it down. Wait
until it has completely shut down (which might take a few minutes for older
versions), then run the installer (on Windows) or just copy over
/Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

If you were running on Linux with a version that might have been compiled
with a different version of Berkeley DB (for example, if you were using an
Ubuntu PPA version), then run the old version again with the -detachdb
argument and shut it down; if you do not, then the new version will not
be able to read the database files and will exit with an error.

Incompatible Changes
--------------------
* Replaced the 'getmemorypool' RPC command with 'getblocktemplate/submitblock'
  and 'getrawmempool' commands.
* Remove deprecated RPC 'getblocknumber'

Bitcoin Improvement Proposals implemented
-----------------------------------------
BIP 22 - 'getblocktemplate', 'submitblock' RPCs
BIP 34 - block version 2, height in coinbase
BIP 35 - 'mempool' message, extended 'getdata' message behavior


Core bitcoin handling and blockchain database
---------------------------------------------
* Reduced CPU usage, by eliminating some redundant hash calculations
* Cache signature verifications, to eliminate redundant signature checks
* Transactions with zero-value outputs are considered non-standard
* Mining: when creating new blocks, sort 'paid' area by fee-per-kb
* Database: better validation of on-disk stored data
* Database: minor optimizations and reliability improvements
* -loadblock=FILE will import an external block file
* Additional DoS (denial-of-service) prevention measures
* New blockchain checkpoint at block 193,000


JSON-RPC API
------------
* Internal HTTP server is now thread-per-connection, rather than
  a single-threaded queue that would stall on network I/O.
* Internal HTTP server supports HTTP/1.1, pipelined requests and
  connection keep-alive.
* Support JSON-RPC 2.0 batches, to encapsulate multiple JSON-RPC requests
  within a single HTTP request.
* IPv6 support
* Added raw transaction API.  See https://gist.github.com/2839617
* Added 'getrawmempool', to list contents of TX memory pool
* Added 'getpeerinfo', to list data about each connected network peer
* Added 'listaddressgroupings' for better coin control
* Rework gettransaction, getblock calls. 'gettransaction' responds for
  non-wallet TXs now.
* Remove deprecated RPC 'getblocknumber'
* Remove superceded RPC 'getmemorypool' (see BIP 22, above)
* listtransactions output now displays "smart" times for transactions,
  and 'blocktime' and 'timereceived' fields were added


P2P networking
--------------
* IPv6 support
* Tor hidden service support (see doc/Tor.txt)
* Attempts to fix "stuck blockchain download" problems
* Replace BDB database "addr.dat" with internally-managed "peers.dat"
  file containing peer address data.
* Lower default send buffer from 10MB to 1MB
* proxy: SOCKS5 by default
* Support connecting by hostnames passed to proxy
* Add -seednode connections, and use this instead of DNS seeds when proxied
* Added -externalip and -discover
* Add -onlynet to connect only to a given network (IPv4, IPv6, or Tor)
* Separate listening sockets, -bind=<addr>


Qt GUI
------
* Add UI RPC console / debug window
* Re-Enable URI handling on Windows, add safety checks and tray-notifications
* Harmonize the use of ellipsis ("...") to be used in menus, but not on buttons
* Add 2 labels to the overviewpage that display Wallet and Transaction status (obsolete or current)
* Extend the optionsdialog (e.g. language selection) and re-work it to a tabbed UI
* Merge sign/verify message into a single window with tabbed UI
* Ensure a changed bitcoin unit immediately updates all GUI elements that use units
* Update QR Code dialog
* Improve error reporting at startup
* Fine-grained UI updates for a much smoother UI during block downloads
* Remove autocorrection of 0/i in addresses in UI
* Reorganize tray icon menu into more logical order
* Persistently poll for balance change when number of blocks changed
* Much better translations
* Override progress bar design on platforms with segmented progress bars to assist with readability
* Added 'immature balance' display on the overview page
* (Windows only): enable ASLR and DEP for bitcoin-qt.exe
* (Windows only): add meta-data to bitcoin-qt.exe (e.g. description)

Internal codebase
-----------------
* Additional unit tests
* Compile warning fixes


Miscellaneous
-------------
* Reopen debug.log upon SIGHUP
* Bash programmable completion for bitcoind(1)
* On supported OS's, each thread is given a useful name

Very nice Gavin! What are the changes between rc1 and rc2?

Lots of minor bug fixes.

Git users may view the shortlog with

Is it possible to update the translations?

0.7rc1 was running perfectly fine on Windows 7 for the past couple weeks.  Just installed rc2 and it freezes on the splash screen where it says loading block index.

Eventually I get a windows popup asking to kill the process.

Something not right there.

Edit: Eventually it does open. But it never used to say "Program is not responding" during the startup phase before.

That should be done for the final version once more, yes!

Dia

Anybody else having success or failure running rc2 on Windows 7, please let us know...

rc2 is starts fine and downloads the blockchain on Windows 8 aside from the issues with Qt which I mentioned previously. Is there a test plan which should be executed to help testing? Nice work everyone!

I just checked v0.6.3 it appears to behave in the same manor.

If you click on the splash screen while it says "loading block index", the splash screen goes a shade of white and you get the popup saying "application is not responding".

Eventually the application loads.

This is nothing new. The initialisation happens in the UI thread, which thus is unable to respond to window system messages for some time between phases, and thus the window system may think it's helpful by showing that message (and/or greying the UI). Changing this is on the (long) TODO list.

Hey, I'm getting this error twice while starting bitcoind (0.7.0rc2 beta) on Windows XP. It then exits.


(0.6.3 on the other hand, is running fine on this system)


EDIT:

 1. Just to confirm that I made sure that 0.6.3 was NOT running at the same time

 2. Tried to reboot, doesn't help

 3. I'm actually getting another socket-related error first. Log follows.

 4. Tried disabling the firewall, doesn't help

Running like a champ on OS X Lion, though it appears to have a slightly larger footprint than 0.7.0 rc1 did.

I have this problem on one of my ubuntu machines.  To get it to work, it requires editing out some mention of ipv6 in the the bitcoinrpc.cpp file.  

though I believe for me (on ubuntu) I've had to do this on every release from 0.6.3 on up  

see:


not sure if those lines still match up in 0.7.0 or not, but i know what to edit out by now.

using onlynet and/or disabling ipv6 during compile results in the same error.

@zvs What Operating system causes this? Have you enabled IPv6 in the Windows network settings? Sorry, I saw you are Using Ubuntu and I'm of no big help there ^^.

@Gavin Andresen It would have been very cool, if Lukes translation stuff and my Windows version info patch would be in 0.7 final, but I guess it's too late for that now?

Dia

I specifically disabled ipv6 on that machine.... it's not worth the resources on one of the kimsufi atom's (esp. when you get unlucky and get a 1.4 atom)

though, it seems a bit odd that some ipv6 functions cause it to not work, when you disable it

I'll try and see what happens, when I tell my NIC to not bind to IPv6 on Win7 and will report back later today.
Of course a disabled IPv6 OS part should not cause IPv6 problems with the client!

Dia

Will the old addr.dat always hang around now that peers.dat has replaced it? I notice peers.dat is much smaller, is this because it is a more efficient internally managed method? Nice work again everyone, if there is any type of formal test plan I am happy to help run it.

PS. I also notice the .lock file is never deleted. Is this normal? Mine was from last year so after closing the client I deleted it and restarted it but it was created again. Normally a lock file exists only when the DB is open, right? I do detach my databases on shutdown.

The old addr.dat is never deleted.  You may wish to swap back to an older version in an emergency.

New users will never see addr.dat, once 0.7 is released.

I was not able to produce IPv6 related error messages by just disabling OS IPv6 binding. Can the ones who have problems with that give more details about used OS and their used command-line switches please.

Dia

well, the documentation seems to suggest that you must enable ipv6 by including USE_IPV6=1, but the build file has USE_IPV6:=1 as default.   i tried changing that to USE_IPV6=- and USE_IPV6=0, still results in same error

that being:

09/09/12 23:28:43 ThreadMessageHandler started
09/09/12 23:28:43 ThreadOpenConnections started
09/09/12 23:28:43 trying connection xxxx lastseen=0.0hrs
09/09/12 23:28:43 ThreadOpenAddedConnections started
09/09/12 23:28:43 ThreadOpenAddedConnections exited
09/09/12 23:28:43 ThreadSocketHandler started
09/09/12 23:28:43 ThreadIRCSeed exited
09/09/12 23:28:43 Error: An error occurred while setting up the RPC port 8332 for listening: Address family not supported by protocol
09/09/12 23:28:43 ThreadRPCServer exited
09/09/12 23:28:43 Flush(false)
09/09/12 23:28:43 blkindex.dat refcount=0
09/09/12 23:28:43 blkindex.dat checkpoint
09/09/12 23:28:43 connected xxxx
09/09/12 23:28:43 send version message: version 60002, blocks=183152, us=0.0.0.0:0, them=xxxx:8333, peer=xxxx:8333
09/09/12 23:28:43 ThreadSocketHandler exited
09/09/12 23:28:43 ThreadMessageHandler exited

to make it work, one must comment out or remove the following in bitcoinrpc.cpp:

        acceptor->open(endpoint.protocol());
        acceptor->set_option(boost::asio::ip::tcp::acceptor::reuse_address(true));

        // Try making the socket dual IPv6/IPv4 (if listening on the "any" address)
        boost::system::error_code v6_only_error;
        acceptor->set_option(boost::asio::ip::v6_only(loopback), v6_only_error);

        acceptor->bind(endpoint);
        acceptor->listen(socket_base::max_connections);

        RPCListen(acceptor, context, fUseSSL);
        // Cancel outstanding listen-requests for this acceptor when shutting down
        StopRequests.connect(signals2::slot<void ()>(
                    static_cast<void (ip::tcp::acceptor::*)()>(&ip::tcp::acceptor::close), acceptor.get())
                .track(acceptor));

        // If dual IPv6/IPv4 failed (or we're opening loopback interfaces only), open IPv4 separately
        if (loopback || v6_only_error)
     

then it does:

09/10/12 00:00:22 ThreadMessageHandler started
09/10/12 00:00:22 ThreadOpenConnections started
09/10/12 00:00:22 trying connection xxxx lastseen=0.0hrs
09/10/12 00:00:22 ThreadOpenAddedConnections started
09/10/12 00:00:22 ThreadOpenAddedConnections exited
09/10/12 00:00:22 ThreadSocketHandler started
09/10/12 00:00:22 ThreadIRCSeed exited
09/10/12 00:00:22 connected xxxx
09/10/12 00:00:22 send version message: version 60002, blocks=183152, us=0.0.0.0:0, them=xxxx:8333, peer=xxxx:8333
09/10/12 00:00:22 Added time data, samples 2, offset -1 (+0 minutes)
09/10/12 00:00:22 Flushed 0 addresses to peers.dat  57ms
09/10/12 00:00:22 receive version message: version 60002, blocks=198073, us=xxxx:44586, them=xxxx:8333, peer=xxxx:8333
09/10/12 00:00:23 received block 0000000000000045a7f8 from xxxx:8333
09/10/12 00:00:23 SetBestChain: new best=0000000000000045a7f8  height=183153  work=345239274296880467532  date=06/05/12 18:48:15
09/10/12 00:00:23 ProcessBlock: ACCEPTED

and so on

Try commenting out the entire line

If I click a link in windows to trigger the URI handling, but already have the client running, it whines about not getting the lock on the data directory.  This would seem to be that its trying to launch a second instance vs reusing the already running instance.  

Consistently getting a "TX rejected (code -22)" message when trying using sendrawtransaction. I believe I'm following all the steps properly. (createrawtransaction, signrawtransaction, sendrawtransaction)

Using the rpc console in Win7x64.

Same result using bitcoind.

I tried this with RC2 on my Win7 x64 machine and it works like a charm. I have one instance running and sitting in the tray. Clicking a bitcoin URI leads to opening the client and no warning, as expected. Are you really sure you are using 0.7RC2, can you verify please?

Dia

debug.log might tell you why it is being rejected. Some reasons it might be rejected:

+ You're re-using an input that has already been spent.
+ Sum(outputs) is greater than Sum(inputs)
+ signrawtransaction was unable to sign all of the inputs (it did not report "complete" : true )

By the way: be EXTREMELY careful with the raw transactions API. You can easily forget to include a change output and create transactions with huge fees; test your code thoroughly on testnet before putting it into production.

I'm on RC1, I'll check RC2 as soon as I can get back to that machine.

Do you use portable Zip or installation? Only the installation will update the file associations for bitcoin URIs, which could also cause errors.

Dia

Install.  I'm installing RC2 as we speak and will give it a go.

Consensus is the RPC-doesn't-work-if-you-disable-IpV6 bug is serious enough to hold up the 0.7.0 final release.

So the plan will be: get a fix for that bug and release/test a 0.7.0rc3.

This is a great progress that you guys did in the 0.7 version.
You don't see a progress at the first sight, but the extra RPC commands and the built-in console - for me, just paradise. And it will be so easy to explain to my mom how to use it, so she doesn't have to keep her wallet on the same pc where my father watches porn, pressing yes at every button... ;)
The idea witn some bitcoind.exe, that she had to run from a command prompt... she did not like it.
But a built in RPC console - just genius! :)
And I must say switching to Qt really seems to have been a good idea, after all.

Thanks.

It seems to me that the RPC server currently entirely ignores the fact that <nets> can be limited via e.g. -onlynet="IPv4" which should never use IPv6 for anything then, right?

Dia

Thanks for the Qt commendation, wumpus and I'm very happy to hear such things as we put some efforts into making the Qt GUI better / cleaner / more polished :). I really love his RPC console, too and I'm glad I could help him improving that beast a little ^^.

Dia

ERROR: CTxMemPool::accept() : not enough fees

I'm assuming this is the error that I'm getting. Is this expected behavior? How does one include fees in a raw transaction?

The fee is Sum(inputs) - Sum(outputs). Drop some coins on the floor and a miner will pick 'em up. :)

Sorry if this is a little OT, but if I just pull from master am I getting your RC?  If so, its working great for me :-)

Still getting that message with RC2.  Win 7 x64 Chrome Browser default.

Can you try to set IE as default browser for a quick test please?

Dia

Translation not updated.

Regarding the IPv6 RPC issue, can you guys test whether pull request #1822 (https://github.com/bitcoin/bitcoin/pull/1822) fixes the problem?

I can create a build of that, if necessary.

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

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

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.

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 

rc2 running on Windows7 perfectly.Will try rc3.

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

RC3 working fine on Windows 8.

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

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?

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?

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

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.

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

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

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.

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 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

Just installed the final. Nice work everyone!  8)

Smooth upgrade on a mac thanks guys.