Bitcoin Forum

Bitcoin version 0.7.0 is now available for download at:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.0/ (http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.0/)

We recommend that everybody running prior versions of bitcoind/Bitcoin-Qt
upgrade to this release, except for users running Mac OSX 10.5.

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues (https://github.com/bitcoin/bitcoin/issues)

Project source code is hosted at github; you can get
source-only tarballs/zipballs directly from there:
  https://github.com/bitcoin/bitcoin/tarball/v0.7.0 (https://github.com/bitcoin/bitcoin/tarball/v0.7.0)  # .tar.gz
  https://github.com/bitcoin/bitcoin/zipball/v0.7.0 (https://github.com/bitcoin/bitcoin/zipball/v0.7.0)  # .zip

Ubuntu Linux users can use the "Personal Package Archive" (PPA)
maintained by Matt Corallo to automatically keep
bitcoin up-to-date.  Just type
  sudo apt-add-repository ppa:bitcoin/bitcoin
  sudo apt-get update
in your terminal, then install the bitcoin-qt package:
  sudo apt-get install bitcoin-qt


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
(on Mac) or (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 the
PPA and are switching to the binary release), 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 getblock call.
* 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

---

Thanks to everybody who contributed to this release:

Chris Moore
Christian von Roques
David Joel Schwartz
Douglas Huff
Fordy
Gavin Andresen
Giel van Schijndel
Gregory Maxwell
Jeff Garzik
Luke Dashjr
Matt Corallo
Michael Ford
Michael Hendricks
Peter Todd
Philip Kaufmann
Pieter Wuille
R E Broadley
Ricardo M. Correia
Rune K. Svendsen
Scott Ellis
Stephane Glondu
Wladimir J. van der Laan
cardpuncher
coderrr
fanquake
grimd34th
sje397
xanatos

Thanks to Sergio Lerner for reporting denial-of-service vulnerabilities fixed in this release.

Awesomeness.

Excellent! Thanks for your hard works!

+1!

Gavin, I was just wondering, would you mind explaining what this is:

Nvm, found an explanation here: http://bitcoin.stackexchange.com/questions/1061/can-a-51-attack-be-detected-and-dealt-with/1065#1065

Excellent. I guess the Ubuntu PPA takes some time to be ready as it doesn't seem to be showing an update available yet.

Mac version is running like a champ. Quicker load time, it seems.

You all are the bomb. Gracias.

Great work! ;D

I have a man-crush on all the developers. THANK YOU GUYS FOR YOUR AMAZING WORK.

The update is there. I updated mine 1 hour ago.

Threaded RPC server, excellent. Less memory usage is never a bad thing either.

Thank you developers!

Weird. I see it listed on the launchpad website but in Update Manager and Synaptics it only shows 0.6.3-natty2 even after reloading. Well, I guess it will show up some time.

edit: fixed err in version.

Great Improvements on the RPC-API! Thanks so much!! :)

Thanks devs!

Is this the September announcement?

No.

Thank you guys!!

Upgrade went perfectly on Win7 32bit.

The Debug window is fantastic and "out of sync" messages really help.

Excellent work as usual. 

<PissAntComplaint>
As a colour blind DBA (i.e UI retarded), I dislike the startup logo.
I'd rather see the "traditional" Bitcoin icon on a light coloured (perhaps a gradient) background.
</PissAntComplaint>

Yeah, logo is how big? in kilobytes? (but QT is also big, hehehe.) I prefer no pictures though and just a purely functional program, but splash screens have been pretty much standard in many apps, so thanks.

Thank you!

This time I can confirm that gitian gives me exactly the same bitcoin-qt.exe as you serve. (unlike it once was with 0.6.2)

Good work Gavin + team, much appreciated.

Thank you , devs.

Is there really STILL no coin control options in this release? This is the major feature I have been waiting for for many many months and I am so disappointed that it seems to be not here ?

Thanks to Gavin and all Bitcoin devs current and past.

Our games at SatoshiRoulette (http://) simply would not be possible were it not for bitcoind and the ongoing work from yourselves.

Thanks to all the developers, great work!

Is there an option to send some coins as a donation?

There is actually complete coin control now (note that the patch that had been created earlier whilst having GUI support only provided limited control), however,  you will need to use the console version (bitcoind) to create the tx's via the "raw transactions" RPC calls: https://en.bitcoin.it/wiki/Raw_Transactions

Great work guys (am reading about raw tx's now in order to start playing with them)!

Thanks!

Wow... i can browse the web while DLing BlockChain on my old trusty P4!

Thanks!

yay! updates! thanks guys.

Bad news, this new version hogging cpu, making my server unresponsive:


Its Debian Squeeze 64 bit.

Hi,

I want to upgrade to 0.7. I'm using macos. Do I just download and install?

Should I backup my wallet again just for safely?

There is no chance of my existing wallet getting over-written or anything is there?

T

nice improvements  :)
runs smothly so far, great job devs! 

Good work guys, thank you  :)

