Patches very welcome

There's no point in that: downloading the chain will not go faster with more connections - one good one suffices. In fact, incoming connections have a much larger chance of wanting to request your block chain, slowing your sync down further.

It takes about half an hour for me, when loading from a local file (a patch that will probably be in 0.7) instead of from the network.

If you have a lot of RAM, you can run it in a RAM drive (if your OS supports that) and watch it fly. Of course, you'll miss the one hard part: not losing or corrupting the on-disk index when your computer crashes.

The hard part is not downloading or storing the block chain. It's building, maintaining and guaranteeing the on-disk consistency of the block and transaction index that is necessary for validation.

The reason is IRC being deprecated and defaulting to off. This will indeed mean less very fast incoming connections, but better connectivity for longing-living listening nodes (as others don't rely on recently IRC-advertized nodes, but on the addresses propagated through the network).

If you're going to suggest people to download the block chain database (bypassing all verification that bitcoin does when it fetches blocks from peers), it may be advisable to suggest using -checkblocks -checklevel=6 when starting up the first time. -checklevel is a new option that allows much more thorough verification.

Otherwise, if somehow such a download (by bad luck or malicious intent) gets corrupted, and many people download their chain from that point, a particular block could put them all at once on a block chain fork.

Mined in slush's pool a few days after it started (december 2010).

Hello all,

since some new options to bitcoind are considered more for debugging and tinkering than for end users, they did not make it into the release notes. Therefore, here is a more complete such list:

• -upgradewallet: new wallets in 0.6.0 are created in the latest format, but old wallets are left untouched in order for them to remain compatible with external tools. -upgradewallet forces the wallet to upgrade to the latest format
• -upgradewallet=<n>: allow (but do not force) an automatic upgrade to a wallet that is still compatible with client version n (for example -upgradewallet=50000 will make sure the wallet remains compatible with 0.5.0). One exception is when the user takes an explicit action that implies a wallet upgrade (encrypting it, for example), and the condition specified by -upgradewallet=N is not satisfiable. In that case, the wallet will still be upgraded to the latest format anyway.  You can also use this option to create a new wallet that is compatible with older versions.
• -checkblocks=<n>: In addition to -checkblocks (which verifies the entire chain), or no argument at all (which verifies the last 2500 blocks), you can now specify how many blocks the to check. For example, -checkblocks=10 will only verify the last 10 blocks. The minimum is 1, specifying 0 will cause a check of the entire chain
• -checklevel=<n>: specify how thorough the inital block validation algorithm is. The default is 1, and corresponds to the level of checking older versions did. In 0.6.0, any number between 0 and 6 is accepted, each significantly slower than the previous one. Checking the entire chain at level 6 will take at least 5 minutes if the blockchain is already loaded into the OS cache entirely.
• -dbcache=<n>: Specify how many megabytes of memory to use for internal caching. The default in 0.6.0 is 25, and higher numbers will not gain you much more speed probably. Higher numbers mean slower startup and shutdown, though.

But in most cases, there is no centrlalization. You are already communicating with the receiver via his website in many cases. There is no loss of privacy by also using this channel for requesting a payment address.

Do you consider e-mail a problem because it is centralized? You can switch to another mail provider if you don't like it. You could even run your own if you're paranoid. It's exactly the same here.

I like this idea very much - it's exactly the kind of evolution necessary for stepping away from seeing base58 strings as addresses (a word that implies some form of permanent connection to an identity).

I've proposed a more concrete proposal some time ago in the same light, a bit more specifically aimed for online merchants. You can read about it here.

@Meni: I could probably live with a hash of some message being attached to the transaction itself, but I'm still unconvinced it is necessary.

In my opinion, it is not the right solution to attach the message to the bitcoin transaction itself.

I'll explain why: everything you attach to the transaction is forever part of it, and will be stored forever (or at least until it can be pruned) by every single node in the system. Yes, this is the intended behaviour for transactions, but there is no need for them to be more than the bare minimum for the network to verify its validity.

When you want to attach a message to a transaction, this is essentially some private communication between you and the receiver of the transaction. Showing it to the world is both a burden, and a decrease of privacy. Indeed it would be possible to encrypt it, but that will not make it anymore necessary.

Realize that in most cases, you as sender of a transaction are already communicating with the receiver by other means. Be it a website, e-mail, instant messaging, real-life communication, .... There is no need to replace this existing communication with the blockchain, which is a very slow and expensive beast to maintain, and it would benefit us all not making it even more expensive than it already is.

Now, only the receiver actually cares about your transaction. In fact, he should be the one responsible for getting it into the block chain if he wants that, and not the sender. The current network and the architecture around it seem to have settled for using the blockchain both for confirming transactions as for getting them to their destination. This is not necessary, as you could easily envision prepared transactions being files that you can just send to someone (who will then verify it, and send it to the p2p network if he cares) via an http protocol, or via e-mail, ...; essentially reusing the communication channel you already had (imagine a merchant's website, you click "click here to pay", that opens your bitcoin client/ewallet, creates the transaction, and sends it directly to the merchant). In such a system, it would be easy to attach whatever message you or the merchant wants you to attach to it to that file. It would travel along with the transaction, and could be checked easily. However, it doesn't need to ever end up in the block chain itself. Nobody cares about it there.

Clearly this requires a different way of using bitcoin than we currently do, but it is closer to how Satoshi envisioned it (the currently deprecated send-to-IP system was how he intended transactions to take place, not via send-to-address). Still, I believe this is how transactions will happen at some point in the future.

Deleting addr.dat indeed works, and if no better solution is found, that will indeed be the advise for people who get stuck.

Still, it shouldn't happen, and it's not very compatible with the idea of decentralization: deleting your addr.dat makes you boot off dns seeds and built-in seeds. This works very well, currently, but I don't like the idea of people depending on it and not maintaining their own peer databases.

It requests blocks in bulk with a getblock. The result is a large inv announcement of up to a few hundred blocks (corresponding to at most 5 MB at a time). The client responds with a getdata for all unknown blocks, which are sent one by one using block.

The data is really requested in groups of several blocks at a time, but only downloaded and processed one by one. There are several improvements possible here still, though.

0.6.0rc5 rewrites addr.dat completely, so it's likely to expose previously undetected corruptions it seems. We've seen several reports of such cases, and worked around some.

I can give you a build or the source code with a potential fix, but it seems unlikely to solve it. Would you like to try?

You can use the new command-line/config option -dbcache=<N>, with N a number in megabytes. The default is 25, which should be quite good, but if you add more, speed may improve a bit still.

In 0.6.0 this is possible via the "importprivkey" RPC call.

The numbers are chosen by an external advisory yes, but apparently it's just a number to identify the problem.

I think it'd be a little more useful if information about the issue could actually be found in online databases directly about it.

As I've said before in another thread, the initial synchronisation process consists of three steps:

• Downloading the data: limited by your and your peer's network speed
• Maintaining the database: mostly limited by disk latency
• Verifying the chain: limited by CPU speed

Before 0.6.0, maintaining the database almost always outweighed the other two. With 0.6.0rc5 the caching settings have been tweaked, resulting in a remarkable speedup for the database. This means that now the downloading time may indeed become significant, and it may be worth looking at improving the download process, for example downloading from several peers at once.

Increasing the number of outgoing connections will not help you get the chain faster: even when you use 0.6.0rc5, the chain is still downloaded from a single peer, and frequently still not the slowest step. In fact, increasing this number is a bad idea for the network, as peers with open incoming ports are not too abundant.

Doing internal transactions directly instead of via the blockchain isn't fractional reserve banking.