Quote from: CIYAM Pty. Ltd. on October 13, 2012, 01:14:35 PM

Quote from: Gavin Andresen on October 13, 2012, 01:08:41 PM

No. The reference implementation doesn't keep a master map of all addresses to unspent transaction outputs, and adding such an index for the small number of services that need to look up arbitrary addresses doesn't make sense.

I understand the point but I think that as fewer and fewer people other than miners and services end up choosing to use the "reference implementation" (due to the size of the block chain and time it takes to process) wouldn't having such an index (as an option) make at least a little sense (which would only come into effect after a rescan assuming the option wasn't originally turned on)?

My view is that the "reference implementation" is actually what we want to make things easy and possible for services (rather than each having to roll their own). If this is wrong then why bother with the "raw tx" API at all (as certainly no normal end-user will ever use it)?

I have to agree with this. Having bitcoind be a platform that enables other developers and service providers to leverage the "low level plumbing" done by developers with superior knowledge of the "quirks" of the protocol (i.e. Gavin et al) allows it to pay dividends.

I think that is something which is really missing (and note this isn't a complaint I haven't built it so I can't complain that others haven't) but rather just an observation. At the same time the bitcoin-qt becomes less useful to end users due to the increasing requirements of full nodes, it becomes even more valuable as a platform for developers to build higher level services and tools.

Just throwing out an idea here but I think the GUI needs to be decoupled from the "bitcoin engine". Imagine a scenario where there are three related projects.

The bitcoin class library (think openSSL, or bouncy castle but a bitcoin equivelent). Contains the data structures and algorithms necessary to communicate with the protocol and store, organize, and access blockchain data.

The bitcoin reference engine is a non-GUI implementation of the bitcoin class library and handles communication between a client (any client) and the network.

The bitcoin-qt (GUI client) is branched off and handles the high level implementation of user interaction and uses the bitcoin engine. This would allow other GUI developers to be able to build drop in replacements leveraging the work already done in the engine.

Once again just an observation but it seems to me the "bitcoin reference client" is really three projects tightly coupled. That makes building derivative works difficult and limits the feature-set that the lower level functionality can provide. Everything is seen through the lens of what is best for this GUI client, a client that is increasingly not the optimal solution for manner users.

WARNING: The above was written before I had my morning dose of caffeine so may be semi-incoherent.