If you run with -detachdb, and exit cleanly, they can be removed.

In every other case, the database files refers to indices in the log file, and the program will fail to open the database files in many cases.

Is the problem just that progressbar below? In that case, a fix for that weird bar (not specifically for Windows 8 though) was recently merged, and will be in the upcoming 0.7 release.

It's certainly faster to be able to do some checks before requiring the parent to exist. This allows you to validate the PoW of received orphan blocks, before bothering to request parent. Also, it allows doing some checks on a received block before needing a lock on the block tree data structure.

Bitcoin-the-system does not keep balances per address, that's just an authentication layer on top. The only thing that exists are coins, each potentially assigned to an address, and each transaction explicitly referring to the coins it consumes.

So, given that you have a 2 BTC coin and a 1 BTC coin (assigned to separate addresses, or to the same, doesn't matter), and you send 2 BTC somewhere, it will just take the 2 BTC coin, as that suffices. If you'd send 2.1 BTC somewhere, it will use both coins, and send 0.9 BTC back to a change address of yourself.

The GUI does not allow you to select inputs specifically, although the 0.7 release will allow you to do so when using the RPC interface.

I don't think this is a good idea:

• It is incompatible with clients where the private key associated with the sender address does not belong to the sender (mostly e-wallets now). Bitcoin transactions do not have a real from address anyway, just potentially an address its coins were previously sent to, and using this as a 'refund' address breaks some uses of the protocol.
• It is incompatible with blockchain pruning, in which case there is no guarantee that information about the first send to a given address is easily accessible. You could of course set up a service that maintains this information, but at that point you don't have any advantage over just a third party that maintains bitcoin address books.
• It re-enforces the notion that we should associate addresses with people, while over time, we will have to move to separate addresses for every transaction to maintain privacy in the system. I know that I'm an offender myself here by showing a vanity address below, but that's only as long as no better well-supported payment methods exist.

bitcoin.org was never owned by Satoshi, IIRC.

My guess is that your wallet consists of many very small coins, and combining them to have enough funds for the amount you're trying to send, makes it too large, or so large that it requires more fee than you'd have left.

Try sending a bit less, or try to first send a smaller amount to yourself.

There are more potential optimizations:

• Batch verification: theoretically, it should be possible to verify the different signatures in a single transaction or a single block at once, as we don't care to know which signature fails. This seems very experimental, but I read things about a speedup of up to 4x
• Specialized/assembly implementations: for the NIST-P256 curve (aka secp256r1), Google implemented an optimized version that is 3-4x times faster on x86-64. Their techniques may be portable to secp256k1?

For reference, script validation reaches a speed of 1735 sig verifications per second, on a single core of my Core i7-2670QM (2.2GHz) CPU. Assuming at least Hal's optimization and parallellisation are possible without additional overhead, 8000 sigops/s should be doable on this CPU, which means validating a current worst-case block (because of the 20k sigops limit) in 2.4s.

Parsing the block chain is trivial, it is updating the transaction database while keeping it consistent that makes it slow.

That said, yes there are serious improvements possible, and we're working on it.

There was some discussion about earlier on IRC.

Right now, message signing is a very low-level function. It has very interesting applications, but in its current form, you're not going to use it unless someone tells you to, or know what it does.

The one point where it makes sense, and the only way I see it being intuitive, easy and useful, is as part of a payment protocol. By which I mean this: an address is a URL or something e-mail like, and the client connects and requests payment information (such as the public key/script to send to, the amount, maybe a message, maybe an order id), the client constructs a transaction and sends it directly to receiver or his payment processor. When such an address is selected, the client could enable a text input field for a message to attach to it, and it would travel together with the transaction directly to the one who cares, with a signature that it comes from the payer.

At that point, it absolutely should be a first-class feature. But right now, it's obscure and unclear.

Since I am the one who claimed that Luke was the only proponent of this possibility, let me try to explain.

First of all, signing and verifying of messages is supported by the upcoming client version no matter what. The question is whether it must be a full tab, like send/receive, or an feature only reachable from the menu.

To me, it is obvious that this is a specific, quite separate feature of the client, unrelated to its core functionality. Making it available as prominent as sending/receiving coins is only confusing. I've seen people assume that it was necessary for confirming transactions, so my opinion is that we should make it as clear as possible that it is unrelated. A "tools" menu item would be best suited for this, but that's a separate issue.

Luke introduced the ability to compile with "first class messaging" (=sign/verify in a tab) some time ago, and at the time I considered having it as an optional non-default feature wouldn't hurt anyone. However, as people now have to spend extra work to keep it around and keep it functional, it becomes a burden. Therefore, I supported the opinion that the ability for having it as a full-fledged tab should be removed.

The blockchain does not contain IP addresses; it doesn't need to. It is just a system for obtaining a global agreement about the order of transactions, and these transactions are between Bitcoin addresses - nothing more.

That doesn't mean it isn't possible to infer some information by trying to localize the origin of transaction (like blockchain.info does: connect to many node, and remember where you first heard about a transaction). This isn't fool-proof, but it may give you something.

However, even without any IP information, there are several ways for tracking coins as they pass through addresses, and deducing some information about who may be dealing with whom - especially as people put (some of) their public addresses online. Bitcoin is certainly not anonymous, but it is possible to get some privacy if you're careful.

You should always make sure that only authorized people can access your RPC interface, either by firewalling it, or using a strong password.

Requiring the wallet passphrase is not intended as authentication to the RPC daemon, it's simply a necessity to decrypt the wallet keys.

What this does in essence, is using the block chain as a communication channel for private information. That may seem to be an easy solution right now, because of how the current Bitcoin infrastructure operates, but it has so many disadvantages (like gmaxwell already described).

The root of the problem - in my opinion - is the fact that the only widely-supported way of doing a bitcoin transaction, is in fact already by using the block chain as a communication channel. Satoshi originally envisioned that transactions would be done using a pay-to-IP-address protocol, and not via pay-via-blockchain-to-public-key-hash (what we do now). In many ways, pay-to-IP is far superior, however:

• It sends the transaction directly to the one who needs it, instead of forcing him to scan the entire blockchain for things that look like a payment to him.
• It moves the responsability for getting the transaction accepted to the only one who cares about that.
• It allows adding comments, order id's, or whatever message you like to the transactions (including proof that it comes from a trusted party), completely private, and without bloating a very expensive distributed database (the block chain).

Over time, however, pay-to-IP had many shortcomings, and became obsolete, and eventually disabled.

I think it is time we introduce a new way for doing direct payments, with the advantages of pay-to-IP, but properly authenticated and secured. I don't think the solution is tagging the Bitcoin transaction itself (which only requires data necessary for the world to validate it) with data that decreases the privacy of the entire system.

No, this was never fixed. Doing it now would at first making transactions which use non-standard but valid encodings non-standard, and then fixing a policy for a transition point after which it becomes illegal.

Ask Satoshi...

(I suspect the answer is that it felt safer to him for some subjective and not very well-founded reason)

Right now, it only means an attacker can make your (unpatched) node get stuck.

Back when only a low percentage of clients had upgraded, it might have been used to assist with a 51% attack, by knocking out some legitimate mining power.

For starters, since it does not allow arbitrary seeds, it is hard (1 in 2^N/2) to come up with a password/passphrase to use as one. The intention is to still generate these seeds by a computer (just like Armory and Electrum do now), but use a dictionary to construct them, so they can easily be written down or remembered. As soon as the seed space is 2¹²⁸ large, attacking it becomes as hard as the ECDSA verification in Bitcoin itself.

Apart from that, there is the possibility to use a user-provided salt.

(this is a proposal based on a discussion with gmaxwell and etotheipi, and inspired by a proposed extension to the Casascius mini private key format)

1. Abstract

There is currently a lot of talk about deriving keys or wallets from a relatively short seed in a deterministic way ("brainwallets"). As your wallet's keys are exposed to the whole world, it is essential to make sure it is hard to mount a brute-force attack against potentially easy-to-guess seeds (in particular when the seeds are user-chosen passwords). This is a proposal for a standard for doing this derivation, which has some nice properties.

2. Introduction

Typically, key strengthening is used to increase the time necessary for trying a single seed. This does however require either fixing the number of iterations (which should increase over time as hardware gets faster), or forcing the user to remember the number of iterations. It also lacks a way to verify a seed was correct, as every seed results in a valid key.

An alternative is using a checksumming system. For example, requiring that SHA256("BLAH" + seed) starts with a given number of zero bits, and using SHA256(seed) as key. With N required zero bits, this also slows down testing of seeds by 2^N per valid seed. It does provide a way to verify a seed was correct, is very fast to do the actual derivation, but also introduces some variation in the seed generation.

Neither solution however addresses the fact that it requires the derivation count or checksum strength to be known in advance (either as part of the specification, or by making the user remember). However, by combining both strengthening and checksumming, we can have seeds that encode their own strength, without compromising security.

3. Proposed algorithm

This is the proposed derivation algorithm:

• Calculate H(H(H(...(seed)...))), with 257 iterations, and H = HMAC-SHA512.
• If the 257th iteration results in a hash that starts with 8 zero bits, the 256th iteration hash is the output (the key).
• If not, keep doing iterations
• If the 513th iteration results in a hash that starts with 9 zero bits, the 512th iteration hash is the output.
• If the 1025th iterations results in a hash that starts with 10 zero bits, the 1024th iteration hash is the output.
• ...

This results in a variable-strength keying that requires 2¹⁶, 2¹⁸, 2²⁰, ... iterations of H per valid seed (both for a legitimate user creating a new seed, and an attacker trying to attack them). However, an attacker who does not know which strength the user chose, cannot give up quickly after a limited number of iterations. In what follows, we will however assume an attacker does now, so the security of this scheme does not depend on that property.

What this does essentially, is split the generation difficulty equally over making it take 2^N steps to generate a key, and at the same time, making only 1 in 2^N seed valid. This has some nice properties:

• Generating a key of a given strength S, requires 2^16+2*S iterations on average
• An attacker that has an oracle which can iterate all valid seeds of a given strength in constant time, still needs as many elements as there are in the original seed space to test all valid keys.

Note that HMAC-SHA512 does take a salt as input. This salt can be an application-defined default (such as the fixed string "Bitcoin key derivation"), but the application can also prompt the user for some extra random but non-secret bits (such as an email address, a birthdate, ...). There have been threads above such a salt alone, if I recall correctly.

4. Improvements

The potential difficulties (number of iterations necessary to a generate a valid seed) offered by the scheme described above are relatively far apart: a factor 4. We can however tweak the algorithm a bit.

Instead of checking for a particular number of zero bits at the start of a hash, we can interpret the hash as a number, and compare it directly to some predefined constant. This is similar to how the proof-of-work check happens in Bitcoin itself. Assume we want the difficulties to start at 2¹⁶ still, but have them be a factor 2 instead of a factor 4 apart, we can use this algorithm:

• Calculate H(H(H(...(seed)...))), with 257 iterations, and H = HMAC-SHA512.
• If the 257th iteration results in a hash whose first 32 bits are below 0x101000, the 256th iteration hash is the output (the key).
• If not, keep doing iterations
• If the 363th iteration results in a hash whose first 32 bits are below 0xB60183, the 362th iteration hash is the output.
• If the 513th iteration results in a hash whose first 32 bits are below 0x80C1A2, the 512th iteration hash is the output.
• If the 726th iteration results in a hash whose first 32 bits are below 0x5B2143, the 725th iteration hash is the output.
• ...

(more constants and mathematical model to obtain them can be found here; the numbers are found by a numerical approximation).

This results in difficulties very close to 2¹⁶, 2¹⁷, 2¹⁸, ...

Another potential improvement is using a different H function, such as something based on scrypt.

5. Implementation

An example implementation in Javascript can be found here. It does use a modified set of constants, which result in difficulties around 2¹⁰, 2¹¹, 2¹², ... instead, as difficulties around 2¹⁶ are already unusably slow (though possible) in Javascript.

Neither bitcoin or fiat currency are backed by anything (in the traditional meaning of the word backed: guaranteed to be exchangeable for something else); in that sense they are very alike. Despite being modeled as digital gold, bitcoin isn't: gold has intrinsic value (it would have value if it were not a medium of exchange), though the intrinsic value of gold is a lot less than the exchange value.

One difference between fiat and bitcoin certainly is the fact that one is secured by laws, and the other by an algorithm. But outside of the country in which a fiat currency is legal tender, its exchange value to other currencies is mostly dictated by a free market, which is also true for bitcoin.

I think the largest distinction between fiat and bitcoin is not in its economical properties, but technologically. It allows people to store and transmit value, in a digital way, across the globe, without needing to trust any third part (be it a government, a bank, a payment processor). That, and the fact that it is inherently digital instead of being a digital representation of a real-world thing with value, makes it unique.