You did compile (everything?) using the /clr option?

If you are talking about any dictionary word (or English first name and many company names) that are less than 7 characters then yes.

Somebody put 1 satoshi into each of thousands of such names over a year ago (start with 1google and click on the two tx's to get an idea).

Another possible approach that would allow for transfer of ownership would be to have one of several "special" firstbit vanity addresses (with each being able to be considered as a "domain registrar") used to send a tx that can be used to identify the current owner.

With this approach it would be the last tx that identifies the current owner and an owner could sell their "domain" (in a way that can be publicly verifiable) by having the coins first sent to the registrar by the "buyer" which will be confirmed by another small tx from the current "owner" (to "release" ownership).

If the owner doesn't release within a certain period (say 48 hours) then the coins for the purchase would be refunded to the "buyer" - if the owner does send a confirming tx then the coins for purchase are sent to the owner (minus a fee) and another tx from the "registrar" is issued to the address.

Agreed that maybe namecoin could be useful in providing a solution for this but whatever the solution it would be best to utilise a block chain in order to have things publicly verifiable.

Aha - this is beginning to make some more sense - is there an explanation of how the mechanics of the "move" command actually works documented somewhere (other than in the code)?

I read through the links you gave (and thanks for the interesting reading) but still don't see how anything written there describes that the purpose of "accounts" is to automatically adjust balances due to a block chain reorg (it seems to me that reorgs are just something that has to be handled in order for it to give meaningful results with listtransactions).

AFAICT the purpose of "accounts" is to be able to divide tx's into separately labelled groups (much the same as in normal accounting with a GL) and thus to be able to get balances for each group (i.e. a "group" is an "account").

Perhaps if you replace the word "purpose" with "implementation" that might be closer, however, the implementation could have easily been written to use a previously "labelled" address as the only input address for a "sendfrom" without changing the purpose at all. I assume the reason it wasn't done this way was to keep the pseudo-anonymity as strong as possible (which is something completely unlike the way any normal accounting works).
 

For sure - but also understand that there are over 5 billion ounces of gold in existence and currently only around 10 million bitcoins (with the maximum amount ever to exist less than 21 million).

If bitcoins were to really be valued as being worth the same as gold then that would make 1 btc closer to 1 million USD. 

The FAQ mentions about having to pay a 20 BTC amount to register your GPG key with them.

So does this mean that it would cost each person 20 BTC just to put in a bid for the shares?

Interesting - hadn't heard of this explanation before - has a block chain reorg occurred since the API commands were introduced?

A good point - personally I think it was probably not such a great idea to have added the commands in the first place (although I can understand why they would have been requested) - the raw transaction commands are definitely something I see as being more useful.

Actually they are nothing like accounting accounts which is exactly why I (and I assume some others) was confused by them in the first place.

The idea of a Bitcoin "account" is to help support a "website user account" rather than anything to do with a general ledger in accounting.

Thanks for the tip - I will be changing the hashing rounds per this advice.

The main reason for the salt being generated the way it is (i.e. from the username) is that I have designed my system to provide security over HTTP (so all information needed to create the salt needs to have been first broadcast).

Am using SHA-1 currently (as it was the only secure hash algo I had previously) but will be changing to it later.

Currently I am encrypting password hashes (with AES) based upon a key that is split between compiled C++ code and a the contents of a text file - so there is nothing to help you crack a password if you just grabbed the DB contents.

The salt that I use (currently) is the username hashed by x rounds and combined with a unique server id string (also not stored in the DB) and the final password hash itself being y rounds of the salt and actual password.

Am just wondering if there is any weakness in the approach that I am using?

From http://c2.com/cgi/wiki?MicrosoftWindows:

Windows was once famously described as "32 bit extensions and a graphical shell [on top of] a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition." This was attributed to Art Bahrs (an HP guy) in Aug 1997, although it probably predates that.

So the slang "two-bit" (such as a "two-bit company") is not used in the US (thought I'd read some joke about Microsoft Windows years ago that had that term in it)?

Good call - I think naming the command sendfrom is what has confused people about its behaviour.

What it does is basically label the tx with the account name (it actually doesn't have anything to do with which addresses are picked to send from).

There is a patch/branch for Bitcoin that enables you to nominate which addresses to send BTC from (normally you have no control over this).

In the next release (0.7) there will be a new raw transaction API which will enable you to do the same (and actually more as you will have complete control over the transaction with it).

Actually I don't think that the algorithm is so important as limiting the # of attempts to login to the same account (as is done by banks) - it would be a pretty stupid piece of software that actually allows even 100 attempts to login to the same account within minutes.

Actually now that I think about it this would make perfect sense as the "account" is just a label you put onto a tx. So if you send and you had never received with an address labelled as an account then of course the balance would be negative.

I guess it really just says more about the unintuitive nature of the implementation.

Am not aware of this feature/bug as after realising that accounts were not suitable for what I was looking for (which was really coin control) I stopped playing with them.