Does this virus send bitcoins to an address or just upload the entire wallet to an email address or what? There are probably a bunch of variations out in the wild, but is there ONE address worth looking at in the block chain? url?

From the help menu, this looks exactly like what I've been looking for. Maybe there's a better name, such as coinmanager - it looks like it splits AND merges (and generates). I'm reading coinsplit.c now. I've gotten paranoid in my old coin age!

Great job getting a new version out. I've run it on multiple machines and it works well and feels 'snappier'. Am I seeing all the addresses in the wallet (even those unused 'hidden' addresses) - not sure, but if so, cool. Looking forward to wallet merge/split and encryption! I was hoping that some of my 'missing' bitcoins would magically appear. I'll just have to wait for the another version.

Because before Julius and Augustus, people couldn't count?

Sept=7=ember
Oct=8=ober
Nov=9=ember
Dec=10=ember

Silver parity before September. And gold parity early 2012.

Not enough options. End of June or.... September? What about the months inserted by caesars Julius and Augustus?

My vote is $100 on 15 July at 8.

If it had some ticks and numbers on the axices, this could be very useful.

The Linux 0.3.21 binaries do indeed come with pre-compiled bitcoin and bitcoind.

Lulzplzkthx, answer=(false==answer); variable 'answer' not defined nor recursive. Clever and twisted though.

I wonder if "Your receiving address" bar is necessary. I suppose it is supposed to encourages the use of a new address with every transaction, but I would guess most people do not do that (consider how many people have a bitcoin address in their forum signature). In fact, the 'address bar' gave me the impression that the initial address was my ONLY address and I became very confused when it changed. I thought I lost my recently received coins!

Perhaps replacing the address bar with a [New receiving address] button would be sufficient. Of course, a tab listing all addresses (used and 'hidden') would also help demystify the addresses hidden in the keypool.

I think the advantages of base58 (unambigous 1lLiI for humans) is lost in a QR encoded message. Base93 (x21-x7E) is more data dense. Base10 (decimal) is almost as dense due to the four encoding types (numeric, alpha, pseudo-binary, and kanji). Data Matrix (as opposed to QR) has the advantage of a true binary format.

A similar take on the signing check idea, is to symmetrically encrypt the private key before encoding in QR/Data matrix. Then writing the password on the check 'signs' it. Of course the paper money isn't transferable before 'password signing'.

That is correct. And the backed up 'vault' idea is also correct. But we are not all hoarding money. I assume you have a bank account right? You deposit money and you EXTRACT money to pay bills. When you die, the account can be liquidated.

Most people are not so fortunate that they can dump money in one direction entirely (never dipping into those funds ever again) for the benefit of their estate. At some point, most people will need to use the money (that is not STORED, but) BACKED UP on the bottom of the ocean.

BitCoin presents no good analogy to the current system. I can backup money (vault) while still having access to money (copy). I am only advocating that a backup actually be a reliable backup. Anonymity through obfuscation is not the only use case. Control is another.

Are you referring to this?: http://www.google.com/trends/viz?q=bitcoin&date=ytd&graph=weekly_img

That is correct. It still sets a precedent of false expectations. First of all, aside from geeks who read the source code, the majority of users will assume that 'change' is returned to the same address. In fact, most users will not understand the distinction between addresses and wallets, particularly because the client does not present the pool of addresses or the balances per address. As soon as a user learns "phew! I can just restore from backup", they will similarly assume they can ALWAYS restore from the same backup.

In fact, that is precisely what should be DESIRED. I should be able to store a physical offline backup of my addresses in a sealed container at the bottom of the ocean. I should be able to give a sealed copy of the keys to my lawyer to be opened by my next of kin upon my death, which I hope will be a hundred years from now.

Let's not focus entirely on anonymity and encryption, while making it very difficult to hold on to our money. A cycle of 100 static RECYCLED keys is probably good enough for most casual users. Let the paranoid pre-generate a billion keys, but then keep it STATIC until the end of time. Or just use one address per wallet and let the paranoid launder their money using a predictable process.

Looks like a domain squatter: http://bit.co.in/

I put all my keys in a git repository. Except for the fear that the 'authorities' are gonna knock on my door later in the decade, I'm far more afraid to delete keys than feel the need to obfuscate them. I'm considering sending a CD to my brother and next of kin with keys and instructions. I assume more BitCoins have and will be lost rather than stolen.

Hey Gavin, You suggest we 'just jump in an take a bug', but some of the 'issues' conflict and require vision.

Take the wallet. I personally think it must be plaintext, which would solve all of the split/merge requests, simplify backup, etc. Each address/key pair could be individually encrypted in a radix64 block if that is desired. Others of course seem to strongly disagree (seems to conflict with generic key store importation, performance, and other 'issues').

Maybe someone (you?) needs to mark issues as ready-to-go, while others deserve to be thought-through. Otherwise, some hacker might jump in and plaintext the wallet and divide the datadir by public (block chain), private (wallet, addr), and clutter (logs).

> There was talk a while ago about building up a sizeable list of addresses
> in the wallet that would be hidden but used for change for future
> transactions.  The benefit there is that if a user backs up his wallet and
> something like this happens after future transactions, his old backup
> will still "contain" all of the bitcoins since it actually has the addresses
> that change coins were sent to.
>
> What ever happened to that idea?  I think it's a good one.

Since this post a year ago, this feature has been implemented as keypools=100. Personally, I think it is a bad idea and does not address the problem, only pushes it off to the 101st address. At that point, users will come to expect certain backup behavior and then one day (presumably when they have more 'real' rather than 'play' money) it doesn't work as expected.

Unless the pool is recycled (change is returned to a random or cycle of addresses) then this is far more dangerous.

I propose, instead, what is expected. The change should be returned to the same address that the BitCoins were sent from.

I understand this decreases deniability/anonymity. But if someone really is paranoid, they should really be laundering money through multiple addresses in random amounts at random intervals. Sending change to a new address is just an obvious 'paper trail' considering all transactions are public, it doesn't take genius investigator to follow the money.

I've been playing around switching between wallets in my .bitcoin directory. Three files (wallet.dat, addr.dat, and blkindex.dat are tied to single wallet or need to be rescanned/deleted between wallet swaps). The blk0001.dat file expands linearly with every swap with seemingly no shared/resusable data (which is evident by my now 600 MB blk0001.dat file.

I'm going to assume the lack of block data sharing is a bug or an oversight, but as of bitcoin-0.3.21, a "reusable wallet" consists of nearly the entire datadir (.bitcoin).

I would have assumed the old block chain (from genesis to yesterday) would be static.

Ideally there would be a [database] directory containing the 'static' historical block chain, a [limbo] directory for the not-yet confirmed recent block chain, a [wallet] directory with my addresses, keys, and anything identifying/personal, and finally a [log] directory that can be safely deleted.

And the more files are plaintext, the better. The bottleneck is the network graph and connections, not local file handling. Let the miners optimize, the general user needs to understand and the power to modify.

Considering this is an international endeavor to create an alternate (if not disruptive) economic system, why not abandon loaded words that don't translate across borders, even while using the same language. Fiscal conservative, classical liberal, libertarian, progressive liberal. It makes the mind spin.

con·ser·va·tive  (adj.) 1. Favoring traditional views and values; tending to oppose change. 2. Traditional or restrained in style. 3. Moderate; cautious: a conservative estimate.

lib·er·al  adj. 1. Not limited to or by established, traditional, orthodox, or authoritarian attitudes, views, or dogmas; free from bigotry. 2. Favoring proposals for reform, open to new ideas for progress, and tolerant of the ideas and behavior of others; broad-minded.

Clearly none of these words appropriately describes this group (opposing change while free from bigotry). Why not predictablism, decentralism, In People We Trust.