I used to have a list of pools here, but it had gone unupdated in a long time and was very incomplete...essentially, most the major pools and large miners are connecting to the relay network in some capacity.

UPDATE: The relay network has been updated to use Bitcoin FIBRE - you can find th enew instructions to peer with it at http://bitcoinfibre.org/public-network.html.

Many of you have likely seen the recent discussions on the P2Pool thread and the post on the foundation blog about the relay network.

It exists as a way for pool operators (and all miners, though not hashers) to get their blocks relayed quickly across a separate network both as a backup to the P2P network and as a quicker way to get the latest blocks as it skips relaying transactions which have already been seen. Thus, if you're a miner anywhere from a small p2pool miner to a large pool, you should be running one of the relay network clients.

You can see more information about its original goals and its original announcement here

You can find the latest information at http://bitcoinrelaynetwork.org/

Many of you have likely heard about this by now, but here's to an official announce...
You can now create your own alt with just a few clicks and a small payment to cover the server costs of a honking compiler server.
Just go to http://coingen.io/ (thanks to mappum for the domain), fill out the form, and have fun with your new coin!

Over the past ~24 hours, the number of satoshidice transactions has increased hugely, leading to transaction memory pools (currently) at around 9000 transactions.  Satoshidice spam is already a huge % of current transactions, but now its just ridiculous.  Is it time to start deprioritizing transactions which use very common addresses?

I made a nonstandard transaction with all the info you need to spend it contained inside, now all you have to do is create the corresponding scriptPubKey and get your free 1.5 BTC
http://pastebin.com/VKi7psby This one was spent.

EDIT: I made another one for later, donate for the winner: 1GYR2ugRiAZmnrDuyQFNSRBzLBn3NXmvoJ (Ill be posting the first clue sometime tomorrow, sadly this one isnt quite as bitcoin-related but it ends in free bitcoins, so what do you care?).

Scroll down for the first clue and get on your way.

