Once upon a time bitcoin.org called Bitcoin "anonymous" but that was a mistake, and for at least two years "we" (core developers) have tried to be careful to say that, at best, Bitcoin is pseudanonymous.

I tell reporters that Bitcoin is more private than using any other online payment method, but less private than cash (unless you know a lot about how it works under the covers and jump through several hoops to keep your identity secret).

Where did you read that bitcoin is supposed to be anonymous?

You just poked one of my pet peeves: the Y-axis on your Euro chart doesn't start at zero, so you're exaggerating it's volatility.

No, I don't have a prototype.

The hardware is real and very cool, but they've got a lot of work to do on software and user interface and manufacturing process and marketing and distribution and.... .  Expect the design to change before you can actually buy one. And like all really innovative projects (and to quote the MythBusters) "Failure is always an option."

Answering detailed questions about exactly how it works right now would be a waste of time, because I think before it ships most of the answers will be different. The meeting in Vienna was for bitcoincard to get early feedback on whether or not they're headed in a good direction.

RE: why would you want a bitcoincard versus just using your cellphone:  I personally think you'll want both; I'm trying to convince them that the bitcoincard could be a perfect "second device" for multisignature transactions. Cell phone viruses and trojans and malware will be the next big wave of security vulnerabilities.

I've been switching back and forth between writing a spec for it ( https://gist.github.com/2839617 ), implementing it ( https://github.com/gavinandresen/bitcoin-git/tree/signrawtx ), writing up a test plan ( https://secure.bettermeans.com/projects/4180/wiki/Raw_Transaction_RPC_Test_Plan ) and testing.

My goal is to get all that done by the end of this week and have it in the 0.7 release.  But lots of things could make it take longer.

I actually created and spent some "input from wallet a", "input from wallet b" private testnet transactions earlier this week (I'm working on some lower-level RPC commands for bitcoind -- see https://gist.github.com/2839617  for the half-baked spec).

Somebody could build a transaction-combining service on top of those low-level RPC commands, although I suspect to be really resistant to sophisticated network analysis doing "one or more inputs from A in,  one or more from B in, ApayToSomebody Achange BpayToSomebodyElse Bchange out" won't help much.  There is a lot of prior work on "mix networks" and maintaining anonymity, and the only thing I know about it is that it is a hard problem to get right.

RE: the 100/120 difference:

Check my work, but I think this is the scenario where it would matter and cause headaches:

You generate a block 100 blocks before a difficulty adjustment.

Then you spend the coinbase exactly 100 blocks later, in a block in the next difficulty period. And, let's say, whoever you send the bitcoins to spends that transaction again immediately.

Now imagine a really wacky scenario where you're reorganized onto a shorter-but-has-more-difficulty block chain.  That could happen if you were disconnected from the main bitcoin network for a while.

Your coinbase-spend transaction and any transactions that depend on it can't be included in the main chain because they're immature, so they get dropped from everybody's memory pool as "trying to spend an immature coinbase."  I'm not sure what then happens; I think you'd eventually retransmit them and get them into the main chain, but that could take a while.

Yes... but having peers with a completely different block chain from you connect is a good way to shake out obscure bugs.  Like Bitcoin-Qt's "how many blocks are in the valid chain" code getting fooled...

Bitcoin-Qt ?  Sounds like a bug in the "estimate how many blocks there are based on what your peers tell you" bug.

Signatures are BER-encoded data structures, and can be an arbitrary number of bytes (if they're DER-encoded, which is the strict subset of BER encoding, then they're 70-something bytes).

Public keys are either 33 or 65 bytes (not counting the "push the next N bytes onto the stack" CSCript opcode).

I've got to say you make me nervous; you seem to be following a "make it work for a couple of test cases then move on" style of development, which is a bad way to create a secure, robust codebase.

PS: I sympathize with you RE: OpenSSL's lack of documentation....

I just got stuck-- looks like somebody is serving up the testnet2 blockchain to testnet3 nodes that connect to them (that's what is causing the 'nBits below minimum work' message).

Re-running to connect to a real testnet3 node is getting me the correct blockchain (with 6,905 blocks).

I think consolidating everything under one domain is dangerous and against the decentralized nature of the Bitcoin project.

I'd love to see somebody resurrect the Visual C++ makefile and build instructions (and let us know if we've accidentally added and gcc-specific code), so Windows developers didn't have to spin up a VM and cross-compile everything.

As to why your builds are different:  no idea, but you can look at the file-by-file checksums in the bitcoin-build.assert file to see exactly what is different.

I should lie and say I'm feeling extra generous to miners this morning and wanted to give them an imaginary 50 BTC fee...

How would you use a 'getaddressbalance'?  What are you trying to do?

Start with an empty wallet.  I send you 100 BTC to address 'foo'. Then you send somebody else 1 BTC.

Internally, a new change address with 49 (edit: 99) bitcoins is created, so getaddressbalance 'foo' would return zero. Would that ever be the right answer?

I love you guys, and hope you're being wildly successful... but:

Plugging in "Deposit $200, get $192" for a cash deposit and then finding out I'll actually have to bring $204.95 or $201.58 because of an extra third-party processing fee feels like bait-and-switch to me. Don't you know in advance how much the payment processors will charge?  Does it vary based on location or something?

Ummm....

When you run something like: 
... bitcoind creates a network connection to localhost:rpcport and talks to the running bitcoind process via the JSON-RPC protocol.

So it doesn't matter what user the process is running as, what matters is securing access to the JSON-RPC network port, keeping the rpcpassword a secret, and preventing attackers from getting in and copying wallet.dat.

Once.

(it is actually once every couple of months, but that's a secret and might change so don't tell anybody that)

Sipa has been busy implementing IPv6 support and much better support for running bitcoin as a Tor hidden service. Both of those should help make the network more robust and resistant to attack. If a lot of people decide to run only inside Tor then it will look like even fewer nodes are listening, though.

Use one of the send commands to send to the multisig address several times and you will create several multisig transactions.

addmultisigaddress does not create a transaction, it just creates a place for future transactions to go.