Ubuntu PPA is not updated.

Yes, it is. Do a...

Is there any chance of this being able to support blockchains made using a different version of libdb?

Also, the PPA is most certainly updated.

The block files (blk000N.dat) are not BDB files, they're a raw, binary, append-only list of serialized blocks, so -loadblock doesn't care about the version of libdb used.

Thanks.

Gavin, you might want to add that Ubuntu users should also type
 sudo apt-get update
between the repository addition and apt-get install steps.

Upgraded with PPA on Ubuntu 12.04 32bit.  No problems, tray icon fixed and now showing :)


+1 this step should be included

Thank you for your hard work!

I hope that history will remember your contributions :)

Great job once again!
Congratulations.

nice work team. where to send my bitcoins to fund your work?

Just during startup, or always?

Always. 30 minutes after startup was same thing.

And earlier versions didn't have this problem?

Nop.

This is version 0.6.3, 1% load:

Lots of new features and all.  That's great.  Thanks guys.

... BUT ...


The important september announcement is not that there is a troyan horse in the binary, allowing a secret retrieval of all private keys in order to reboot the block chain, is it?

I mean, everybody's so quick into jumping in every new version.  Am I the only one worrying a bit about that?

Only if you did not read the source.

Personally, I run a simple file compare against the last build and look at the changes.

It ain't called Open Source for nothing.

Thanks, its running smoothly.

0.7 quits unexpectedly immediately after launch on my OSX 10.5.8.

Is anyone else having this issue?

  Only using ~300MB of RAM for me.  Seems slightly reduced so that's nice, even if not a big deal.  The "Out of Sync" notifications are nice to see.

  The options appears to be cleaned up a lot.

  Thank you for the continued hard work!

the new client is running very smooth.

_Amazing_ work.

* Add UI RPC console / debug window

Where is this? I can't seem to find it

It's under 'Help' menu.

gavin any chance of seeing big endian/little endian compatibility someday?

It shouldn't over write your existing wallet.dat, but why wouldn't you back it up just in case?

It is pretty easy to do, and if for some reason something unexpected should go wrong for you, saying "I thought you said it would be ok" won't bring back your coins.

Anybody got a plain English explanation?

I'd like to request people using bitcoind to NOT upgrade and force the devs to deal with changes properly.

These 2 changes above are ridiculous.
Can we expect the next version of bitcoin to remove other things that people are using and simply say - bad luck - see you later?
Have any of the bitcoin devs ever worked in a real production environment?
This sort of change suggests the answer to that question is 'no'.

We already had a nightmare of problems back in April due to not dealing with change properly, why are we still seeing this lack of proper procedure here with this 0.7.0 release?

From everything I've seen the bitcoin client has always appeared to me to be in Beta.

Are you insinuating we shouldn't use beta software to do real work?  :o


;)

So - since the software is in beta the changes done shouldn't be treated appropriately? ...

And ... yes your quote is trying to create a link between 2 things I said that were not linked at all ...

The Mac version crashes on launch on my Leopard box, so I guess I'll wait for 0.7.1 and see what happens.

Yes, that's what I'm seeing.

Nah, just that I don't expect beta software to be maintained with the same attention to backward compatibility as I would expect of work done in a production environment.  If I'm going to use beta software in my own production environment, then I'm going to expect to have to do some work on my end to keep up with the newest releases.

I used ellipsis to show that content had been removed from the original and left the link there so that anybody who wants to can see the context. Not trying to hide anything.

How were they not linked?  You asked if the bitcoin devs had ever worked in a production environment and then complained about the way they were handling 0.7.0 which is a beta release.

Feel free to create competing software.  It is open source after all, and the protocol is public knowledge.  If you can provide a better product and do a better job of treating changes properly, then yours will likely become the new standard.

For the main client it is low priority.

But in a blatant plug... https://github.com/jgarzik/pynode does support big + little endian out of the box.

Clearly it isn't, I'll agree with you on that :)

Correct.

And beyond that, the RPC API has never had the same ironclad backwards-compat guarantees that the blockchain and P2P network have.  From satoshi's time to present, RPC calls have been considered an internal control plane.  Compatibility with existing use cases is very important, even with RPC API, but sometimes there are exceptions:  deprecated, unused APIs; APIs where we've discussed and planned for changes ahead of time, etc.

hmmm, it sounds like there may be an OSX-specific problem.

What is the previous known working version?

Was that an official OSX build from Gavin, your own build, or a third party build?

