NO, he is NOT still on IRC giving them away. -.-

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The cracker who stole 18kBTC from Bitcoinica was on IRC this morning giving them away. A number of us posted our addresses with the intent of returning the stolen coins to Bitcoinica. I have setup an address that will be handed over to Bitcoinica (as a wallet.dat file) at some point when they have figured out where I should send it. Therefore, if you have been sent any stolen coins and wish to return them, please forward them on to 1BPKHoL1sAVnfzxnH38RfXYYcHrEcniUKW (see balance).

Note that with Bitcoin-Qt, you will generally not be able to control which coins you are sending. Since a lot of people got the coins in their main wallet, I have backported coderrr's Coin Control to Bitcoin-Qt 0.6.2.

Windows: installer or zip
Source: tar.gz

e3d2ec5694f26eb5f45ea6244aa1c2792ac3e7c87113e0dfae827469eaf31499  bitcoin-0.6.2+coincontrol-win32-setup.exe
a3a067273027232ef009c20a4e0e91410cd59820d7c80c89a45780ad3ba23426  bitcoin-0.6.2+coincontrol-win32.zip
42d04be61b340a17bf8ee8607079c90ddb067300cf1fbb041744c5e162f0bc1a  bitcoin-0.6.2+coincontrol.tar.gz

If someone could post exact instructions on how to use Coin Control for this purpose, I'm sure it would be appreciated!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQQcBAEBCAAGBQJPuJzeAAoJEL0ClCQh9IifQJcf/0JV0HwtMuyBouLBbhBBMALd
SZEQZGyWlWS7bg1eIXUcC+RuwD+MLRRAPKIvhQ+iFf7L9nO/kFzSyHP7Z9DAfVFM
5QU1eJhgSydYfxM6rnbzhxKq4Zeov5OhoAg3YuUZJmN+b/YSMmtTQ7XxcMRdkfod
I+K1pgI8Tl1+IdLMa8i6ZG4KbBmUYkhnRMvPP0wTKUcQvRzpLXTERb9KY/+1ZfVs
vyJqj9ghWUzgK1OuOUpOGsJ+QjJ1GkhFWLAmH6QuLewA4pgp1QKVKEzYbKxUjyd/
0ioFSVecrRO+XayMp5AGkEflocu5w4W0SPhFSRgWEuv+uqhpHGYpF65O5SLvYZIc
QChtbPkUHypAnkCeIyZPftwTFc38dw9UKARPlDbznST9dBpnrnxPFrL2ylrJUuDe
gg5fWP6AnTD05le7/OA4xIVtq+OYCA+kLjHM7tnWjSZF7l5/pUeYH90lOuJRbDEe
fme7HQ/kzKy7RaTdCroYKQFl/WBvRBb+aoLsF3cHZ39DJ2R7gdDvInlzkkXdu89q
Ppav1JFIPiZPgD+vg1g+F320m3bOzrdfGBn1QUqXJzE3W/JJ1T8U7E+fGDvcOLW6
kXdcL3jeWfNU4NX80i/4xKUr5ii2DWe2b5H7L5jqydaySsmgmStmHnkAyDiAnKu5
aQwwzQ+u+xGOElunEEkhG4XAJ2Jcm/A52Y99RCRuMXjfNxLftGBg42o3WeC34jY2
r1eqaXo2fgPHuuVxo95NGeuvu3O9n9graG5ZYCD4mS9Vf+GX8alkJCHgda56TjEF
kNHOjGAICZ1hLSk8ej9noetwqaxlc6dHWCP5sImCn7fkPxl0RUR+r/smWPK7hAOI
bfL5bRQxTQULXGaC26qw8YkMHPrVZaQs+qS9M9ztwmG7/EPC4E0NVTNEwvnHqQih
QP7hnfNN6EBDVKDvyXkW7Ja0Vk6V2R2zOPthO7ccbo863iPRFctYdqmwr7RP8OFc
Umb2+EOzqItXJMRdpdzNudjphlRxYL3rXQUX7MsLPwpar/VysqlDdbqWC+PT3ht3
ECKE3IKfbDnidfF0QSm1U+BbpnDogcFzxd0v+w4YI6PJvAZeWbMT5G1pFfltYTdc
f1ppIANVk/8a5GSTa7PXh/Dpv3TdT+nzD+W1AsmTAmVhw9sS9yYflFLLF6C8foNk
iwStTP+9bXUdNFIdQRVb/MVFf085r9jNrbw5x9OpuhZEa/AAqhJaEsXooK0Yd10X
jMfqKIlxq+/PKoZNLQLBWF4vOMOKOcQYAcSLbp8HO1qDKPbeS5wAgZtEsJ00gspr
TsfvyAodFO6i44U6Epq73edpxMJMx27JURaqkkk236FSSk8frmCcqkD3qGREnnE=
=zZ1y
-----END PGP SIGNATURE-----

---

NOTE: This build seems to be unusable. Previous next-test is still available.

---

next-test is a branch of the mainline bitcoind & Bitcoin-Qt with as many pull requests merged as possible, to aid in testing them. This branch can be used to test many pull requests in your daily Bitcoin use. The goal is to help pull requests get the testing they need to be merged into the main tree, so once you test a change, please comment in the relevant pull request (ideally with details).

Please note these might possibly corrupt your wallet. No warranty of any kind of provided. BACKUP YOUR WALLET

• Windows: installer ‖ zip (sigs)
• Source code: git ‖ tar.gz ‖ zip

Today's next-test includes the following pull requests (green are merged now; red are disputed):

