If you receive income in any form, and your income-translated-into-dollars is above whatever the "must file" amount currently is, then yes, you must report it on your income taxes at the end of the year.

Doesn't matter if your income is in the form of dollars or euros or bitcoins or diamonds.

And I'm pretty sure Fincen would say that if you're receiving more than $10,000 worth of bitcoins from somebody then they want to know about it, just like they want to know if you're getting more than $10,000 worth of diamonds from somebody.  See the fincen.gov for the mind-numbing details.

It should be pretty easy to use the raw transactions API to implement a "send all".

You would do:
  listunspent --> list of inputs
  Then estimate a reasonable fee (this is the hardest bit, but listunspent tells you amount and #confirmations and you can estimate tx size based on number of inputs)
  createrawtransaction/signrawtransaction/sendrawtransaction

Somebody should write a little python tool we can ship in contrib/

Bitcoin version 0.7.1 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.1/

This is a bug-fix minor release.

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues

Project source code is hosted at github; you can get
source-only tarballs/zipballs directly from there:
  https://github.com/bitcoin/bitcoin/tarball/v0.7.1  # .tar.gz
  https://github.com/bitcoin/bitcoin/zipball/v0.7.1  # .zip

Ubuntu Linux users can use the "Personal Package Archive" (PPA)
maintained by Matt Corallo to automatically keep
up-to-date.  Just type:
  sudo apt-add-repository ppa:bitcoin/bitcoin
  sudo apt-get update
in your terminal, then install the bitcoin-qt package:
  sudo apt-get install bitcoin-qt

KNOWN ISSUES
------------

Mac OSX 10.5 is no longer supported.

How to Upgrade
--------------

If you are running an older version, shut it down. Wait
until it has completely shut down (which might take a few minutes for older
versions), then run the installer (on Windows) or just copy over
/Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

If you were running on Linux with a version that might have been compiled
with a different version of Berkeley DB (for example, if you were using an
Ubuntu PPA version), then run the old version again with the -detachdb
argument and shut it down; if you do not, then the new version will not
be able to read the database files and will exit with an error.

Explanation of -detachdb (and the new "stop true" RPC command):
The Berkeley DB database library stores data in both ".dat" and
"log" files, so the database is always in a consistent state,
even in case of power failure or other sudden shutdown. The
format of the ".dat" files is portable between different
versions of Berkeley DB, but the "log" files are not-- even minor
version differences may have incompatible "log" files. The
-detachdb option moves any pending changes from the "log" files
to the "blkindex.dat" file for maximum compatibility, but makes
shutdown much slower. Note that the "wallet.dat" file is always
detached, and versions prior to 0.6.0 detached all databases
at shutdown.

New features
------------

* Added a boolean argument to the RPC 'stop' command, if true sets
  -detachdb to create standalone database .dat files before shutting down.

* -salvagewallet command-line option, which moves any existing wallet.dat
  to wallet.{timestamp}.dat and then attempts to salvage public/private
  keys and master encryption keys (if the wallet is encrypted) into
  a new wallet.dat. This should only be used if your wallet becomes
  corrupted, and is not intended to replace regular wallet backups.

* Import $DataDir/bootstrap.dat automatically, if it exists.

Dependency changes
------------------

* Qt 4.8.2 for Windows builds

* openssl 1.0.1c

Bug fixes
---------

* Clicking on a bitcoin: URI on Windows should now launch Bitcoin-Qt properly.

* When running -testnet, use RPC port 18332 by default.

* Better detection and handling of corrupt wallet.dat and blkindex.dat files.
  Previous versions would crash with a DB_RUNRECOVERY exception, this
  version detects most problems and tells you how to recover if it
  cannot recover itself.

* Fixed an uninitialized variable bug that could cause transactions to
  be reported out of order.

* Fixed a bug that could cause occasional crashes on exit.

* Warn the user that they need to create fresh wallet backups after they
  encrypt their wallet.

----------------------------------------------------
Thanks to everybody who contributed to this release:

Gavin Andresen
Jeff Garzik
Luke Dashjr
Mark Friedenbach
Matt Corallo
Philip Kaufmann
Pieter Wuille
Rune K. Svendsen
Virgil Dupras
Wladimir J. van der Laan
fanquake
kjj2
xanatos

It is MIT licensed, anybody can mirror it anywhere they like. You don't need anybody's permission, just do it!

You don't need the whole network to support transaction replacement to do that; just write some code that holds a time-locked transaction, has a way of replacing it with another time-locked transaction, and have it automatically broadcast the transaction onto the network if not replaced before the time-lock expires.

It would be more convenient to have the whole network support transaction replacement, but I don't think it is reasonable for the whole network to remember everybody's dead-man-switch transactions. And even if they did, you'd run the risk that a miner eager to get an extra transaction fee would ignore a newer version of the transaction and mine the old transaction.

RE: do I have gazillions of bitcoins:

I've said before that I have "thousands of bitcoins, not tens or hundreds of thousands of bitcoins." I have mined a grand total of 250 bitcoins-- electricity here is not particularly cheap, and I'm a software kind of guy, not a hardware hacker. So it always made more sense for me to buy bitcoins rather than mining them.

I would definitely be wealthier right now if I had been working as the CTO for a company for the last two years and had never heard of Bitcoin.

RE: what work will I do:

I will continue doing what I've been doing-- trying to focus on work that benefits all of Bitcoin and not one particular company. That is the kind of work that falls through the cracks-- why would one company pay for cross-implementation compatibility tests? Sure cross-implementation compatibility is really important for the stability of the Bitcoin network, but as long as the implementation THEY'RE using works properly then why would they spend extra to make life easier for other implementations?

Or a company might fund the development of anti-denial-of-service techniques, but once they do, why would they want to share that with their competitors? Being more denial-of-service-resistant might give them a competitive advantage...

TruCoin paid me a salary for a couple of months last year to do core development work (and paid Alex Waters to start doing Q/A for core development), but TruCoin ran into funding problems of their own and stopped paying us to concentrate on their own projects.

Creating a Foundation is a proven, well-established way for projects to solve the free-rider problem of funding core development that benefits everybody. Over time, I hope to be working less on the reference implementation and more on "Chief Scientist" stuff, like organizing working groups to write best practices documents or work out agreements on changes that might be necessary to the core protocol to support more transactions, better privacy, advances in quantum computing, hiring or recruiting experts to do security reviews of proposed new stuff, etc.

RE: voting:

Great ideas! I think I'll be pushing to start with a good old-fashioned "send you a letter with a PIN number to your mailing address" as the first step to preventing voter fraud. We'll have to have a much more extensive discussion of voting procedures before it is time to vote.  I'll probably push to follow the lead of other successful organizations, and to do the Simplest Possible Thing That Will Work-- which might be hiring a disinterested high-reputation company who specializes in running elections for organizations.

Nice! You should submit a pull request to put a version of this in the contrib/ directory; my only suggestion would be to make it take a version string as an argument (and maybe automatically look in the test/ subdirectory if it contains 'rc').

Right, and we don't accept "change the world" pull requests because the risks of introducing a catastrophic bug outweigh the benefits, and rewriting everything invalidates all of the careful code review that's been done over the past few years.

However, we ARE moving towards better architecture as different parts of the code get worked on to support new features or improve scalability or fix bugs.  For an example of inversion-of-control done right, look for use of boost signals and slots; for example:

If I recall correctly, mybitcoin.com users got 49% of their coins back (I was one of the stupid people who trusted some bitcoins to them, by the way).

Not yet. There is a pull request implementing bloom filters that should make that easy to implement.
No. The reference implementation doesn't keep a master map of all addresses to unspent transaction outputs, and adding such an index for the small number of services that need to look up arbitrary addresses doesn't make sense.

I'd suggest you -blocknotify and the getblock() RPC call to maintain your own index of address --> unspent txout.

I slapped one up you can try:  http://skypaint.com/bitcoin/fauceturi.html

I think typing bitcoin:1.....?label=... etc  into the browser address bar should work for testing, too.

This will be a WONTFIX, unless somebody steps up to continue supporting OSX 10.5.

I'll put a big note in the release notes that we're dropping OSX 10.5 support.

There's no such thing as 'official.'

I think the best term is "reference client."

Huh?  There were none.  The blockchain bootstraps itself from the genesis block and peers on the network.

Bitcoin version 0.7.1 release candidate 1 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.1/test/

This is a bug-fix minor release.

New features
------------

* Added a boolean argument to the RPC 'stop' command, if true sets
  -detachdb to create standalone database .dat files before shutting down.

* -salvagewallet command-line option, which moves any existing wallet.dat
  to wallet.{timestamp}.dat and then attempts to salvage public/private
  keys and master encryption keys (if the wallet is encrypted) into
  a new wallet.dat. This should only be used if your wallet becomes
  corrupted, and is not intended to replace regular wallet backups.

* Import $DataDir/bootstrap.dat automatically, if it exists.

Dependency changes
------------------

* Qt 4.8.2 for Windows builds

* openssl 1.0.1c

Bug fixes
---------

* Clicking on a bitcoin: URI on Windows should now launch Bitcoin-Qt properly.

* When running -testnet, use RPC port 18332 by default.

* Better detection and handling of corrupt wallet.dat and blkindex.dat files.
  Previous versions would crash with a DB_RUNRECOVERY exception, this
  version detects most problems and tells you how to recover if it
  cannot recover itself.

* Fixed an uninitialized variable bug that could cause transactions to
  be reported out of order.

* Fixed a bug that could cause occasional crashes on exit.

* Warn the user that they need to create fresh wallet backups after they
  encrypt their wallet.

... so transfer 1,000 headers with different extranonces in one handshake.  Or don't handshake every time. Or modify the firmware that speaks whatever mining protocol you're sending at it to do the increment-extranonce-and-recompute-the-merkle-root-thing itself.

All of this discussion is useless; even if you could convince us core developers that we need A HARD FORK RIGHT THIS VERY MINUTE! there is absolutely zero chance we could make that happen before the ASICS start shipping.

So: plan accordingly.

Actually, there is a small incentive to forward transactions:

If you mine a block that contains a lot of transactions that have never been broadcast on the network, it will take your peers longer to verify that the signatures in the block are valid.*

So it takes your block longer to propagate through the network, which makes it slightly more likely to lose a block race.

---

* A couple of releases ago I implemented a signature cache, so if a node sees a transaction broadcast it doesn't have to re-check it when that transaction is part of a block.

I'll outsource my thoughts:
  http://skeptoid.com/episodes/4176

I really and truly hope you're, right, MPOE.

But I would give 4-to-1 odds that the US justice system will disagree, and my advice to anybody thinking of raising funds via an unregulated IPO would be "don't do it unless you want to do it as a protest against our broken system and are willing to face the likely consequences."

I'll cheer you from the sidelines, but I'm either not stupid enough or not brave enough to go up against the SEC.

+1

I still hope the Bitcoin world will be boring in 4 or 5 years, but I expect lots more chaos and drama until at least then. This is what innovation looks like-- lots of failures and a few spectacular successes.

It is still WAY too early to tell what will be successful long-term.