Yes, the "from" account-- I think bitlane wants the "to" account...

So you create a 'send' transaction:

... and you've associated msK1Hu7N27XTcuXd5MqWuyhW3YEGxHgVPe with the label "2_address":

listtransactions looks like this:

... because "send" transactions always report a negative amount (you're sending coins) and the account that they're being sent from.

If you want to know the account/label associated with the address that you're sending to, do this:

... or you could use the [comment]/[comment-to] params to the sendtoaddress/sendfrom/sendmany commands if you want the "to-account" to show up in listtransactions.

I think it is a waste of time to maintain so many old versions.

But it's Luke's time to waste...

Interesting.

If I understand correctly, if an address has a greater-than-average amount of currency then it will get interest.

Paid for by all the accounts with a less-than-average amount of currency.

So there's an incentive for everybody to (try to) be above the average. That seems like a recipe for a lot of disappointed people, especially since a graph of size-of-account will have a long tail with of lots of little accounts.

Making a half-thought-out-prediction, I'd say the end result would likely be one big centralized account controlled by the largest exchange with over 50% of the currency in it, because there would be a natural incentive to store your money in the biggest account so you get the most interest...

Bitcoin version 0.6.1rc2 is now available for download at:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.1/test/

This is a bug-fix and code-cleanup release, with no major new features.

NOTABLE CHANGES
===============

Much faster shutdowns. However, the blkindex.dat file is no longer
portable to different data directories by default. If you need a
portable blkindex.dat file then run with the new -detachdb=1 option
or the "Detach databases at shutdown" GUI preference.

Mac and Windows binaries are compiled against OpenSSL 1.0.1b (Linux
binaries are dynamically linked to the version of OpenSSL on the system).


CHANGE SUMMARY
==============

Use 'git shortlog --no-merges v0.6.0..' for a summary of this release.

Source codebase changes:
- Many source code cleanups and warnings fixes.  Close to building with -Wall
- Locking overhaul, and several minor locking fixes
- Several source code portability fixes, e.g. FreeBSD

JSON-RPC interface changes:
- addmultisigaddress enabled for mainnet (previously only enabled for testnet)

Network protocol changes:
- protocol version 60001
- added nonce value to "ping" message (BIP 31)
- added new "pong" message (BIP 31)

Backend storage changes:
- Less redundant database flushing, especially during initial block download
- Shutdown improvements (see above)

Qt user interface:
- minor URI handling improvements
- progressbar improvements
- error handling improvements (show message box rather than console exception,
  etc.)
- by popular request, make 4th bar of connection icon green



Thanks to everybody who contributed to this release:

Chris Moore
Dwayne C. Litzenberger
Gavin Andresen
Jeff Garzik
Luke Dashjr
Matt Corallo
Philip Kaufmann
Pieter Wuille
R E Broadley
Timothy Redaelli
Wladimir J. van der Laan
cardpuncher
freewil
graingert
sje397

Network effect.

More developers are working on Bitcoin, there are more interesting projects, more useful tools, more documentation at places like bitcoin.stackexchange.com, etc. And that all builds on itself.

Yes. And yes.

If a 51% attacker stopped including all broadcast transactions in blocks "we" would quickly figure out a rule or rules to reject their blocks.

Something like "ignore a longer chain orphaning the current best chain if the sum(priorities of transactions included in new chain) is much less than sum(priorities of transactions in the part of the current best chain that would be orphaned)" would mean a 51% attacker would have to have both lots of hashing power AND lots of old, high-priority bitcoins to keep up a transaction-denial-of-service attack. And they'd pretty quickly run out of old, high-priority bitcoins and would be forced to either include other people's transactions or have their chain rejected.

I'm tempted to code that up and run some tests on a testnet-in-a-box, but there are much higher priority things on my TODO list; I don't think a 51% attack is likely. You'd spend a lot of time and money on an attack that "we" would neuter within a day or two.

I blogged about the CoinLab deal (the post wanders off into bigger-picture economics thoughts at the end):
  http://gavinthink.blogspot.com/2012/04/coinlab-and-bitcoin.html

I have a -noprivacy patch that I use for the Faucet that accomplishes what you want, sending any change back to the funding address.

It isn't part of the core code because it doesn't play nicely with other features (accounts and listtransactions, for example). See https://github.com/gavinandresen/bitcoin-git/tree/noprivacy

There's one selling for about 2 BTC (equivalent) here: http://cheshirehorse.com/Buggy-Whip-P6374.aspx

I wonder how that compares to the inflation-adjusted buggy-whip price in 1900...

I pinky-swear on a stack of bibles I haven't heard a peep from Satoshi.

Whatever he/she/they have been busy doing, I guess he/she/they're still busy doing it. Or maybe doobadoo is Satoshi and is trying to misdirect us....

Of course fungibility is important.

But fungibility isn't all-or-nothing, and, in my humble opinion, it isn't all-important. Refusing to accept dollar bills or bitcoins that you believe were obtained illegally makes them less fungible, but so what?  It's the right thing to do.

Cross-posted from the Alternative Clients sub-forum, since it looks like the alternative client folks are more interested in adding new features than figuring out exactly how the features we already have work:

Better testing, both for the Satoshi code and across different implementations, is right at the top of my priority list. So I wrote some code to make it easier to exercise edge cases in Script evaluation:
  https://github.com/bitcoin/bitcoin/pull/1121/files

The unit tests are data-driven by two files:
 script_valid.json  contains pairs of (scriptSig,scriptPubKey) that, when used in a transaction, should evaluate to true.
 script_invalid.json  contains pairs that are invalid for some reason.

I'm looking for help to expand those to cover all the quirky edge cases that might trip up alternative "fully validating" implementations (excluding OP_CHECKSIG/OP_CHECKMULTISIG, I'm still thinking about how best to write test cases for those). If you can help, please jump in and write some more. Assuming you've got the bitcoin source tree cloned the process for adding new tests is easy:

1. Edit src/test/data/script*.json
2. From the src/ directory run:
   make -f makefile.unix test_bitcoin
3. Run the unit tests with:  ./test_bitcoin

Or if you've already got Script test cases in some other human-readable form please point me to them.

I'm planning on resetting the testnet with a new genesis block and a chain that contains all of the valid tests as spent transactions (and a checkpoint so all those nice test cases aren't overwritten).

It would be really nifty to have a 'bad chain' node running; -connect to it and it would send you otherwise-valid blocks that contained one or more of the invalid transactions from script_invalid.json. Does that sound like a project any of you would like to tackle?

I agree with Andrew. Building a website that handles money is a terrible first project.

We should have, but "we" didn't think of that in time.

I've been working on a "how to do it better next time" document:
  https://gist.github.com/2355445

Better testing, both for the Satoshi code and across different implementations, is right at the top of my priority list. So I wrote some code to make it easier to exercise edge cases in Script evaluation:
  https://github.com/bitcoin/bitcoin/pull/1121/files

The unit tests are data-driven by two files:
 script_valid.json  contains pairs of (scriptSig,scriptPubKey) that, when used in a transaction, should evaluate to true.
 script_invalid.json  contains pairs that are invalid for some reason.

I'm looking for help to expand those to cover all the quirky edge cases that might trip up alternative "fully validating" implementations (excluding OP_CHECKSIG/OP_CHECKMULTISIG, I'm still thinking about how best to write test cases for those). If you can help, please jump in and write some more. Assuming you've got the bitcoin source tree cloned the process for adding new tests is easy:

1. Edit src/test/data/script*.json
2. From the src/ directory run:
   make -f makefile.unix test_bitcoin
3. Run the unit tests with:  ./test_bitcoin

Or if you've already got Script test cases in some other human-readable form please point me to them.

I'm planning on resetting the testnet with a new genesis block and a chain that contains all of the valid tests as spent transactions (and a checkpoint so all those nice test cases aren't overwritten).

It would be really nifty to have a 'bad chain' node running; -connect to it and it would send you otherwise-valid blocks that contained one or more of the invalid transactions from script_invalid.json. Does that sound like a project any of you would like to tackle?

Good question. They're the Mint, so I bet they'll handle that the same way they handle somebody showing up at a bank with a bunch of counterfeit $100 bills: they'll ask you where you got them, and either throw you in jail (if they don't like your story) or tell you to be more careful about who you deal with and maybe direct you to some technology to help detect counterfeits in the future. But they won't let you deposit them or trade your bad money for good.

RE: $100 per-transaction, $500 balance limit:

That makes perfect sense; they probably figured out about how much it will cost to hack a MintChip to get it's private key (dissolve case in acid, put it under an electron microscope, attach electrodes at exactly the right spots, etc...). Do a little calculation involving the cost of hacking one chip, the number of times you can double-spend before you're likely to get caught and the maximum amount per transaction and I bet they figure it doesn't pay.

Especially if online transactions "phone home" to detect double-spends.  If you have to physically walk to 500 different not-online merchants to get away with $50,000 worth of double-spends that's just like counterfeiting $100 bills, and that's an attack Mints have been pretty successfully dealing with for hundreds of years.

RE: anonymity: the anonymity model is similar to Bitcoin. Each physical MintChip is like a Bitcoin keypair, if you can easily buy/load a bunch of them anonymously then it will be hard for Them to track your purchases.

If MintChip fails I bet it is not due to hacking or lack of anonymity, but just due to the inconvenience of needing Yet Another Physical Doohickey. Paper money fits nicely into the wallet I already have, I don't want Yet Another Dongle on my keychain, and I bet before the end of the year either Apple will finally approve a Bitcoin app or there will be a nifty HTML5-based web wallet I can use on my iPhone...

Or maybe you should wait 60 blocks before considering a half-a-million-dollar transaction final if you think there is any possibility of a mining cabal trying to do this.

All of this reminds me, I need to clean up my user-defined-checkpoints code for the 0.7 release, so a cabal of merchants and exchanges can get together and decide they will "lock in" an agreed-upon blockchain after 6 (or 60 or whatever) confirmations. I think that would go a long way towards infrastructure for injecting real-world knowledge about who is trustworthy into the block-chain.