• Typo-tolerant (optimized) Base58 parser
• Parse URIs with non-BTC amounts
• -acceptnonstdtxn option to skip "non-standard transaction" checks
• Optimized binary-to-hex converter (ToHex)
• FastGetWork optimization
• Specify fees explicitly via JSON-RPC
• Reopen log file on SIGHUP
• Support for Tonal Bitcoin units (ᵇTBC, ˢTBC, and TBC)
• Bugfix: BIP22: getmemorypool
• New -minfee and -minfeeper options (with JSON-RPC setminfee to change at runtime) to control minimum fee requirements for transaction inclusion in blocks mined
• URI-handling code update - safety check and notification
• massive URI-handling / IPC server re-work
• Relay and accept transactions that personally benefit the user
• Trim trailing whitespace in src/*.{cpp,h}
• Tor hidden service support
• Fine-grained UI updates
• Refactor CreateNewBlock transaction selection algorithm
• Bugfix: getwork/getmemorypool: NULL pindexPrev across CreateNewBlock, in case it fails
• CreateNewBlock: Check that the produced CBlock is acceptable
• Issue1234
• change strings to Bitcoin (uppercase), where it is used as a noun and up...
• Encapsulate BDB environment inside new CDBEnv class
• make CheckDiskSpace() use 50 * 1024 * 1024 Bytes
• Signbugs
• Reorganize(): remove spurious TxnAbort()
• Get rid of snprintf (except one) with fixed buffers, shorten code
• Split BDB database blkindex.dat into multiple databases
• Show block timestamp
• Add -proxytoo option, which allows proxy use non-exclusively, unlike the -proxy option.
• translation updates / string updates
• Filter out whitespace and zero-width non-breaking spaces in address field validator
• Who doctored.... never was very useful, now only for the debuggers...
• Should not be T minus, as this indicate duration to future event.
• Unless debugging, show a more useful format for the askfors
• mapAlreadyAskedFor gets additions when AlreadyHave()
• Clarify license for debugwindow icon
• ECDSA signature optimization and more DoS prevention
• Win32: use _strnicmp (ISO C++) instead of deprecated strnicmp (POSIX) - V2
• GUI: add an icon for Debug logfile -> Open in the RPC console
• Update Header Licenses
• getmemorypool: longpolling support
• Shared code for wallet lock help and check
• Coin Control / less change / refactor coin selection

Bugs found:

• Deadlocking risk from debugging signals
• Finer-grained UI updates breaks test suite
• Splitting up database breaks Bitcoin-Qt
• "Quieter" initial block download doesn't build
• Finer-grained UI updates conflicts with Windows over MF_HELP constant name
• Splitting up database crashes after database upgrade

IPv6 had some major changes between this next-test and being merged into master. Please test the new next-test due out sometime soon and see if it works for you.

Should be fine, though I'd advise against posting it publicly, just in case some attacker is googling for vulnerable services.

Can you confirm whether IPv6 is enabled or not?

Should be in the getinfo "errors" key. It uses a hardcoded private key to relay across the p2p network.

It doesn't wrap native here. I use a Qt-based system.

Probably. Does wx have a consistent look? I thought it just wrapped GTK+ :p
As for function, it should be possible, though probably a lot of work.

Qt doesn't have "looks"; Qt applications just adopt the appearance of your OS, whatever that may be (at least by default; I understand there's some way to "skin" Qt applications...).

Yes, wxBitcoin and bitcoind 0.4 share(d) the same codebase, and bitcoind 0.4.x is still built with wxBitcoin to avoid breaking anything subtle. But nobody is looking out for or fixing GUI-specific issues, for example. Ideally, someone would bring it up to speed with a port to the 0.6.x codebase too (which I could then just backport fixes from).

Maybe, but it'd need to be someone else doing it - I really hate wx

wxBitcoin is for all "official" purposes unmaintained and dead. I only support bitcoind 0.4.x, not wxBitcoin. If you want to resurrect it, I'm happy to help, but there will need to be at least one real developer who cares about it...

Getting stuff on SourceForge requires being able to compile with gitian, not much more. That requires Ubuntu right now. If you can help with this, ping me in #Bitcoin-Dev (IRC) and I'll try to help you through it.

I can't speak for why Gavin signed the message with his "CODE SIGNING KEY" rather than his normal one, but at least I can confirm that this key is 4096-bit (his normal one is only 1024-bit) and signed by the normal one. It's also the one he uses to sign all his release builds.

It's not relevant. The signature was removed when he edited the post to correct the stable version numbers (he had 1 higher than the correct versions), and he resigned the corrected message later.

I know for the 2 cases I've heard of this crash, it turned out to be a rare case where the wrong password was being accepted erroneously, which then led to a crash. So for every good password, there were maybe 0.4% of all wrong passwords that crashed instead of giving an error. Reconsider whether you actually have the right password.

SourceForge uploads require 3 independent people to build the same binaries to verify their integrity. Want to volunteer to help out with 0.4.x? :p

We have exactly zero free software or non-Windows BFL firmware upgraders. Despite BFL's claim, I was unable to get my Singles recognized by a Windows VM no matter how I passed the device through. When/if someone else* documents the protocol (I hear their EXE is easily decompiled), I plan to write a free firmware upgrade tool. In most countries, this process would be perfectly legal (yay clean-room reverse engineering), so it's just a matter of time.

(since I intend to write such a tool, I cannot myself look at or decompile BFL's code without tainting the "clean" status of my code)

Note: This is not vulnerable to CVE-2012-2459

FWIW, the network is now 5% secure against CVE-2012-2459.

The latest next-test is secure.