I seem to recall (but am too lazy to look up) some interesting research on the gini coefficient for subgroups in the United States; if I recall correctly (and it is very likely I don't), Scandinavian Americans as-a-group have a lower gini coefficient than Scandinavians.

That is either evidence for economic oppression of underprivileged groups in the US, or evidence that culture matters when it comes to economic success, depending on whether you're left-leaning or right-leaning.

A real crash.

In a perfect world, Bitcoin version 0.1 would have included code that looked for a "Bitcoin version X or later required to read this wallet.dat file" setting, and notify the user and exit cleanly if X is greater than the version you're running.

We don't live in a perfect world.

So the second-best solution was to have version 0.4 and later do the "Bitcoin version X or later required to read this wallet.dat file" thing.  And write a value into the wallet that causes previous versions of bitcoin to crash on startup.

If previous versions didn't crash when given an encrypted wallet, they'd just ignore the encrypted keys, generate a bunch of new, unencrypted keys, and give people heart attacks when they ran the old version of bitcoin and told them they had a 0 bitcoin balance.

There is not a donation address for the whole development team; if there was, somebody would have to be in charge of keeping track of the bitcoins, deciding what they should be spent on, etc.

I don't want to be that somebody....

If you like the wallet encryption feature, send bitcoins to:
  Matt Corallo :  1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
and Jeff Garzik : 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj

Matt (aka "BlueMatt" in IRC) did the hard work of making wallet encryption happen, and deserves a ton of credit for being persistent and reworking his Jeff's initial implementation a few times based on feedback and suggestions.

Gregory Maxwell ('gmaxwell') also deserves credit and donations, he gave a lot of feedback and did a lot of testing:
  gmaxwell : 1LjPAUKf23kDBy9sLJbiLfsvjde3ZdHcbJ

(corrected to give Jeff credit for the initial implementation-- sorry Jeff!)

More details are in the doc/README file in the tree:
  https://github.com/bitcoin/bitcoin/blob/master/doc/README#L70

I've been wondering about that-- is it possible to write a password cracker that generates all the lower-entropy passwords first?

That's the kind of theoretical computer science problem that it seems like should have an answer, or have a proof that it is equivalent to the halting problem.

Well, CPUs are easy-to-program general purpose hardware that can do lots of things (and several things at the same time, in these days of multicore CPUs) pretty darn fast.

GPUs are hard-to-program more-specialized hardware. These days they can do pretty much any raw calculation a CPU can do, faster-- it just takes a lot more effort on the programmer's part to figure out how. That extra effort is only worthwhile for the most performance-critical code.

When I worked at Silicon Graphics I saw several interesting algorithms implemented using OpenGL operations reading and writing to texture memory and/or the accumulation buffer and/or the framebuffer. That was before OpenCL and GPU programming languages, but the experience gave me a lot of respect for the ability of good programmers to look at problems sideways and come up with ... interesting ... solutions.

The 'open' command is the best way to run Bitcoin.app from the command line:

Oh, forgot to add:  Thanks to everybody who helped out!

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

The main feature in this release is wallet private key encryption;
you can set a passphrase that must be entered before sending coins.
See below for more information; if you decide to encrypt your wallet,
WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you
forget or lose your wallet passphrase, you lose your bitcoins.
Previous versions of bitcoin are unable to read encrypted wallets,
and will crash on startup if the wallet is encrypted.

Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
(bdb version 4.8) than previous versions (bdb 4.7). If you upgrade
to version 0.4 and then revert back to an earlier version of bitcoin
the it may be unable to start because bdb 4.7 cannot read bdb 4.8
"log" files.

Notable bug fixes from version 0.3.24:
--------------------------------------

Fix several bitcoin-becomes-unresponsive bugs due to multithreading
deadlocks.

Optimize database writes for large (lots of inputs) transactions
(fixes a potential denial-of-service attack)



Wallet Encryption
-----------------
Bitcoin supports native wallet encryption so that people who steal your
wallet file don't automatically get access to all of your Bitcoins.
In order to enable this feature, choose "Encrypt Wallet" from the
Options menu.  You will be prompted to enter a passphrase, which
will be used as the key to encrypt your wallet and will be needed
every time you wish to send Bitcoins.  If you lose this passphrase,
you will lose access to spend all of the bitcoins in your wallet,
no one, not even the Bitcoin developers can recover your Bitcoins.
This means you are responsible for your own security, store your
passphrase in a secure location and do not forget it.

Remember that the encryption built into bitcoin only encrypts the
actual keys which are required to send your bitcoins, not the full
wallet.  This means that someone who steals your wallet file will
be able to see all the addresses which belong to you, as well as the
relevant transactions, you are only protected from someone spending
your coins.

It is recommended that you backup your wallet file before you
encrypt your wallet.  To do this, close the Bitcoin client and
copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user
name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/
on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on
Windows Vista and 7 and /Documents and Settings/(user name)/Application
Data/Bitcoin on Windows XP).  Once you have copied that file to a
safe location, reopen the Bitcoin client and Encrypt your wallet.
If everything goes fine, delete the backup and enjoy your encrypted
wallet.  Note that once you encrypt your wallet, you will never be
able to go back to a version of the Bitcoin client older than 0.4.