Thanks.

Could be, hopefully Gavin will find something useful in my debug.log file.  ;)


0.6.3, which is running right now.


It was the official release.

This is a major version update, so things like this can be expected. Even if they had left those features in, the upgrade still might not be seamless for business users. If you don't want to update immediately to the new version, old versions still receive bugfix-only updates for about 1 year or so.

0.6.4 is currently being tested here:
https://bitcointalk.org/index.php?topic=110231.0

First, thank you!

Second, if it's not too much trouble:  two datetime columns on address Book would be great:  created, last txn

A sincere "Thank you!" to all the developers.

0.6.3 also works fine here.

0.7 was the official build from bitcoin.org.

That last question was asking who built the previous, working version?  Who built 0.6.3?  Gavin, you, or other?

We updated today from 6020 to 70003 all went smooth, thank you very much!

One thing we can't figure out. Why bitcoind API can't return the senders address from a transaction?

We are still using third parties for this operation which is far from optimal. I believe that lot of others have the same needs as I read in other posts.

Ah. 0.6.3 was the build from bitcoin.org too.

Tremendous.

Bitcoin transactions do not have a sender address. They have one or more input txouts, each of which may or may not have an identifiable address it was previously sent to. Relying on this information is not portable, as it is client-dependent. If you need a refund address or some payout address, ask for it. This also prevents reuse of addresses, which is bad for Bitcoin's privacy model (not just of those whose addresses are involved).

PS: since 0.7, you can find this information using the raw transaction API.

i have problems with p2pool !

P2pool 3.1 is not compatible with bitcoind 0.7,
and since getmemorypool is removed, it thinks its version is too old.
You can upgrade p2pool to 5.0 now.

Both of my copies, 0.6.3 and 0.7.0, were official releases too.

really?

1) Are you sure that there are transactions without an identifiable sender addresses? I've never seen a single transaction like that in the blockchain.

2) "coin taint" all the way back to the original generated coin(s) in question  has always been fully traceable whenever I've attempted.

3) Coin control is a desired / requested / needed feature. The ability to control which source coins are spent in transactions and whatnot.

4) there is no four. except maybe "please qualify your assertion as I've addressed in #1"

What you have is the last address that received those coins.  This is not the same thing as a sender address.

Things get even more silly if you think about transactions with multiple inputs and/or outputs.

@kjj

huh? why not?

Are you saying you can spend someone else's coins despite not having access to the private key for their address(es)?

Edited to add:

multi-input transactions require private keys just the same as single-input. I'm not sure what you're referring to.

A rather direct, simlpified implication is that if coins are sent, the private key(s) used to generate the transaction script(s) is controlled by the sender.

Yes, that is exactly what I am saying.  Post an address, and I will cause a 3rd party to send a transaction to it in such a way that it can not be returned to me.

Thanks for new version.
:)

Please find or hire someone to update and fix the problems in it, so that it might be merged in the future. Maybe start a bounty?
Today's next-test (https://bitcointalk.org/?topic=110898) still has Coin Control barely merged in, but this will probably be the last time due to rapid bitrot.

+1

I would love to see this feature working.

I might start the bounty myself in the morning (or some other time) if it hasn't been started yet... After when I've slept and/or look back in this direction (bitcointalk forums) again.

Thanks for the official-like status update on the future of this feature, luke.

Are you describing a scenario where your bitcoin wallet (private keys) is controlled by a third party?

Or perhaps (for example)

One could "withdraw" from their GLBSE balance to someone else's bitcoin address (to make a patment from them)

perhaps mtgox and/or other "in the cloud" wallet providers... I can only speculate. Only ever used official satoshi (bitcoinqt / bitcoind) wallet.

I'm aiming to completely get rid of the splash screen by 0.8. No promises though.

Yes.  I have at least three accounts with services that will send coins at my command, but will not come from a key that I control, or is otherwise associated with me in any way.  A return to sender on those payments will go either to the service provider, or to a random user of that service.

And that's just off the top of my head.  I bet that if I looked through my password safe, I'd see plenty more accounts that I've totally forgotten.

And that's not all.  Say you are making a major sale, and you want the proceeds to go into a P2SH multisig account where most of the keys are offline, or under the control of an authentication service.  You get the payment and check the list, see that the coins are "tainted".  Now what?  You don't have the keys available to return them immediately.  Oops.

updated to 0.7.0-beta
Thanks!

Update, 22 Sept:  Still looking for a fix for OSX 10.5 users. If you are running 10.5, you should not upgrade yet.

