NEW FEATURES SINCE BITCOIN VERSION 0.5--------------------------------------Bitcoin-Qt can display and save QR codes for sendingand receiving addresses.

New context menu on addresses to copy/edit/delete them.

New Sign Message dialog that allows you to prove that youown a bitcoin address by creating a digitalsignature.

Wallets created with this version of bitcoin willuse 33-byte 'compressed' public keys instead of65-byte public keys, resulting in smallertransactions and less traffic on the bitcoinnetwork. The shorter keys are completelycompatible with older versions.

New command-line argument -blocknotify=<command>that will spawn a shell process to run <command>when a new block is accepted.

validateaddress JSON-RPC api command output includestwo new fields for addresses in the wallet: pubkey : hexadecimal public key iscompressed : true if pubkey is a short 33-byte key

New JSON-RPC api commands for dumping/importingprivate keys from the wallet (dumprivkey, importprivkey).

The -nolisten, -noupnp and -nodnsseed command-lineoptions were renamed to -listen, -upnp and -dnsseed,with a default value of 1. The old names are stillsupported for compatibility (so specifying -nolistenis automatically interpreted as -listen=0; everyboolean argument can now be specified as either-foo or -nofoo).

The -noirc command-line options was renamed to-irc, with a default value of 0. Run -irc=1 toget the old behavior.

PRELIMINARY SUPPORT FOR MULTISIGNATURE TRANSACTIONS---------------------------------------------------

This release has preliminary support for multisignaturetransactions-- transactions that require authorizationfrom more than one person or device before theywill be accepted by the bitcoin network.

Prior to this release, multisignature transactionswere considered 'non-standard' and were ignored;with this release multisignature transactions areconsidered standard and will start to be relayedand accepted into blocks.

It is expected that future releases of Bitcoin-Qtwill support the creation of multisignature transactions,once enough of the network has upgraded so relayingand validating them is robust.

For this release, creation and testing of multisignaturetransactions is limited to the bitcoin test network usingthe "addmultisigaddress" JSON-RPC api call.

Short multisignature address support is included in thisrelease, as specified in BIP 16. Run with -bip16=0 toturn off support for BIP 16.

How often do you get the chance to work on a potentially world-changing project?

NEW FEATURES SINCE BITCOIN VERSION 0.5--------------------------------------Bitcoin-Qt can display and save QR codes for sendingand receiving addresses.

New context menu on addresses to copy/edit/delete them.

New Sign Message dialog that allows you to prove that youown a bitcoin address by creating a digitalsignature.

Wallets created with this version of bitcoin willuse 33-byte 'compressed' public keys instead of65-byte public keys, resulting in smallertransactions and less traffic on the bitcoinnetwork. The shorter keys are completelycompatible with older versions.

While I have only the vaguest of understanding of EC cryptography, the "compressed public keys" bullet point there looks… interesting. I tried searching the boards and didn't see anything other than this post, so I guess I'm asking here:

• Is there discussion of this elsewhere that you could point me to?• Does this form a new type of address/public/private-key pairing in the wallet.dat?• How far is this "complete compatibility" with older versions? Can I move a wallet.dat from this new release that's created these new keys to an older release and have it still work?• Has testing so far included sending transactions between old and new versions, and between old wallets that have been upgraded to the new version, and probably more permutations on things like that?

Or are these the kinds of things that are being asked to test thoroughly? Is there a test plan of some sort, or should we just be doing whatever we can think of on testnet to see what happens?

so far all seems good.signing a message with a key is nice, now we need an easy way to verify a message with an address aswell... signing only works if the signature can be interpreted by somebody i think

Gavin, will Btcoin-QT support plain M-Of-N transactions and P2SH transactions or will it be etiher-or?

I don't know, the GUI for multisignature transactions hasn't been designed yet. But I imagine it will be simpler to always produce P2SH transactions, just as the client always produces OP_HASH160 transactions and has no option to produce plain OP_CHECKSIG transactions.

I assume that both forms will be supported for multisig payments into your wallet (but detailed discussion on how to support multisig in the GUI should happen somewhere other than this thread).

How often do you get the chance to work on a potentially world-changing project?

While I have only the vaguest of understanding of EC cryptography, the "compressed public keys" bullet point there looks… interesting. I tried searching the boards and didn't see anything other than this post, so I guess I'm asking here:

• Does this form a new type of address/public/private-key pairing in the wallet.dat?

Yes and no. The same private key now corresponds to two different pubkey/address pairs. Which one is used is determined at generation time. Since the wallet stores both pubkey and private key, the length of the pubkey is used to determined which pair is intended.

Quote

• How far is this "complete compatibility" with older versions? Can I move a wallet.dat from this new release that's created these new keys to an older release and have it still work?

Good point. It will probably work, but the compressed pubkeys will be considered non-compressed ones by older versions, so they will probably miss transactions. Over time, the ledger seen by older clients and newer clients may diverge. I'll try to fix this before 0.6.0 final is released.

Quote

• Has testing so far included sending transactions between old and new versions, and between old wallets that have been upgraded to the new version, and probably more permutations on things like that?

Sending from and to old and new addresses has been tested, and between old and new clients. As mentioned, I didn't test downgrading.

Quote

Or are these the kinds of things that are being asked to test thoroughly? Is there a test plan of some sort, or should we just be doing whatever we can think of on testnet to see what happens?

I tried out Bitcoin-QT 0.6 RC1 but had to go back to 0.5.2 after Bitcoin-QT was using 98% CPU.It wasn't doing anything, not downloading a block, not sending a TX. After switching back to 0.5.2, CPU usage is back to normal.