I was just about to say the same thing; if there were multiple people all over the world downloading and checking the binaries against the PGP signatures that would be a wonderful thing, and would be much more robust against all the various attacks that might happen (DNS poisoning on some subset of the Internet, compromising one mirror, etc etc etc).

Yes, I am an angel sent from God to deliver Justice to a world full of Sin!

But I'm not behind the bitcoincard project. I did meet with them in Vienna, along with other bitcoin folks. See http://blog.bitinstant.com/blog/2012/6/8/bitcoincard-in-vienna-day-1-coffee-missing-atms-and-some-tes.html for info/pictures.

Wanna bet?

Yeah, where did I say that?

Oops, edited, I forgot about my "don't feed the trolls" rule.

+1

And I'd say the same for anybody who has offered shares on GLBSE; I am not a lawyer, but you should talk to a lawyer about whether or not you might have broken some laws you had no idea existed, and if you did, what you should or shouldn't do about it.

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

No, these are Luke's pet branches, which I think are a bad idea because they divert development and testing efforts away from the latest release.

The first real 'stable' release will be 1.0, and we're not there yet.

Yes, go ahead and implement it.  Here's a thumbnail sketch of one way to start:

+ Create a web service that lets anybody upload their email address and a list of public keys.

+ Send the user an email whenever 'tainted' coins are sent to any of those public keys, telling them how tainted they are and where they came from.

That's it.

For extra credit, you could let users upload their wallet.dat files (private keys encrypted, I would hope) and auto-extract all the public keys in the wallet.  Heck, if you stored the private-key-encrypted wallet.dats you might be able to charge a little for both blacklist detection and wallet backup.

I'm sure I could figure it out, but I don't have a copy of osx 10.5 to run, won't pirate it, and don't feel like spending $60 to pick up a copy on Ebay. I'd rather not spend the half a day it would take me to set up a development environment in a VM, too....

You'd need 15 words to represent a bitcoin address; more if you include a checksum (a very good idea, transpose two words without a checksum and you'd get a "black hole" address).

Creating a secure payment protocol so I can tell people "send payment to gavinandresen@clearcoin.com" and be confident that I'll get the coins is very high on my priority list.

We're getting reports that version 0.7.0 isn't working on OSX 10.5-- are there any Mac developers with a 10.5 machine who can help figure out what is wrong?

The OSX builds are done on my OSX 10.6.8 machine, compiled against the 10.5 SDK in 32-bit mode (see http://gavintech.blogspot.com/2011/11/deploying-bitcoin-qt-on-osx.html ) for maximum compatibility. I'm not sure what changed between bitcoin versions 0.6.3 and 0.7.0 that would break compatibility...

RE: listing bitcoind separately on the clients page:  good idea.  casascius, do you know (or are you willing to teach yourself) enough git to submit a pull request to the https://github.com/bitcoin/bitcoin.org  repository?

I think we should remove the direct download links from the bitcoin.org (and wiki) homepage, too, and instead just link to the clients page.

Sure, use multisig and store the keys on two different types of hardware (e.g. cell phone and computer).

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.

Yes, if by earlier you mean a few minutes earlier (it would have to have a 50+ BTC fee to make it worthwhile for miners to double-spend a transaction that already made it into the last block).

Two zero-confirmation transactions essentially happen at the same time as far as the network is concerned; if there was a good way for everybody to agree that they happened in a particular order we wouldn't need the blockchain. I assume that miners will take the transactions that give them the greatest short-term profit; that may not be correct (there might be a lot of miners interested in the long-term health of Bitcoin), but I think it is the safest assumption. And I think if we design payment protocols around that assumption they will be more secure.

Yes, mathematically approximately zilch.

... unless the OpenSSL entropy-gathering code on your computer isn't working properly, so bitcoin's random-key-generating code doesn't work (we use OpenSSL to get good random numbers). That is a bigger worry, but happily lots of people have been reviewing that code for years.

Bitcoin version 0.7.0 is now available for download at:
  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

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  # .tar.gz
  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.

You request a transaction by hash (using an 'inv' message).

You then get the transaction in a 'tx' message.  The hash isn't sent as part of that data, because you can reconstruct it by hashing the transaction data.

If you're running Bitcoin-Qt on a Mac, what version of OSX are you running?

I'm trying to get an idea of how many people are still running 10.5, because supporting that version of OSX is starting to become painful (it is almost 5 years old now...).

And before somebody asks: yes, signing the Bitcoin-Qt app so it plays nicely with 10.8's "Gatekeeper" is near the top of the TODO list.

Right now, there is a hard-coded limit of 1 megabyte per block.

If we assume that limit never changes, that gives:
 1MB per block * 6 blocks per hour * 24*365.25*200 = 10,519,200 MB

... or 10.5 terabytes for the maximum size of the entire blockchain over the next 200 years (somebody check my math, I'm really good at dropping zeroes).

I expect that in 200 years 10 terabytes of storage will cost a few pennies.

---

Now whether or not that 1 megabyte per block limit should go away is hotly debated, and will be debated more and more as transaction volume increases.