A minor issue, not sure if yet reported. 0.7.0 client does not allow to transfer the whole balance, stating an incorrect initial fee (prior to ‘send’ confirmation). My example: balance 0.1739839, client does not allow to spend more then 0.1719839 (initially assumes 0.002 minimum fee), the minimum fee is in fact 0.0015 (correctly calculated after 'send' data check on 0.1719839 and overrides an earlier 'assumed' 0.002), so 0.0005 remains unspent even if you force it as a nominal fee in the settings. Initial fee miscalculation? 6.3 does not have such problem. Please check. TIA.

pm me for details if needed.

I am having a issue deleting old addresses from the address book using version 0.7.0 on Ubuntu 12.04.  Does anyone else have this issue?

If so, this warning should be included in the top post. (Not everyone will read page five before upgrading.)

I am having trouble copy and pasting addresses into Pay to box when trying to send BTC in that it won't even give me the option to paste despite it being in the clipboard and working for all other applications.  .  Reverting to 0.63 works again for me.

I'm on windows 7 x64.

I've experienced that exact issue before in 0.6.3 but just never thought to report it.

1) Often would get a message "insufficient... something something something ...after fee included" (can't remember exact wording)

2) So then  after I subtract the fee manually, it takes out a different fee amount or sometimes reports a different fee is required.

-- I haven't sent coins since upgrading to 0.7.0 but if I am able to reproduce this behavior at a later date I will fully document the messages

Thanks to you Gavin and to the whole team.

it looks like 0.70 is registering the bitcoin: URI protocol (at least in Windows) but if I already have the bitcoin client running, I get an error.

http://i59.photobucket.com/albums/g296/tonygal/2012-09-25_0928.png

Downloading the blockchain in 0.7, seems a lot faster :)

I tried using the Donation link on the bitcoin foundation page, and nothing happened in the bitcoin client. I don't know what the expected behavior is, but I assume it isn't nothing.

Same error on my end, when clicking the provided URI to pay the Bitcoin Foundation of all things. (W7 64bit)

In short: When Bitcoin-Qt was not running, the application would launch normally, and then proceed to do... nothing in particular.

(I'm assuming something is meant to happen at this point. It doesn't.)

So, I kill the application and click the link again. Same result. With mild annoyance, I repeat this a this a few times over.

I try to find some way to manually paste the link. (Because that sounds like something one should be able to do.) No luck there either.

At which point I give up and extract the address from the URI (no plaintext address was provided)

After conceding defeat, I finally manage to paste the address, smack a label on it, add the specified amount and
do the transaction by hand, while trembling and cursing in terrible anger. ;)

If the registration doesn't work, you can also drag&drop a bitcoin: URI to the running client (this was the original mechanism).

Can you guys please tell me, if you did an upgrade install or removed the old version before installing 0.7?
Another interesting thing would be how the Bitcoin URI entry in your registry looks like.

Enter regedit and go to HKEY_CLASSES_ROOT\bitcoin\shell\open\command for that info.

Oh and please verify that you are using latest 0.7 release and no former RC!

Dia

I installed over the RC versions.


The drag and drop method works.

Can you please change into and report back!

Dia

Seam's to take forever for confirmation's now. 32 confirmation's for a Tx done 3 hour's ago. Took a long time just to get 1(about 20 min or so) is this normal for this version?

The timing of each confirmation is dependent on the network, not your client version.

Sometimes blocks are confirmed more slowly, sometimes blocks are confirmed more rapidly.

It is only the targetted average that is 10 minutes per confirmation.  This is a target that the network is always striving for, but -- due to probability -- never attains.

^^ Thank's for the info.

Of course! The symbol switching did the job. Thanks.

However, the text in the comment is "bitcoin+foundation+donation". I don't know if the '+' symbols are supposed to be rendered like that.

That's a problem in the website, not the client. %20 should be used to encode spaces in URIs, not "+":
http://stackoverflow.com/questions/2678551/when-to-encode-space-to-plus-and-when-to-20

Changed the "$1" part of the registry value to "%1". Works fine now.

I believe I upgraded to 0.7 from 0.6.2. Possibly from 0.6.3. (Not from an RC version.)

Would forcing the registry value to "%1" during installation break anything?

Thanks for the help. :)

Huh.

That's a problem with BIP 20-- it doesn't say how the parameters are encoded.  I assumed they were encoded the same way as http URLs (application/x-www-form-encoded) because the bitcoin: scheme is very similar to the http scheme (where everything after the ? is x-www-form-encoded); are they not?

This client opens much slower for me

As asked for in another thread, info even small from users who are using a client.
Running 0.7.0 on Win7 64 no problems, not turning the client on much though due to having mobile connection and saving my download limits. I never wanted to comment in these threads much because my tech knowledge is very limited even though I can piece them together hardware wise.
I will put my its running ok or not up from now on.
Thanks for all the hard work as well dev team.