That requires the full blockchain (which is something that will get removed further and further from wallets in the future, imho), plus an extra additional index on top of it. Furthermore it misses any ability to store local data (address labels, accounts, comments, ...).

I believe what you are looking for is Electrum or another lightweight client, which keeps all that data and I assume fast rescan ability on a server.

I agree with you that we shouldn't need a lengthy rescan to switch wallets (afaik, we don't, but switching is far from how easy it should be), but the solution is adding multiple wallet support to the client. Using the blockchain as your transaction store may sound fun, but I don't think it's a viable end-user way of working in the future.

I think you're preaching to the choir. I don't think many people consider bdb for the wallet a good idea. I've already experimented with an own format to function as drop-in replacement for the database file. It doesn't look too hard, but obviously compatibility issues will complicate things.

Seems your source code is not compatible with JSP.

I believe the reason for only using one table is the result of the glue layer on top of BDB (which I suppose was designed by Satoshi). This way, only one open database object needs to be kept around per file. It's an ugly system, but it seems reasonable at least. As far as I know, Satoshi didn't really like the idea of alternate clients, so I don't think he designed with ease of interoperability in mind. Once that layer was in place, it was probably all to easy to add fields to (mostly) the wallet for various pieces of data (and I did so as well, later on...).

Regarding the choice for BDB in the first place: it makes sense for the transaction/block index database. These are large, need frequent updates and queries, and need a high degree of transaction atomicity. For wallets and IP addresses, I believe better solutions are possible. Both are only read at startup, and subsequently updated but mostly appended to. I hope we can move to a better format (especially for the wallet) soon. One that isn't prone to corruption under flaky hardware (perhaps by only appending to it, and occassionally rewriting it), isn't linked to a fixed database environment directory, and is backward compatible...

Can you just answer this question: where does the label you want listtransaction to report for outgoing transactions, come from? Or alternative, how do you want to set it?

The question is, where do you want the data that gets added to the label or account of an outgoing transaction to come from? If it comes from another hypothetical RPC call "settransactionlabel" or something, you may as well use the sendfrom RPC.

You say that account is always empty for outgoing transactions. That is not true, it is equal to the account you sent it from (and the default is ""). If you use "sendfrom", you can decide which account it is subtracted from.

Also, yelling doesn't help.

CBlock::AcceptBlock() is called for each block that gets attached to the block tree on disk, i.e. every valid block that has a history leading back to the genesis block. It is also called for blocks that fail to connect afterwards (those with double spends in them) or stale blocks that just never make it into the best chain.

I think you're better off hooking in ConnectBlock() and maybe DisconnectBlock(). These get called for each block joining and leaving the current best chain.

The entire premise of bitcoin is that to participate in the system, you agree to its rules. Those are not enforced by the software - you can change it - but by the community.

If the software would be easier to modify, nothing would change. Maybe a few more alternative blockchains would appear, but those who are willing to start such an experiment can already do so today.

Can you post your debug.log file somewhere?

How long have you been stuck already?

The development process consists of this cycle (in a perfect world, at least):

• the "merge window" for a new version opens
• complete and accepted pull requests are merged into the master branch
• the "merge window" closes (it usually remains open for a few weeks)
• a release candidate is built
• the release candidate is tested
• if found necessary, fixes (but no new features) are merged, and a new release candidate is built.
• if the last release candidate survives testing, it is renames and released as final
• repeat

$ ./bitcoind getblockhash 100000
000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506
$ ./bitcoind getblock 000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506
{
    "hash" : "000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506",
    "size" : 957,
    "height" : 100000,
    "version" : 1,
    "merkleroot" : "f3e94742aca4b5ef85488dc37c06c3282295ffec960994b2c0d5ac2a25a95766",
    "time" : 1293623863,
    "nonce" : 274148111,
    "bits" : "1b04864c",
    "difficulty" : 14484.16236123,
    "tx" : [
        "8c14f0db3df150123e6f3dbbf30f8b955a8249b62ac1d1ff16284aefa3d06d87",
        "fff2525b8931402dd09222c50775608f75787bd2b87e56995a7bdd30f79702c4",
        "6359f0868171b1d194cbee1af2f16ea598ae8fad666d9b012c8ed2b79a236ec4",
        "e9a66845e05d5abc0ad04ec80f774a7e585c6e8db975962d069a522137b80c1d"
    ],
    "previousblockhash" : "000000000002d01c1fccc21636b607dfd930d31d01c3a62104612a1719011250",
    "nextblockhash" : "00000000000080b66c911bd5ba14a74260057311eaeb1982802f7010f1a9f090"
}


First call getblochash to find the hash of a block at a particular height, then use getblock to query information about the block with that given hash. The "time" field will tell you the block's timestamp (in seconds since epoch).

I've once proposed an optional URL that can be specified by a user, which provides an exchange rate history with a particular currency. The client could then show amounts in transactions and balances in that currency, and even add virtual "exchange rate profit/loss" ledger entries that correspond to a varying exchange rate.

Not much response back then

libbitcoin or armory's library will surely give you a much more flexible interface, but you *can* just do this using bitcoind as well. See the getblockhash and getblock RPC commands.

What problems do you have with the current build system, and on which platform?

It's indeed around 1.1 GiB at this point. You should have 176613 blocks at the time of writing.

The previous post in this thread is 1.5 years old. We've since switched from the wx GUI ("bitcoin") to a Qt GUI ("bitcoin-qt"), and the version requirements for several libraries changed as well. We've also switched from SVN to GIT...

In any case, that cmake file will be severely outdated by now.

The calculated fee depends on the actual transaction produced, such as on the size, the number of inputs, their value, and their age. The client uses some heuristic to prevent unnecessary losses, but the algorithm is not deterministic. In some cases, a simpler transaction is produced, or if time passed, the fee requirements decrease.

In short, yes, this is possible.

importprivkey is slow because it does a rescan of the entire blockchain, and blocks most other operations while it's running. It's not intended to be used frequently in its current form.

I think you'll just need some patience.

You can delete them if you closed the client cleanly. In case of an unclean shutdown, they are necessary.

Version 0.6.0 should already create much less log files (or rather, wipe more frequently), though. If you're not using 0.6.0 yet, it may help.