To all pool operators, solo miners and p2pool miners; I have an announcement.

As everyone well remembers, we are upgrading the block-validity rule of Bitcoin to support short multisignature addresses. We realize that upgrading the code that you've been using for a long time is at least inconvenient and, for some of you, even painful or scary. But in the case of BIP30, which went into effect with the appropriately safe network support on March 15, it was necessary and in the case of this announcement the long-term benefits will far outweigh the short-term costs of this transition.

Therefore I'd like to announce that support for BIP16 has acquired a majority of mining support needed to prevent a potential permanent fork and will be activated on April 1st as previously planned.

This chart shows support over the last week: http://blockchain.info/P2SH.  Support is well over 70%.

So if you are a pool operator, solo miner, or p2pool miner you need to upgrade your Bitcoin-Qt/bitcoind before April 1st. Running a version of bitcoind earlier than 0.6 release candidate 3 past this date means running the risk of potentially wasting your hashing power mining invalid blocks since earlier versions will accept invalid spends of BIP16 transactions into their memory pools and will put them into blocks considered invalid by the majority.

p2pool users will also need to upgrade to the latest version of p2pool.

If you are a miner connecting to a mining pool, you can ignore this message.

For non-miners: version 0.6 also contains several important bug and denial-of-service fixes, so if you can, upgrade.

Backports of the BIP16 code to earlier releases are available if you are running a patched bitcoind. Patched binaries of older releases will be available soon.

