ead6c2f45f
Querying addresses that have millions of transactions is supported however takes hundreds of seconds to fully calculate the balance. Creating a cache of previous results wasn't currently working because the `isSpent` query is always based on the current bitcoind tip. Thus the balance of the outputs would be included however wouldn't be removed when spent as the output wouldn't be checked again when querying for blocks past the last checkpoint. Including the satoshis in the inputs address index would make it possible to subtract the spent amount, however this degrades optimizations elsewhere. The syncing times or querying for addresses with 10,000 transactions per address. It may preferrable to have an additional address service that handles high-volume addresses be on an opt-in basis so that a custom running client could select high volume addresses to create optimizations for querying balances and history. The strategies for creating indexes differs on these use cases. |
||
|---|---|---|
| .. | ||
| address | ||
| bitcoind.unit.js | ||
| db.unit.js | ||
| web.unit.js | ||