Keep in mind that you are always responsible for your own security.
All it takes is a slightly more advanced wallet-stealing trojan which
installs a keylogger to steal your wallet passphrase as you enter it
in addition to your wallet file and you have lost all your Bitcoins.
Wallet encryption cannot keep you safe if you do not practice
good security, such as running up-to-date antivirus software, only
entering your wallet passphrase in the Bitcoin client and using the
same passphrase only as your wallet passphrase.

See the doc/README file in the bitcoin source for technical details
of wallet encryption.

Signed SHA1 checksums of the binary release files:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

25c3ec9683d62235afea24d4a147d4616d8a884f  bitcoin-0.4.0-linux.tar.gz
a800d9fa4aa61527e598708f4ace7f855c22a46b  bitcoin-0.4.0-macosx.dmg
1d2c8d82ede5e8aa9f83b59da07e443de89c5c8f  bitcoin-0.4.0-src.tar.gz
ecf1304ff467bd30dc668b3dadff3044c3c86df1  bitcoin-0.4.0-win32-setup.exe
6034efe23e4bd76b0860f633e81710cd66d499db  bitcoin-0.4.0-win32.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAk58n20ACgkQdYgkL74406ibEACgzyZj86lsQORi5HTs/N3ABCes
Pg8AoKFXU1vxiZI9qZOQ5ZET60ewcynW
=sY+Q
-----END PGP SIGNATURE-----


Full changelog ("git shortlog --no-merges v0.3.24..")
-----------------------------------------
Abraham Jewowich (1):
      Fix bug with accessing vchData[0] when vchData is empty.     Fix typo in CBase58Data::CompareTo

Alex B (2):
      Romanian translation added
      Spanish translation update

Alex Waters (1):
      Updated readme file

Daniel Folkinshteyn (1):
      Update the list of seednodes.

Dawid Spiechowicz (1):
      added polish wallet encryption messages

Dean Lee (1):
      Update to the Chinese Simp translation

Dev Random (4):
      Linux gitian config with separate wxWidgets build
      Mingw gitian with separate wxWidgets and boost
      Mingw gitian build with deterministic bitcoin.exe by use of faketime
      Add Gitian Build descriptors for Boost and wxWidgets.

Doug Huff (1):
      Make mlock() and munlock() portable to systems that require the address to be on a page boundary.

Dylan Noblesmith (1):
      mlock() all private keys in memory

Eric Hosmer (1):
      Added crypter to makefile.vc.

Fabian H jr. (1):
      Updated checkpoints, maybe Tx fee should be reduced to 0.0001 from 0.0005 and maximum minimum tx should be 0.0010.

Gavin Andresen (24):
      Do-nothing MapPort() ifndef USE_UPNP.  fixes #450
      Don't std::advance past beginning of transactions array.  Fixes #465
      Remove unused ScanMessageStart function
      Compile with DEBUG_LOCKORDER to detect inconsistent lock orderings that can cause deadlocks
      CHECKMULTISIG unit tests.
      Highlight mis-matching locks
      Fix rpc-hanging deadlocks
      Fixed potential deadlocks in GUI code.     Also changed semantics of CWalletTx::GetTxTime(); now always returns the time the transaction was received by this node, not the average block time.     And added information about -DDEBUG_LOCKORDER to coding.txt.
      Fix typo ("you own security")
      SetCrypted() obtains keystore lock, to be safe.
      Logic running with -keypool=0 was wrong (empty keys were being returned). Fixes #445
      Fix RPC call name in error message.
      obtain cs_wallet mutex to protect vchDefaultKey
      Fixed regression I introduced: wallets with lots of transactions were unusable in GUI.
      Fix bad merge: getaccountaddress was broken for new accounts
      Give hard-coded seed nodes a random last-seen time, to randomize order they're tried.
      Do not try to download blockchain from 0.3.23 nodes
      If compiled -DDEBUG_LOCKORDER and run with -debug, print out every mutex lock/unlock (helpful for debugging something-is-holding-a-mutex-too-long problems)
      Stay connected to seed nodes; disconnecting causes problems if you are trying to make the initial blockchain download.
      Versions 0.3.20 THROUGH 0.3.23 have trouble with blockchain downloads; avoid them
      Bumped version numbers to 0.4.0rc1
      Optimize database writes for transactions with lots of TxIns.     Patch from ArtForz, who discovered the problem.
      Fix AddAddress cs_mapaddresses/db transaction deadlock
      Fix QA email address

Giel van Schijndel (15):
      fix warning on 64bit systems: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      fix warnings: expression result unused [-Wunused-value]
      fix warnings: using the result of an assignment as a condition without parentheses [-Wparentheses]
      fix warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
      fix warning: X enumeration values not handled in switch [-Wswitch-enum]
      fix warning: unused variable 'X' [-Wunused-variable]
      fix warning: unused function 'SigIllHandlerSSE2' [-Wunused-function]
      fix warning: variable ‘nMinDepth’ set but not used [-Wunused-but-set-variable]
      fix warning: control reaches end of non-void function [-Wreturn-type]
      Make some global variables less-global (static)
      Cleanup makefiles such that diffs to them are smaller
      Move func 'REF' from util.h to serialize.h
      Start moving protocol-specific code to protocol.[ch]pp
      Move CAddress to protocol.[ch]pp
      Move CInv to protocol.[ch]pp

Han Lin Yap (2):
      Comment "deprecated"
      Add a note to only include .po file

Jay Weisskopf (4):
      Add logos/branding currently found on bitcoin.org into NSIS installer.
      Set default compression for NSIS installer to LZMA.
      Remove NSIS branding from bottom divider.
      Increase resolution of Windows icon.

Jeff Garzik (8):
      Update CWallet::LoadWallet for proper return type.
      Bump version to 0.3.25
      doc/README: word wrap into something readable
      CAddrDB::LoadAddresses: properly initialize CAddress
      src/makefile.unix: remove -DFOURWAYSSE2
      Add reference python miner, in contrib/pyminer/
      README.md: word wrap text file
      Revert "Define MSG_NOSIGNAL to 0 on platforms where it is unavailable."

Jeroenz0r (1):
      Translation from "Open Bitcoin" to "Verstuur Bitcoins"

JoelKatz (1):
      Fix UNIX-specific thread handle leak.

Johannes Henninger (1):
      Identify as "Bitcoin + version number" when mapping UPnP port

Luke Dashjr (7):
      Update nTime after nExtraNonce to avoid potential race     (extraNonce being reset due to just-occurred time change after nTime is set)
      Reset extraNonce only every 15 seconds, just in case some miner is updating time himself and stuff
      Reset extraNonce only when prevBlock changes, so miners can continue updating the time on their work until it's stale
      Support for boost filesystem version 3
      ignore stuff
      Save coinbase, not just extraNonce
      Bugfix: Use timestamp in coinbase rather than "bits", needed to ensure coinbase txn is unique even if address is the same

