Compressed public keys help the size of the blockchain. Unless you negotiate full public keys (like will be necessary for multisig, probably), compressed public keys don't help you for scanning (an address is still 160 bits, shorter than a public key).

Though there are uses, I don't think scanning private keys will (or should) be common.

Compressed keys were not used initially because either Satoshi didn't know about them, or preferred avoiding them for legal reasons (those appear very limited, anyway).

Yes, there's a new command-line option -blocknet=X, where X can be ipv4 or ipv6. Using it means the client won't listen (at least not by default) to X interfaces, and will not attempt outgoing connections to that network.

Portable means you can move/copy it to another data directory.

If changes have been made to a .dat file (except blk0001.dat, which isn't really a database), an "lsn_reset pass" is necessary before the file can be used in another data directory (or the same, if its logfiles are deleted). Versions prior to 0.6.1 would always perform this pass at shutdown - which could take up to a minute on some systems. Since 0.6.1, this process is made optional for addr.dat and blkindex.dat. Wallets are always made portable at shutdown.

No official release to date has had that functionality, but 0.7.0 probably will.

From the perspective of being educational, I have absolutely no problem with people reimplementing code. They may stumble upon bugs, and even a partial implementation can have niche purposes (for example only the networking code for a crawler, or fast blockchain manipulation code for rescanning addresses).

That said, trying to understand existing code also has great educational value; in particular when you're trying to improve things, because that confronts you with things you thought you understood but didn't. In my opinion, this is a better way for helping the community than by starting from scratch - that just takes longer before it is useful.

It depends on what caused the slowdown. While not syncing the chain, with no caches to write at shutdown, I often get shutdowns close to a second or less now. During chain download, it can be significantly more.

I like this idea very much. It changes the incentive from just including a transaction in the blockchain to also burying it, which is what the owner really wants. I've suggested something similar before, but I can't remember whether it was on the forum.

The actual distribution is an exponential distribution, with lambda=1/600s (assuming difficulty is properly adjusted to the actual hashrate). This follows from the fact that block mining is a Poisson process (every fraction of time has the same, independent, chance for having an event).

Note that this is an idealized assumption: network delays cause the seconds immediately after a new block have a lower chance for producing a valid non-stale block. Also, I'm talking about actual block creation times, and not the times reported in their timestamps. Certain pools fiddle with these timestamps to increase the time work remain valid - they can, but that probably means the distribution is different when looking at timestamps (for example, it can be negative).

In summary, under idealized assumptions, the shape stays identical.

Assuming the actual hash speed of the network is constant for a longer period of time (which isn't true, but we can approximate), the time between blocks will always have the same distribution, regardless of the actual hash speed.

I hope a typical human never needs to see a base58 private key.

Actually, I hope they don't need to see anything base58 at all (think URL's, files, QR codes, ...).

What you suggest was my first idea.

I changed it not to further pollute the version byte namespace. It was originally a version number, and after time it grew into something that contains informations about data types, network, ... as well. I preferred not to add a new number for a variant of the exact same thing. Or put otherwise: i feel that secret keys are linked to addresses - one shouldn't change version if the other doesn't, and obviously addresses don't change because they're using compressed pubkeys (they can't for compatibility reasons).

I mailed about this suggestion to the development mailinglist(*), including several test vectors. As far as I know, nobody complained.

I must admit I didn't take human recognizability into account too much. Even though base58 was designed for ease of human transmission, things with the length of a secret key will always be copy-pasted anyway.

(*) URL: http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&forum_name=bitcoin-development

The Linux and Windows binaries are built using gitian. Gitian is a system that builds the source inside an virtual machine running Ubuntu. By carefully controlling the build environment like this, it guarantees that everyone ends up with byte-per-byte the same binary as output. These are signed using GPG, and compared among developers before release. This allows everyone to verify that the distributed binaries are indeed created from the specified source code.

The script for the Windows build can be found here. Note that it's built in a Unix environment, and is probably very different from how you'd do it on Windows itself. Still, it may contain some hints.

If you're going to rewrite C++ in C (by building virtual function tables yourself), why not code it in C++ in the first place? If compatibility is a problem, you can always expose a C interface to the code.

There is indeed a problem with the OSX version, resulting in 100% usage. We're working on a fix.

May I ask what you need this for (don't get me wrong, there are various good reasons for it, I'd just like to know the use case).

Accounts are only intended as a virtual balance, the ability to keep a separate balance for different users. It has nothing to do with actually separating the wallet coins.

Which OS? What was the exact version you were using before (before or after 0.3.21)?

-rescan is actually only necessary if the old client was older than 0.3.21.

-rescan has become almost useless since 0.3.21, since the wallet stores the last block it knows about, and it will do an automatic rescan from that point on at startup.

The only reason when it is still useful is when you're upgrading from a 0.3.20 or older wallet, or when you used external tools like pywallet to add keys to your wallet.

This really has nothing to do with bitcoin. Maybe you can post something in the market section if you want to pay for programming help.

Let me try to formulate things differently. I'm only talking about the Bitcoin reference client (its wallet) being used by end users. Using address-to-block indexes in fat servers that serve many thin clients, is obviously a good idea.

But for an end user who is running the bitcoin software (for now with a full node, later perhaps in SPV mode when it is implemented), I see no reason to replace storing the transactions in the wallet by an on-the-fly scan through the block database (even with an extra index to speed it up). First of all, the endpoints (in particular the receiver) is ultimately responsible for having the transaction around: in case the transaction is not yet in the blockchain, sender and receiver of the transaction are those who will keep broadcasting them. In case of a reorganisation, a transaction may be lost and again the owners are responsible for keeping the transaction alive. Second, further developments with multisig transactions will require transactions being negotiated (which is non-trivial and requires many communication steps) before they can be published and mined into the chain.

It seems to me your largest issue is usability. And I agree, there are many improvements possible for the end-user using a local bitcoin wallet. But the solution is supporting multiple wallets, improve efficiency, improving the user interface, simplify saving and restoring backups (tagged with for example the first block that would need to be scanned for incoming transactions), .... Adding an extra index may be viable right now, but I can't believe that such a requirement will be necessary for how bitcoin wallets will be used in the future.

That said, I didn't say such an index is a bad idea - there are certainly uses (in particular when the nodes functions as a back-end for thin clients, or runs a large service). It's not a priority right now, but that can change. I just don't think it is the thing end users need now.