[THIS THREAD IS VERY OUT-OF-DATE AND SAYS SOME THINGS THAT AREN'T TRUE ANYMORE. IT APPEARS THAT FOLLOWING IT HAS CAUSED SOME USERS TO HAVE INCREASED DIFFICULTY RECOVERING THEIR WALLETS, SO PLEASE DONT DO THIS UNTIL (IF) THIS THREAD IS UPDATED]

THIS THREAD IS VERY OUT-OF-DATE AND SAYS SOME THINGS THAT AREN'T TRUE ANYMORE. IT APPEARS THAT FOLLOWING IT HAS CAUSED SOME USERS TO HAVE INCREASED DIFFICULTY RECOVERING THEIR WALLETS, SO PLEASE DONT DO THIS UNTIL (IF) THIS THREAD IS UPDATED

So, you open Bitcoin to check on your Bitcoins and to your dismay it won't open.  Now what?
You probably see errors like

EXCEPTION: NSt8ios_base7failureE
CDataStream::read() : end of data
bitcoin in AppInit()

Don't worry, your keys are almost always still there, they are just hiding, I'm gonna help you find them

Prerequisites: A willingness to open your Terminal application, Python

Methodology: Usually when a wallet gets corrupted, its not the private keys that get corrupted but some setting, transaction or public key.  In order to get Bitcoin to open and allow you to access your Bitcoins, we will use bitcointools' fixwallet.py to delete settings, accounts, public keys, and transactions and see if we can get you access to your private keys to spend your coins again.

Notes:

• This guide will refer to your .bitcoin directory several times, by default this is on Linux, /home/folder/.bitcoin, on Windows %AppData%/Bitcoin (probably C:\Users\UserName\AppData\Roaming\Bitcoin on Win Vista/7 or C:\Documents and Settings\UserName\Application Data\Bitcoin on XP) and on Mac OSX, /Users/UserName/Library.  If you use a different bitcoin folder, use it instead and add a --datadir=/path/to/your/bitcoin/folder each time you call one of the bitcointools programs.

Guide:

• 1. BACKUP YOUR ENTIRE .bitcoin FOLDER Period, even corrupted wallets will still have useful data in them and the database folder may have enough BDB logs for a real BDB expert to fix your wallet if all of this fails.  Also, several points in the guide require you to restore the original corrupted wallet.dat, so you have to have it.
  
• 2. Often times the BDB logs or other DBs get corrupted and Bitcoin refuses to start.  Delete all the files in your .bitcoin directory except for your wallet.dat and try Bitcoin again.  This should solve 90% of the corrupted DB errors you see with Bitcoin.  If this doesn't work, the corruption lies in your wallet, but don't worry, it should still be fixable.
  
• 3. Grab yourself a copy of Gavin's excellent bitcointools either by using git clone https://github.com/gavinandresen/bitcointools.git or by using the download tar.gz from https://github.com/gavinandresen/bitcointools.  Untar it to a directory of your choice and cd /path/to/that/directory in your Terminal application.
  
• 4. First, lets do a basic sanity check on the wallet.  Call ./dbdump.py --wallet once you have cd'd to the bitcointools directory.  You should get some out put that looks like

  PubKey 0402...de94 1XXXXXXXXXXXXXXXXXXXXXXXXXX: PriKey 3082...de94

  some that looks like

  ADDRESS 11XXXXXXXXXXXXXXXXXXXXXXXXXX :

  Change Pool key 1: 1XXXXXXXXXXXXXXXXXXXXXXXXXX (Time: Fri May 27 16:27:28 2011)

  and finally some settings like

  fUseUPnP: True
  

  If some of those are missing, dont worry, all that really matter is the first type, which contains your bitcoin private keys. As long as you dont see any errors along the lines of ERROR parsing wallet.dat, type key, ekey, or wkey, and you have several lines of the first type, you should have no problem getting access to your bitcoins. If you dont have any lines that look like the first then you are going to have to work a bit harder to get your keys back, which is outside of the scope of this post.
  
• 5. Now that you know your wallet still has your private keys in a readable state, its time to recover.  Run ./fixwallet.py and replace your old wallet.dat with walletNEW.dat that bitcointools just created in your bitcoin folder.  If you see several ERROR messages that are of a type other than key, you know it is working.  Try to open Bitcoin, you may find that it opens perfectly now, or you may find several issues in this wallet wrt your settings, accounts, etc which you may need to re-enter.  If you want to clear your accounts, transactions, settings, etc or Bitcoin still isnt working for you, keep reading.
  
• 6. This involves some trial-and-error.  The goal here is to run ./fixwallet.py with options to drop the corrupted parts of your wallet.  The options are --noaccounts, --nosettings, --notxes and --nopubkeys.  First off, replace the wallet.dat you created in step 5 with the original, corrupted, one.  Then run ./fixwallet.py --noaccounts --nosettings --notxes --nopubkeys; replace your wallet.dat in your .bitcoin folder with walletNEW.dat and see if Bitcoin opens (note that your transactions and balance will be gone when you use --notxes, this is intentional, read on for instructions on how to get them back).  If Bitcoin doesnt open, the recovery of your wallet falls outside the scope of this guide; you might try asking an expert who you trust to see if they can get further.  If it does work, however, repeat this step with less and less flags until Bitcoin refuses to open.
  If you used --notxes, open Bitcoin with -rescan to repopulate them from the block database. DO NOT use the --notxes option if you had transactions in your wallet which are not yet in a block.
  If you used --noaccounts, you will need to recreate your accounts.
  If you used --nopubkeys your list of public keys in your address book may be cleared, note that your old addresses will still work, however you may wish to change your publicized addresses to those which you can add to your address book so that they appear properly in your client.
  If you used --nosettings, please go back to the Options dialog and re-enter all your settings.  
  

Comments, suggestions, sticky?

I wrote up what I think should be acceptable to make fees clearer and easier to manage.
https://github.com/TheBlueMatt/bitcoin/commits/feefix.
It is separated into 3 commits as follows:

Make the fee error/dialog messages much clearer.

Update fee policy to be much more customizable.

This changes nTransactionFee into nBaseTransactionFee and
nPerKBTransactionFee where nBaseTransactionFee is applied to each
transaction once and nPerKBTransactionFee is applied per KB to
each transaction.

Also, fOverrideTransactionFee has been added to allow the ignoring
of GetMinFee() when creating transactions.

These can be set via command line options, rpc commands, and in the Options dialog (in a new second tab called "Transaction fees")

Add setautocommit, reject transaction and committransaction.

Here is the help for setautocommit:
If <autocommit> is false, the send* functions will return a txid,
which must be manually committed instead of being immediately committed.
Once a new transaction has been created, you can get information about it by using
gettransaction <txid>. It can then be commited or rejected using
committransaction <txid> or rejecttransaction <txid> respectively.

I decided to actually look at what is required to backport to wx2.8.  Actually, its mostly copy/paste/sed crap. 
Its done in the worst possible way and is ridiculously inefficient, I just wanted to see if it could be done.
As it turns out, it seems completely possible.
The GUI shows up and the majority seems to work.  Translations appear to work, but that is only in very brief testing.
I'm sure I've made 100 or more typos, so I'd like some corrections (and pointing out of much better ways of converting crap between wxString and std::string, if someone can find one).
You can grab the version at https://github.com/TheBlueMatt/bitcoin/tree/wx2.8

I was thinking, when we move to encrypted wallet in 0.4.0, we might as well upgrade the BDB we are releasing our builds with to 4.8 from 4.7.  The debian packages already link against 4.8, as do the Mac releases (assuming build-osx.txt is right).  The actual databases formats are identical, but the log format changes (not 100% sure here, but that is what I've been told by several people).  That would mean it should never be an issue for end users, but if they start copying wallets around from OSX to Win with the logs, they might see DB errors.  Comments, concerns, questions?

[EDIT:]

I suppose the title speaks for itself, but here is the commit blurb:

Add wallet privkey encryption.

This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.

Keys are encrypted with AES-256-CBC through OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using AES256 with (by default) 1000 rounds and
a random salt.

By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <password> or, from the GUI menu, Options->
Encrypt Wallet.

When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassword <password> <time to keep key in memory> first.

A keypoolrefill command has been added which tops up the users keypool
(requiring the password via walletpassword first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their password and call
topupkeypool.

A walletpasswordchange <oldpassword> <newpassword> has been added to allow
the user to change their password via RPC.

Whenever keying material (unencrypted private keys, the user's password, the
wallet's AES key) is stored unencrypted in memory, any reasonable attempt is
made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.

Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.

Thanks to jgarzik for the original patch and sipa for all his input.

Pull request is at https://github.com/bitcoin/bitcoin/pull/232
https://github.com/bitcoin/bitcoin/pull/352
Now rebased on wallet class + mostly based off of Pieter's suggested model.

EDIT: New commit blurb to match changes.

Posted this in discussion to try to get the most traffic, but not getting much and it is technically "development" so please grab the instructions on updating the translations here: http://bitcointalk.org/index.php?topic=8390.0

[EDIT:]

I just went back with poedit and updated all the translation files to match the newest source and there are quite a few new strings which need to be translated.  Please go to https://github.com/TheBlueMatt/bitcoin/tree/translations/locale, click on the language you wish to translate, LC_MESSAGES, and bitcoin.po.  Download the raw file and search for msgstr "" within, and update the translation of whatever is in the msgid above.  When you have an updated bitcoin.po, please post it here and Ill make sure it gets merged upstream into the next bitcoin release.  If you want to add a new translation, feel free to download any bitcoin.po and update all of the msgstr's with new ones, and post it here, making sure to specify what language you are translating.

EDIT: Got a spanish one, still need a ton more though...thanks.

I noticed in a screenshot a while back that I had forgotten to translate "Enable Port Mapping via UPnP" (in the options dialog box) before UPnP was merged.  If someone who speaks RU, PT, NL, IT, FR, ES + DE can translate that for me, it would be much appreciated. 

Bonus points for translating:
"Don't encrypt the private keys in the wallet."
"Automatically encrypt old, unencrypted keys."
"Enter a password to encrypt/decrypt all addresses created after this point.\nIf you do not want to encrypt new private keys, please start the client with the -nocrypt flag set.\nWARNING: If you lose this password, no one, not even the Bitcoin developers can get you your Bitcoins back."
"Password"
"Error: Please supply a wallet encryption/decryption password." (users have to enter a password, "" is not accepted)
"Please supply the current wallet decryption password." (same usage as above)
"Wallet decryption setup failed" (a generic error message which indicates an internal error in wallet decryption initialization)
"The password entered for the wallet decryption was incorrect."
"You specified the -nocrypt option, but the wallet has encrypted private keys, bitcoin will now exit."
"Would you like to encrypt the remaining unencrypted keys in your wallet (Recommended)?\nNote: This means older version of Bitcoin will not be able to read any of your wallet."
"Creating new keys, this may take a minute..." (aka filling keypool, but I thought this was more readable for end-users)
"Enter the current password to the wallet."

[EDIT:]

This is a working form of jgarzik's wallet private key encryption patch with some added security (originally here).
https://github.com/TheBlueMatt/bitcoin/commit/0f2fec7d2fc7b6e1dac187735402a721b63ca7cf.
I didn't make this a pull request as I don't think its done in the best way possible and wanted comments.
Currently it encrypts with AES256 in the same way jgarzik's original patch does (private keys only, enter the password at startup or via WALLET_PASSPHRASE environment varible).  It does not go back and encrypt existing unencrypted wallets but any new keys will be encrypted.
Is it best to attempt to sign with keys derive the public keys from the private ones on load to test the password, or should a hash be used? All the ekey's are tested, should that be changed or kept to be safe? etc.

EDIT: Added the option to encrypt every private key already in an unencrypted wallet and bug the user on every application open to do so.
EDIT 2: Added the option to change the password for the wallet.
EDIT 3: Pull request at https://github.com/bitcoin/bitcoin/pull/203

[EDIT:]

I'm very tired so I'll keep this short: https://github.com/bitcoin/bitcoin/pull/182
Please discuss hex/tonal support.  Current pull does not have it, but adding it would be easy based on Luke-jr's original patch if the community supports it.

EDIT: Out of respect to Luke-jr's polls, I am closing this one, please vote there.
http://bitcointalk.org/index.php?topic=6206.0
http://bitcointalk.org/index.php?topic=6207.0
http://bitcointalk.org/index.php?topic=6208.0
Also, Luke-jr, please allow people to change their vote if they are convinced by the discussions in the thread.

[A Debate on the Usefulness of "Donating" Miners and their part in Bitcoin's long term outlook and uptake]

A Debate on the Usefulness of "Donating" Miners and their part in Bitcoin's long term outlook and uptake

I recently had a debate (mostly) with Blitzboom on the matter on #bitcoin-otc and decided I would post some of what was said here to open the discussion.  It is mostly in reference to theymos's quote below (which was on the thread related to disabling the built-in miner, so I decided to not respond to it there):

I was thinking about that too but won't someone who essentially never solves a block have a near 0 effect on the network?
I'd guess that if you solve a block every 6 months on average (or worse) you won't speed it up / affect other miners you'll just waste energy. Is there any benefit to it at all? Assuming you're not in a pool of course.

If the idea spreads that mining helps the Bitcoin network, then tens of thousands of people might turn on generation. Many of these people won't ever win a block, but if some do, then the network will be affected. Every time an unprofitable miner wins a block (or whenever they contribute to a pool), the difficulty will go up.

When the difficulty goes up, the least efficient miners are pushed out of the market unless they are volunteers. Volunteers therefore take up a greater and greater portion of the network's total CPU. This is bad for at least two reasons:

• The network becomes less efficient, using more energy than it needs to.
• "Amateur" miners are not able to respond to threats as quickly as professional miners. They're probably not running the most recent version of Bitcoin, and even if they are, professional miners can make changes to Bitcoin without a new release. The situation is better when the amateur miner is part of a pool, but if the pool goes rogue, the amateur miner will probably not know about it.

It's also really going to irritate me if I see propaganda saying, "Do your part: mine Bitcoins!" or something like that, when the network is perfectly capable of running without volunteers.

My objection to this is mostly due to its infeasibility in the long term in the current model of bitcoin adoption.  In theymos' proposed model of the bitcoin economy, miners only exist where it is profitable for them, ie the price of bitcoin is higher than the price of electricity.  This means that there will be relatively few high-power miners making up some large percent of the mining power (for the sake of argument, lets assume the rest of the miner's total power is negligible).  Because bitcoin mining is profitable, those who have high end cards will bring them online and sell for their costs, making the price drop and leaving only the few most efficient miners.  (Problem 1)  This creates a system in which bitcoin's price is equal to the price of electricity.  If this is how the bitcoin network always will be, there will always be a very small number of efficient miners who have some large percent of the total value of bitcoin.  (Problem 2)

Problem 1: In order for the network to function the way it was designed, we need as many miners as possible.  If mining is controlled by a few, slarge miners, it will always be succeptible to a double-spend attack by someone with considerable resources.  Take, for example, ArtForz.  Even if he were to triple his capacity, he would still not be nearly capable of defending the entire network against an attack by someone with the resources of the recent Mysterious Miner.  If several others, like ArtForz, brought similar scale miners online (as would happen in theymos' model), even them together would not be able to defend against an attack by a very large botnet or the use of a supercomputer by a well-connected attacker (say, an attacker who works at a university and is willing to take the risk to take over the entire computer for a couple hours). 

Problem 2: This is one of the largest issues with the perception of bitcoin by the average person, and is one of the largest complaints I see whenever someone posts about bitcoin.  "It is a ponzi scheme".  And as long as most new generation happens between a small community of large-power miners, it effectively is.  New users pay the miners when they join (as miners are the largest sellers), but if many of them want out, there is no support there.  As long as there exists miners which can crash the bitcoin market overnight (which would be very easy for some of the current large-scale miners such as ArtForz), the bitcoin economy carries with it many of the traits of a ponzi scheme (albeit a very open one) which makes MANY people very wary of investing.

If bitcoin is to be used by any medium to large size organizations, there needs to be very strong confidence in its ability to continue with some amount of value and with a secure network.  IMHO this idea that mining is not good for the network is ridiculous, as currently, miners are making such large profits that the first thing people see in bitcoin is a ponzi scheme and this needs to disappear on the back of more mining power.

Feel free to tear this apart.

[EDIT:]

After several VMs, I finally got bitcoin to build properly on Windows.  To avoid others having to go through that, I zipped up all the folders in a --lzma tar and posted them here.  If you unzip the tar to C:, you should be able to open the msys/1.0/msys.bat file, cd to ~/Administrator/bitcoin and make -f makefile.mingw without any problems.  
This includes all the built sources for all the dependencies of the mainline bitcoin client.  After you have built it, you can find it in C:/msys/1.0/home/Administrator/bitcoin/bitcoin.exe.  

Notes:
openssl is actually openssl-1.0.0d, but the makefile looks for it in 1.0.0c, so the folder was renamed.  To make openssl, you will need to install perl, I used ActiveState Perl which seemed to work well.
To use git, you need to run /c/Git/bin/git.exe.  
Untarred, the folders total somewhere around 4.75GB (the archive is 450MB).  
Yes, I could have cleaned them up and only included sources, but I've seen identical installs fail on different version, so everything is included.  
I built the system on Windows Server 2003 32-bit and tested building bitcoin on Windows 7 32-bit.  That said, I make no guarantees that this works ever, anywhere (and would be surprised if it did).  

EDIT: If you really want to build your own copy of everything from the ground up, see http://bitcointalk.org/index.php?topic=5851.msg86700#msg86700

I just finished setting up a nightly build server.  It currently only builds i686 for linux, but I'm hoping to add Windows soon.  It also includes an up to date copy of the blockchain with each nightly.  
It can be found at bitcoin.bluematt.me.  Thanks goes to validus for the bandwidth.  

Edit: URL is now bitcoin.bluematt.me/bitcoin-nightly.  It is now DNS load balanced.  Thanks to validus and vrs for bandwidth.

[UPDATE:]

I wrote a patch for UPnP via miniupnpc.  Currently it is just for UNIX, but shouldn't be too hard to get running on OSX.  Some people have mentioned that Windows has its own native library for UPnP which we should use.  Currently UPnP is on off by default and can be easily turned on with -upnp but that is up for debate (actually poll).  See the pull request here: https://github.com/bitcoin/bitcoin/pull/133.

UPDATE: The patch now works for OSX and Windows and includes a WXUI switch for enabling/disabling UPnP at runtime.  Note that the windows version still uses miniupnpc (not the native windows libraries, does anyone feel very strongly about this?).  
As I couldn't get miniupnpc to compile on Windows, the makefile is designed to use the binary version published on the website (which includes the library against which bitcoin is linked, upnpc-exe-win32-20110215.zip).  To get the relevant headers, however you need to download the original source archive (miniupnpc-1.5.20110215.tar.gz) and copy *.h to C:\upnpc-exe-win32-20110215\miniupnpc.  Note that the UNIX/OSX versions expect version 1.5 (slightly different UPNP_AddPortMapping definition).  
Also, the translations of the copyright notice in the about dialog need changed before this should be pulled.  Currently only dutch has been translated (thanks joepie91).

UPDATE 2: Added translations by community members for French, Spanish and German (plus existing Dutch) and added Russian, Portuguese and Italian translations from Google Translate.  Anyone had time to review the code and have suggestions or think it is ready?

UPDATE 3: Italian translation updated thanks to Joozero.  Anyone have comments on the code?

When HTTP/1.1 was created, a return code (402) was created to indicate that a payment is required.  However, no protocol has ever been created to use it, hence it sits as "reserved for future use".  Almost no sites actually use it (wikipedia seems to indicate that Apple's MobileMe uses it from time to time) and I though it would be a great use for bitcoin.
Many companies (Facebook/Zyga, Google's Chrome App Store, etc) are working to make it as easy to pay for goods on Internet "apps" as it is to pay on iPhones and Androids (well mostly iPhones). 
If Bitcoin is to be a currency for online purchases (IMHO it is perfect for such things), making it easy to buy things with Bitcoin is important.  Although it needs to be easy to buy Bitcoins with USD, it is also important for it to be easy to spend Bitcoins on digital goods.
Hence, I think the HTTP 402 Status Code should be used to request payment in-browser.  This could allow one-click ordering of digital goods with Bitcoin. 
A server would respond to a request with HTTP error 402 as well as a X-Bitcoin-Address and X-Bitcoin-Price headers and a browser could ask the user if they wish to transfer the amount specified to the address specified.  When the server confirms the payment, the user would be allowed to continue.  This could be implemented in a Firefox/Chrome/Safari/etc plugin which connects to a bitcoin RPC daemon or to Mybitcoin,etc.  If a client doesn't have such a plugin, the 402 should still allow the site to send a page which requests that a Bitcoin or other transfer be made.
Does this seem like a good idea?  Would someone be willing to make a simple plugin which implements this?