Great!  Pull requests to fix compiling-on-platform-X problems are always welcome (assuming they don't also break compiling on platform-Y).

Yes.

Not relaying "smelly" blocks is a very interesting idea.

It doesn't have to be a binary relay/don't relay... you could immediately relay good blocks but wait a while before relaying bad blocks, and make the length of time you wait to relay based on how bad you think they are (maximum of maybe 10 minutes before you relay).

But... not relaying new blocks immediately might just encourage the bad guys to try to connect directly to as many nodes as possible, and that could be bad for network health.

Full disclosure blog post is at:
  http://gavintech.blogspot.com/2012/03/full-disclosure-bitcoin-qt-on-windows.html

Executive summary: we were compiling Windows binaries with the wrong flags.

Check your math-- to get 51% you'll need to dedicate six times as much hardware to hashing as it takes to get 15%:

The formula for what fraction of existing hashing power you need add to get X% of the network is:

To get 15%, you need to add 17.6%.  E.g. if existing hashing power is 100, then you add 17.6 more and your fraction is (17.6/117.6) = 0.15.

To get 51%, you need to add 104%.  E.g. if existing hashing power is 100, then you add 104, then your fraction is (104/204) = 0.51.

104 is six times as much as 17.6.

I started experimenting with user-defined checkpoints (-checkpoint=height,hash multiarg, and 'addcheckpoint <height> <hash>' RPC call) but stopped when higher priority issues came up.

It seems to me that type of low-level mechanism is the right way to go; checkpointing is a good low-level way of identifying which chain you think is "the" chain. And making it command-line/RPC configurable means we don't all have to agree on One True Way of deciding what the right blockchain aught to be; cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify.  etotheipi can write some code that scans the blockchain for well-known miner signatures (or asks miners directly if they produced a new block), etc.

If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.

How are signatures created when the phone or computer needs to spend some coins?

I'm told it IS possible to break a single ECDSA key in half and then have a complete signature generated without either device ever knowing the entire key, but, if I recall correctly, the solution involves several communication round trips between the devices and some very sophisticated cryptography.  The multikey solution is much simpler.

If I'm wrong, then great! The single ECDSA key solution will get adopted for wallet security and multisigs will only be used for escrow.

RE: makku's question "How do you identify transactions that belong to you in the first place?"

I think it is wrong to think of coins involved in a multiparty multisignature transaction as "belonging to you."  They don't belong to you-- you have to agree and cooperate with other keyholder(s) for the transaction to be spent.

You are involved in the transaction, but you need some extra information that isn't in the blockchain to know how you are involved (are you an arbitrator? a person getting paid?  a person paying somebody? something else?).

We'll release full detail tomorrow (Monday) at 16:00 GMT, after essentially the entire world has had a chance to go into work Monday morning, see the alert message, and shutdown/upgrade.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A potential security vulnerability has been discovered in the Windows
version of Bitcoin-Qt. If you are running Bitcoin-Qt versions 0.5
through 0.6 on Windows you should shut it down and upgrade to either
version 0.5.3.1 or 0.6rc4 NOW.

The command-line bitcoin daemon (bitcoind), Mac and Linux versions of
Bitcoin-Qt, and versions prior to 0.5 are not affected.

Due to the nature of the vulnerability, we believe it would be very
difficult for an attacker to do anything more than crash the
Bitcoin-Qt process. However, because there is a possibility of such a
crash causing remote code execution we consider this a critical issue.

Binaries are available at SourceForge:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/

If you have questions, feel free to drop by the #bitcoin-dev channel
on FreeNode IRC.

- --
Gavin Andresen
Gregory Maxwell
Matt Corallo
Nils Schneider
Wladimir J. van der Laan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9j12IACgkQdYgkL74406iIyQCfbxFTO3yD4Q2bHDjPlDuJn3Mj
9GAAn3mV+ggo+5q1Ujd0A5zwpFYojkE2
=g1Ad
-----END PGP SIGNATURE-----

I agree.

https://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/

... has a fairly recent copy of the blockchain.

Testnet is healthier now, although you'll need to run latest 'git HEAD' to be on the right chain. Thanks to everybody who threw some hashing power at it to outrun the bad, old-rules chains.

Stay tuned:  the testnet is a mess right now. Another genesis block reset might be needed to fix it, there have been several blockchain-splitting changes and there are several different versions of the blockchain competing (with/without the difficulty change, with/without the duplicate coinbase change, and with/without BIP16 support).

In the meantime, testing with a testnet-in-a-box or private testnet is a good way to go:
  https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/

There have already been several "transaction spam" attacks; as already pointed out, transaction fees keep them from being a big problem.

The code also limits the number of free transactions that are relayed across the network, so you can't flood the network with transactions that will never get mined.

Smarter denial-of-service attack prevention code has been a major unseen feature of the last couple Bitcoin releases.

Yes, fixed in rc2.

Bitcoin doesn't install Growl-- something else must have in the past.

PS: there is an open bug in the 0.6 release that it is not compatible with some versions of Growl; if that isn't resolved Growl notifications might be completely disabled.

PS: The 'accounts' feature doesn't scale well past a dozen or two accounts each with a few hundred transactions. It could (need to add some indices to the database so looking up transactions by account and/or time is quick), but doing that work hasn't been a high development priority.

You should be able to build your GL on top of the accounts feature of bitcoind.

The 'validateaddress' RPC call will tell you the account associated with an address and whether or not it is an address that belongs to you or is external.

Combined with the 'sendfrom' and 'setaccount' RPC calls, you should be able to create a proper general-ledger-type application where all transactions have well-defined "from" and "to" accounts.

Example of one way to do it using my testnet-in-a-box setup:

1. Create a couple of accounts:

2. Now pay for web hosting out of "cash"

3. All the information about the transaction (from and to accounts) is available, but you'll need 2 RPC calls to get it:

The GUI has no notion of a "sendfrom account", so any coins send from the GUI won't play nicely with whatever system you create using the RPC interface. The expectation is the vast majority of GUI users won't go to the trouble of creating a general ledger system to keep track of where their bitcoins are coming from and going to.

That is always a risk, which is why next to the downloads there is a gpg-signed SHASUMS.asc file.

To check the integrity of the download you should:

+ Check the signature on the SHASUMS.asc file:
+ Make sure the checksum for the downloaded file matches the checksum in the SHASUMS.asc file: