I don't think you realise just *how* remote the chances are - so perhaps consider the following:

1) You win 1M lottery - seven days in a row.

2) You just miss getting hit by a jumbo jet falling out of the sky - seven days in a row.

3) You managed to pick up a Hollywood movie starlet - seven different starlets seven days in a row.

All of the above happening are more likely than the chance of two addresses being the same.

Got it now.

Transactions are prioritized according to a few criteria:

1) Their size.

2) The age of their inputs.

3) Any fees you have included.

If the size and age are no problem then fees are currently not necessary at all (although they may not be prioritized as highly as those that include fees).

If the size is large then a small fee per kb is required and if not too big but the inputs are too recent then a minimum fee (of 0.005 I think) is required to be processed quickly (small tx's without fees that have inputs that are too young will just end up having to wait until they become old enough to process).

Currently a tx will only end up as "dead" (never to be processed) if it is above the minimum size and no fee has been provided (most clients will not let you easily create such a tx).

If you elect to pay more fees than necessary then it is up to miners to decide whether to prefer your tx (I assume in general they would - and especially since the introduction of Satoshi Dice).

In recent times I have noticed that tx's that do not include any fees (but don't need to) can be delayed quite a bit (say several hours) vs those that do.

No different to dollar bills lost or stuffed into mattresses that were forgotten.

Seriously dollar bills don't have an expiry date so why would we want them for bitcoins?

I guess it is perhaps likely that within 100 years the ECDSA used for the key pairs will have become insecure and another algo will be needed (effectively forcing all to "upgrade" their bitcoins or risk losing them).

Thanks - I will be adding support for "bitcoind" calls as part of the first application I intend to promote with the launch of the system later this year (can't say much about the application itself).

Apart from the "secret application" it already has Forum and Blog packages and it will also have a complete webmail application as well (with GPG support).

It's perhaps a little more like a complete platform (such as Ruby on Rails) and sure I understand not everyone wants to learn how to work with such a beast.

The really good thing about the system/platform is that you can build complete web applications without writing code at all.

Well not a rewrite of SQL statements (as there are none in my system) but it would be an entirely new application so I do understand that it's probably more likely that some sort of minimal approach (as you suggest) to fixing things up would be taken.

There are no SQL queries manually coded anywhere in my system - all SQL is generated by the application server so the above simply could not occur.

A big advantage to this approach (apart from security) is that fields can be renamed without having to manually change any code (after renaming a "regenerate" performs all require changes).

The tricky part of achieving the best anonymity possible is the need for "change" addresses as careful analysis of tx's can end up deducing that certain addresses belong to the same owner.

For the highly technically proficient user the raw tx API makes it possible to control exactly which addresses are being used in a tx, however, this is not something for any average user (and therefore won't help in increasing general adoption).

I think multiple wallet support will probably be of some help here for the general user (is already in some clients and I think is planned to eventually be put into the Satoshi client).

People that are mining bitcoins do have an ability to repay (which is not tied to any other currency) so if they are looking to increase their mining power (by purchasing more FPGA/ASIC units) then it can make perfect sense for them to be borrowing BTC.

That said - there are a lot of scammers on this forum so be careful before lending out your bitcoins.

For sure the volume has greatly increased since last year - but nothing has dramatically changed very recently (was actually a little surprised that the "memorydealers" visit seemingly had no effect this time when last time it caused a huge jump in volume).

I very much doubt that - the volume on btcchina has been well under 1000 btc per day for quite a while.

Yes - this is under development (just not a big priority yet).

Actually I am building CMS extensions that will generate real pages that can be indexed by Google, etc. (has just not been my priority).

Sure - when you provide a password to "log in" then this is hashed along with a UUID to then encrypt an AJAX type request.

Your request will just look like rubbish to any MITM watcher and all content returned via the AJAX request (which is all the content and why Google can't see anything) is encrypted not with the same key but with another hash (determined client side from the original).

Due to the use of a UUID it is not possible to use a "replay" attack from watching the original login post (hope this makes sense).

For the website in question I'd guess so.

Am actually hoping to go up against the likes of Diaspora by having private content securely encrypted over plain HTTP (a feature recently developed).

If you are interested in having a website that is SQL injection proof and cannot have source code stolen then you might be interested in the technology that I've developed (all back end code is compiled C++, all queries are via an abstraction layer that ensures SQL injection is impossible and all URLs cannot be tampered with due to checksum protection).

The one weakness at this stage with the technology is that Google can't even search your site (all queries are through the main website URL).

I didn't really like the UI change to QT initially but I must say now that it has grown on me (and has improved with the last couple of versions). Also there is no problem with setting the tx fee to zero.

Perhaps you might consider giving it another try?

Unfortunately it is very "low level" and so will take a bit of working out but if you want complete control over tx's it is the only way you are going to get it (the other patches that have been done aren't nearly as comprehensive as this raw approach is).

The accounts are very unintuitive - you tie one to an address via setaccount but actually that is only being done for the purposes of tracking incoming tx's. Outgoing tx's get their account label from the account label provided when you send (having nothing to do with any address you may have have "tagged" with setaccount).

So an account is not an address but instead a label applied to a tx. The design is for dividing a wallet up into separate user accounts as say an exchange might do and is most useful for the case of transferring bitcoin between such accounts without having to actually perform a real tx.

What you want to look into is this: https://en.bitcoin.it/wiki/Raw_Transactions

(you get complete control of a tx using these RPC calls)

Sounds very promising - I will be wanting 10,000 addresses where each address has a specific 5 character (after the 1) prefix. Do you have a rough estimate how much this would cost?