Bitcoin Forum

I downloaded a wallet last night and its up to just over 130,000 blocks as of now

I also went to http://faucet.bitcoin.st/ last night and got my .01 BTC for free. I did this before all the blocks have been downloaded...so does this mean that I will not get the .01BTC or will I get it later once I have all the blocks? Its taking me about 12 hours to reach 130,000 blocks is this normal?

130.000 is already pretty close to the current block number. Just wait for it to complete (131313 blocks currently).

I don't understand: do you need 130,000 blocks to start receiving bitcoin? ( i have 90,000 now)

I opened a wallet and sent 1BTC from Virwox.com to my bitcoin address and nothing happened. I did not receive my bitcoin and it says "0 transactions". Did I just waste $20??? HELP

If i have understood correctly, then yes, you will first have to download all blocks, because these contain the history of bitcoin. So if virwox made your transaction at the 131431. block, then you will first have to download every block before it to reach your transaction. Don't worry, once it happens (usually 2-3 hours), it won't take long afterwards.

Well every transaction has to be included in the next blocks found on the network. Your client is downloading all of them from the very beginning. It doesn't know yet about any transaction but it probably will as soon as your client is catching up. You should really consider reading into the technical aspects of bitcoin anytime soon. The wiki is a good start. https://en.bitcoin.it/wiki/Main_Page (https://en.bitcoin.it/wiki/Main_Page)

Cool! It just showed up.

It did take me 12 hours to download all the blocks though. Isn't this going to become a huge issue for new users a couple of years from now when it takes days to download all the blocks? What if BTC is still around 100 years from now? How long will it take then?

Wondering that myself  ;D

Just a few seconds because you will have insanely high downloadspeeds in 100 years :)

There are other option available in the future.  Including, but not limited to, simply including a recent copy of the blockchain in each new client release to be downloaded directly rather than over the p2p network and verified by each client upon first start.  It's the verification process that takes most of the time, not the actual downloading.

If they do decide to include the database they better hope it compresses well. My data directory for bitcoin is at 1.8GB and growing. That's only with 131340 blocks AND an empty wallet that has not yet made any transactions. Who knows how big it will be in five years  :o

The other option involves pruning of the blockchain's spent transactions, which is already in the protocol, but not yet safely implimented into the client.  That is why transactions are stored in a merkle hash tree instead of just a flat file with all the transactions hashed once.  The merkle hash tree permits spent transactions to be deleted from the local blockchain without disrupting the verification of other transactions in the same block yet unspent.  The only part of the blockchain that must continue to exist is the headers, which weigh in at 80 bytes exactly for each block.  Roughly 4 megs per year. 

It's sad that the 0.01 from the faucet is only enough to cover a single transaction fee. All that hard work (of typing into a box) for nothing!

Does that not introduce centralization?

Not really, because at this point the client will still verify all the blocks upon first start, regardless of where the blockchain came from.  In the future, there are likely to be clients that come with a blockchain already in it and trust this included blockchain, but that would require trust in the client developers.

That's odd.  Mine is a bit under 450 MB, and that includes some relatively large logfiles as well.

Yes, but if the majority of people (>50%) uses the same client, wouldn't that allow the client developers to "force the network into a different blockchain"?

Here's what I have in the bitcoin directory:

debug.log  595 MB
blk0001.dat  262 MB
blkindex.dat  128 MB
10 other files for 28 MB

In the database directory under the bitcoin directory there are 89 files of 9.5 MB each for a total of 845 MB. Grand Total of all files: 1.858 GB  ???

Do you restart your client often?  The debug.log is just a logfile that is recording events that your client considers notable, such as restarting.  You can delete that without a hickup, and the client will just start another upon the next restart.  blk0001.dat is the actual blockchain while blkindex.dat is the file that your client uses to quickly find a particular transaction within all those blocks.  I would still recommend that you backup your wallet.dat file before deleting anything, though.

Use the latest client version 0.3.23, it reduced the minimum transaction fee to 1/20th of the previous value.

In the future, only a few pool owners, heavy miners, and people with a high number of bitcoins will actually store the blockchain, because it will reach into the TB's of size quite quickly.  Most other users will connect to one or more of these blockchain holders to verify account balances using a lite client (chainless client).

At least, this is what I see happening if there is wider acceptance and use of bitcoins.

According to my process listing (I'm running this under Debian by the way) the client has been running 179 hours, about 7.5 days when I installed it. I just left it open and running on another desktop. I just closed it out and restarted it and it cleaned up about 800MB of data from the database directory. I opened up the debug.log and it appears to be a listing of all IRC traffic that the client generates. Perhaps the next client release can clean up this file as well when the client shuts down?

The debug log exists for development reasons, and having the client automaticly delete the log upon exit would be self-defeating.  I suppose that a startup batch script that destroys the existing debug.log file upon restart wouldn't be too dangerous.  Or you could use the -noirc switch to disable the irc bootstrapping altogether.  You only need it upon the initial startup of a fresh install, or if you wipe out your database.  You don't really need it at all, it just makes finding the ip addresses of the first few connections easier.  After that, node discovery is done via the p2p network itself.  I always use -noirc.  You need to do it if you are using tor or I2P, otherwise the irc code will just leak out your ip address anyway.

This needs to happen within 1 year given current transaction rates.  Blocks have increased in size now that real transactions are being done and a small fraction of blocks (the new blocks) are taking up increasingly larger percentages of the total block size.  Unless bitcoin is deserted, in 1 year it will take over 1 GB to download all of the blocks.  No new users will participate if it takes 1 GB download just to start.

The clock is ticking and what you describe needs to happen now.

Do you really think so?  I download files larger than that via bittorrent for a few hours entertainment.

It is already in progress.  Most of the code is there to allow a lite client, and the pressure will be on to complete it so Bitcoin can be used from mobile devices.

It was a joke, but good to know! :)

In principle, in order for your client to know for a fact that you have some number of bitcoins, it must trace the entire block hash from its creation to the creation of those bitcoins to the block containing the transaction that gave those coins to you. The current client actually does all of this. So if the bitcoins were transferred to you, they will show up when your client catches up. If they don't show up, the transaction could still be unverified. You can check for the complete transaction now using block explorer. The larger the transaction fee and the larger the transaction the sooner it shows up.

You need not be running a client to receive bitcoins. You needn't do anything special to receive bitcoins -- it's the sending that's the active process. Your client will detect them when it catches up to the block that included the transaction.