Matt Corallo (35):
      Add minversion to wallet.
      Add wallet privkey encryption.
      Set the number of SHA512 rounds based on the speed of the computer.
      Push unlocked_until in getinfo.
      Dynamically remove/insert the Options for encryption in the menus.
      Add the walletlock RPC method to lock the wallet manually.
      Add Wallet Encryption section to README
      Use DB Transactions when encrypting wallet.     This speeds up the encryption process significantly.
      Make an invalid addrIncoming so that old clients crash.
      Update makefile.linux-mingw to work with crypter and UPnP fix.
      Fix makefile.linux-mingw
      Fix crashes when a wallet is locked and GetReservedKey() is called
      Generate Warning when using default key.
      Fix Build in GetReservedKey() in wallet.cpp
      Fix bad return values in LoadWallet.
      Actually use mapAlreadyAskedFor.
      Fix EncryptKeys crash introduced by a9ba4710, identified by TD.
      Check for duplicate txins in CheckTransaction.
      Make it clear that setting proxy requires restart to fully apply.
      Don't listen if on TOR (resolves #441).
      Add missing include to serialize.h
      Add file for transaction tests.
      Cleanup test suite output to be more useful.
      Unify copyright notices.
      Missed a 'password' should be 'passphrase'.
      Fix incorrect RPC error messages
      Add specific wallet encryption details to doc/README
      Upgrade dependancies and tweak build process.
      Update binary mos to latest translations.
      Fix build process to actually work.
      Add binary mo for new translation.
      Update gitian build descriptors to produce proper builds.
      Update bitcoin icon to make nsis setup exe deterministic.
      Update binary mo to match latest po translation.
      Restructure gitian files and add download config files.

Michael Bemmerl (4):
      Basically some grammatical fixes of the German translation.
      Added German wallet encryption messages translation.
      Changed Russian translation according to comment in issue 395
      Updated German translation

Michal Zima (1):
      Updated czech translation

Nils Schneider (2):
      log low-level network messages only when fDebug is set
      missed printf in AbortMessage(); merged printfs in EndMessage

Patrick Varilly (1):
      Single DB transaction for all addresses in a message

Pieter Wuille (11):
      Prepare codebase for Encrypted Keys.
      Do not use obsolete CPrivKey for passing keys around
      Bugfix: add autogenerated addresses to address book
      get rid of mapPubKeys
      Use CBitcoinAddress instead of string/uint160
      split off CBase58Data from CBitcoinAddress
      Fix for small change outputs
      Bugfix: don't overuse limited ExtractAddress
      avoid strAddress + validity checks
      SocketHandler thread can be detached
      Updated dutch translation

Stéphane Gimenez (1):
      Single DB transaction for addresses from DNS seeds

Vegard Nossum (6):
      Add missing includes to key.h
      Add missing include to script.h
      Add missing includes to net.h
      Fix testing setup
      Add prototype for EvalScript() to script.h
      Add a file for script tests

Venkatesh Srinivas (4):
      Test for SO_NOSIGPIPE rather than assuming all BSDs support it.
      Qualify make_tuple with boost:: namespace.
      Use 'unsigned char' rather than 'char' for pchMessageStart.
      Define MSG_NOSIGNAL to 0 on platforms where it is unavailable.

Wladimir J. van der Laan (2):
      remove magic number: change threshold for nLockTime to constant
      make SetHash160 return a value (as specified in the function signature)

cjdelisle (1):
      wxWidgets needs to be at least version 2.9.1 because wallet crypto uses ToStdString() which is not in 2.9.0

ovdeathiam (1):
      Edited locale/pl/LC_MESSAGES/bitcoin.po via GitHub

I split this from "Be Safe" thread in Alternate Cryptocurrencies, and moved it here so more people could voice their opinions.

RE: a be-safe thread for bitcoin:  There are already a couple "be safe" threads stickied in the Bitcoin Discussion forum (e.g. the beware of trojan wallet stealers thread, the newbies article that links to keep-your-wallet-safe, etc).

Writing a more general one is not a bad idea; if I knew last November all the craziness that would happen this year I would have written one back then (but back then nobody was spending tens of thousands of dollars speculating on bitcoin).

RE: putting my employer in my forum signature:  what do other people think? Would that be unfair advertising for TruCoin or good full disclosure?

If it drives more business to TruCoin then that will eventually, hopefully, mean more money in my pocket, so if it is up to me heck yeah I'll mention TruCoin in my signature!

I like the idea of trying to prove that the DoS code doesn't increase the chance of network fragmentation.

The DoS countermeasures should be careful not to penalize or ban peers for any messages that the client will (or might, in another situation) relay.

For example, double-spent transactions don't trigger the DoS countermeasure code.

That should be sufficient to prevent split-the-network attacks; if an attacker wants to try to split the network, the only way the attacker would be successful is if it could somehow send messages to peers that ARE relayed and trigger disconnections elsewhere in the network.

Looking through the patch:
  https://github.com/bitcoin/bitcoin/pull/517/files

... I see a couple of cases where relayed messages are penalized (block times too far off, and hitting the free transaction relay limit).  To be safe, I'll remove them.

As for relaying block headers for banned peers:  "banned" means "if you try to connect to me I'll simply drop the connection attempt." I feel strongly that is the correct behavior; the motivation for the DoS prevention code is to "whitelist" peer behavior, and try to prevent possible 0-day attacks like "if I send you THIS invalid transactions followed by THAT sequence of weird bytes followed by THIS corrupted block header THEN I trigger an obscure bug in the version of OpenSSL that you're running and compromise your machine...."

Pronounced "barfy"

GPUs suck at accessing main memory.

But they're very, very good at accessing on-board memory.  See, for example (from a couple of years ago)
 http://blog.cudachess.org/2009/07/cpu-vs-cuda-gpu-memory-bandwidth/
I predict it'll take... mmm... 3 weeks after source code is released for the first faster-on-a-GPU solidcoin 2.0 closed-source miner to come out.  8 weeks until there's an open-source one available.

But my predictions are often wrong.

There's been a little discussion on the bitcoin-dev mailing list.

I think it is a great idea, but "BEP" is the wrong name (because there are already BitTorrent Enhancement Proposals).

No.

Why not? I don't remember. Why would you want to un-encrypt it?  (I ask because if you want to save an unencrypted backup then maybe a better feature would be "backup wallet" with an option to backup encrypted or unencrytped)

Status of the multisig proposal:  There are two, a stripped-down, simplified one:
  https://gist.github.com/39158239e36f6af69d6f

... and a supports-more-use-cases-but-is-more-complicated one:
  https://gist.github.com/dba89537d352d591eb36

RE: long delay, no window on startup:  will be made much better by the QT splash screens in bitcoin 0.5.
RE: lots of GUI bugs: whole rafts of wxwidgets-related bugs will go away with the switch to QT in bitcoin 0.5.

RE: incompatible on older version of windows: I don't know nuthin about windows compatibility, somebody want to volunteer to investigate?  Is bitcoin 0.4 less compatible for some reason than 0.3.24 was?  (shouldn't be...)

Linux and Windows and Mac binaries are available at sourceforge:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/test/

And HTTPS download from the Amazon Cloudfront content distribution network:
 https://d24z2fz21y4fag.cloudfront.net/downloads/bitcoin/bitcoin/bitcoin-0.4rc2-win32-setup.exe
 https://d24z2fz21y4fag.cloudfront.net/downloads/bitcoin/bitcoin/bitcoin-0.4rc2-win32.zip
 https://d24z2fz21y4fag.cloudfront.net/downloads/bitcoin/bitcoin/bitcoin-0.4rc2-macosx.dmg
 https://d24z2fz21y4fag.cloudfront.net/downloads/bitcoin/bitcoin/bitcoin-0.4rc2-linux.tar.gz

The d24z.... downloads are an experiment; I like that they're https, I don't like the obscure d24z... URL (that's actually github's CloudFront id; I asked, and they have no objections to linking directly to the https version of the downloads).

Executive summary release notes:

The main feature in this release is wallet private key encryption;
you can set a passphrase that must be entered before sending coins.
See below for more information; if you decide to encrypt your wallet,
WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you
forget or lose your wallet passphrase, you lose your bitcoins.
Previous versions of bitcoin are unable to read encrypted wallets,
and will crash on startup if the wallet is encrypted.

Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
(bdb version 4.8) than previous versions (bdb 4.7). If you upgrade
to version 0.4 and then revert back to an earlier version of bitcoin
the it may be unable to start because bdb 4.7 cannot read bdb 4.8
"log" files.

No.

There are 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 possible bitcoin addresses.

If your calculator can handle numbers that big, you can play around with how long it would take to try generate one quadrillionth of them if you could generate a trillion per second.

(I get an answer of a bit over 46 trillion years)