The checkpoint for this release is 216116, the current block is 220944. Full verification is done on block contents after the checkpoint, so it is expected to run slower on the last 4000 blocks.

I just finished an upgrade of a previously synchronized Bitcoin 0.7.2 on Win7, it took 70 minutes from startup to "up to date".

The Win32 client reports being built with Qt 4.8.3, the current release is v4.8.4, and has a good many fixes.

I can see the problem already. This "download dependencies and bitcoin" script is made for CentOS5/Bitcoin0.6 and hasn't been updated. It gets the "master" branch of Bitcoin which is the newest alpha/nightly commited code. Several large changes have been made requiring different libraries, especially the need for leveldb.

You should change the "tarball" in centosbuild.sh

mkdir bitcoin-master
cd bitcoin-master
wget -qO- https://github.com/bitcoin/bitcoin/tarball/master --no-check-certificate | tar xzv --strip-components 1
cd src
#cp -vap ~$USERNAME/makefile.new .

to a stable release:

https://github.com/bitcoin/bitcoin/tarball/0.6.3 or
https://github.com/bitcoin/bitcoin/tarball/0.7.2

This script will copy bitcoind to your home directory when it's done compiling, it does not install it for all users.

I can tell you this is absolutely true. The aliens will only reveal themselves to certain people, but as I live on a energy point on the planet, confirmed from the incredible rate of birth defects and people who suddenly develop strange accents, I am able to receive their messages. I was able to use this information to prepare for the false-flag war the citizens are in now with the LAPD and Yemen, and have buried my weapons and supplies at different locations on public lands, and I stocked up on tantalum and yttrium long ago, since we now see the signs that the activist democrat elite who want to abort the children of the truth-seers have sold our future to the Chinese and the printing of paper money to devalue our debts will be the last straw they can pull, and China will use North Korea as a lightning rod for a ploy for global war to get back what they are deserving and enrich the illuminati controlled weapons and prison complex. This is the manipulated opportunity that the assault from above will capitalize on, when the rations are gone and we are eating each other, we will be most vulnerable to the invasion. The weather manipulations at HAARP and the chemtrails in the sky will seem like child's play when the asteroids carrying the egg-pods and DNA of the reptilian third stage of our evolution explode overhead and the earth is terraformed to an ammonia atmosphere that will trigger the mutations in the immunizations we've been given.

https://en.bitcoin.it/wiki/Difficulty

Difficulty * 4295032833.0 / 600 = estimated hash rate

Difficulty = 600 / 4295032833.0 * estimated hash rate (hash/s)

Difficulty = 139.6962545641144970431923866272 * estimated hash rate (Ghash/s)

0.0001 per kB (not KiB) to relay x 22.530kB in size = minimum 0.0023 fee to relay (vs 0.0005 paid). Bitcoin requires the minimum fee if any output is less than 0.01 BTC, which many many are.

You have many addresses in your wallet. Blockchain.info does not know about all your wallet addresses, and cannot tell you your balance. Every time you send a payment, you are likely sending some of your balance back to another of perhaps hundreds of address you own (not shown to you in Bitcoin). This is change.

A. I just received a 1 BTC payment to address 1aaaa, now my wallet has 1 BTC.
B. I send .5 BTC to SatoshiRockPaperScissors, but the entire 1 BTC payment (input) must be sent, so a second hidden payment (output) is sent back to me at address 1bbbb in my wallet,
C. My Bitcoin client now shows my balance is 0.5 BTC, but it doesn't tell me the actual addresses behind-the-scenes that contains what amounts.
D. I look up my 1aaaa address balance on some website, and it says 0 BTC.

The unconfirmed coins shown in your screen shot add up to about 2BTC. Until these payments confirm by being included in a block, your actual Bitcoin balance is 2 BTC more than what is shown. Your local Bitcoin considers sent coins as reserved and spent even if unconfirmed though, and doesn't have a mechanism to cancel out a sent payment nor transmit a message to other Bitcoins to cancel the payment. This prevents you from double-spending yourself, because a miner might finally include the long chain of payments that funded all these, even after many days later. BTC4Amazon might eventually get the original payment, so re-sending another payment is not wise.

You should not send money without the Bitcoin client completely sync'd to the current network block, that is one way to cause a double spend.

There is one straightforward way to clean up all the unconfirming payments. You double-spend them yourself:

1. use a tool like pywallet to remove the exact transaction numbers of any unconfirmed payments to and from you from your wallet,
2. relaunch Bitcoin with the -resync command line option to correct your balance, verify all the unconfirmed transactions are gone,
3. in Bitcoin options, add some voluntary fee to all payments, like 0.01,
4. create a new receiving address in your wallet, and send your entire balance to this new address, only after the blocks are updated and you have several network connections.
5. voila, all those unconfirmed payments on the network you sent are "cancelled" and will never complete, as your good transaction has spent all your existing payments inputs.

You can't make other people's unconfirmed payments to you go any faster. They may never complete if they didn't include a fee or are attempting to double-spend-attack you.

ldd /usr/lib/bitcoin/bitcoind
        linux-gate.so.1 =>  (0xb7772000)
        libboost_system.so.1.46.1 => /usr/lib/libboost_system.so.1.46.1 (0xb7759000)
        libboost_filesystem.so.1.46.1 => /usr/lib/libboost_filesystem.so.1.46.1 (0xb773b000)
        libboost_program_options.so.1.46.1 => /usr/lib/libboost_program_options.so.1.46.1 (0xb76db000)
        libboost_thread.so.1.46.1 => /usr/lib/libboost_thread.so.1.46.1 (0xb76c4000)
        libdb_cxx-4.8.so => /usr/lib/i386-linux-gnu/libdb_cxx-4.8.so (0xb7525000)
        libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0 (0xb74cf000)
        libcrypto.so.1.0.0 => /lib/i386-linux-gnu/libcrypto.so.1.0.0 (0xb7324000)
        libminiupnpc.so.8 => /usr/lib/libminiupnpc.so.8 (0xb7317000)
        libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb72fc000)
        libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7217000)
        libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb71eb000)
        libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb71cd000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7022000)
        libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb701d000)
        libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb7007000)
        /lib/ld-linux.so.2 (0xb7773000)
 
Make sure you have all the shared library dependencies required, and of the correct version bitcoin was built with if you aren't compiling yourself.

Price reduced since BTC value went up, and is comparable to completed eBay prices for used 64GB SSD.

Corrupting a wallet is almost expected eventually if you continue to kill Bitcoin while downloading blocks. The last-seen block hash is written to the wallet every block, which means the wallet is sometimes updated dozens of times a second while downloading blocks that fast.

Did Bitcoin attempt to automatically salvage the wallet, and was this successful? I noted and filed an issue where you continue to get warning messages every launch after a wallet salvage was performed.

Muphry's law.

So they will communicate with you in Japanese or English, and you complain in run-on uncapitalized sentences without a single punctuating mark in your "native" language?

頭がいい人には日本語の書き方も習やすいそうです。

I'll move this over here for more discussion of Torrent 2.0


"The 2GB issue", failure to import blocks after 2.0GiB on 32 bit builds, was reported by me, so I guess I'm the one that "raised" it here. Now that Bitcoin can actually use a bigger torrent and 0.8.0 has a higher checkpoint, it's finally time for a new torrent!

You should get the same 4.8GB bootstrap.dat SHA256 at that height, if you don't, we've got a big problem!

The only thing that would make a torrent I create less than "semi-official" would be if I make a compressed torrent without consensus. I am slowly convincing myself even more that a compressed torrent is preferable though. Without compression you are downloading the same amount of data as normal p2p. The compressed binary would only be repeatable on the exact xz/lzma/7zip build version and settings, but I think there are probably four people total that have run mkbootstrap anyway, so this is not important. It takes about an hour to smash the blockchain down to 60% the size at the extreme settings I've used over many trials to optimize settings.

Compressed-Pros:
-2000+ MB of uploading and downloading saved for every user,
-2000+ MB less storage used when seeding,
-won't cause problems if torrent HDD is FAT32 (under 4.0GB for now)

Compressed-Cons:
-Not as simple to use, end-user must decompress with third-party utility (although 7-zip is common and opens xz),
-More work creating torrent (doesn't matter to end-users),
-Cannot "update" torrent by simply replacing data file with newer version with additional blocks (likely to be a rare practice anyway, I am the only one seeding the old torrent right now).

Here is example compression, both require about an hour (but decompress in minutes):

xz utils 5.0.4/Win64, 3GB+ RAM required to compress (2,780,285,148 bytes)
xz --compress --keep --format=xz --check=sha256 --verbose --lzma2=dict=256MiB,nice=273,mf=bt4 bootstrap.dat

7-zip GUI win64 - 6GB+ RAM required to compress (2,769,830,975 bytes)
Format: 7z, Compression Level: Ultra, Compression method: LZMA, Dictionary size: 384MB, Word Size 273

The blockchain checkpoint in this release has been updated to 216116. I created a bootstrap.dat of this height and successfully imported it in 37 minutes with bitcoin-qt on Win7 64 bit. This bug appears quashed: https://github.com/bitcoin/bitcoin/issues/1951

Using one of the fastest SSDs made, Bitcoin is CPU-limited and thread-limited, holding one CPU core at 100%, and blipping a second core to ~75% every few seconds.

02/10/2013  08:44 PM     4,855,459,871 bootstrap.dat
SHA256: bf658c7055b733bfc15ea167f298c5599b89d220b14dbe7c8ef20b18e468c451 *bootstrap.dat


I will offer this as a torrent and also give direct-download links to those who wish to jump-start and seed such a torrent, since my seeding speed is limited. The question is, should an official torrent going forward be a compressed file? Using the highest compression preset with xz/lzma (installed with most distros, opens with 7-zip or MacOS GUI tools) saves 2GB of downloading, so I say yes:

02/11/2013  01:09 AM     2,780,285,148 bootstrap.dat.xz

Also, bootstrap.dat is too big for FAT32, but not the compressed version. Bitcoin 0.9+ could even (feature request) open a compressed bootstrap (lzma is a stream container) directly if standardized.

I'm just going to leave this here:

http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality

You really didn't read anything in this thread, did you?

One should always calculate and store in integer base units when dealing with Bitcoin amounts. Pool operators and other sites that have previously stored values in floats have been shamed out of existence.

The only time it would be even close to acceptable would be if you are dividing or multiplying by a non-integer and want to maintain an even higher degree of accuracy internally in accounts (such as my $0.00000 in mtgox), and then you must ensure that your platform and any other that may run your code will store in IEEE 754 double floats or greater.

Another way bitcoin was more thought out than you may understand: There will be a maximum of 0x775F05A074000 bitcoin base units ever in existence, which is a 51 bit number. From wikipedia "'double precision' (64-bit) binary floating-point number has a coefficient of 53 bits (one of which is implied), an exponent of 11 bits, and one sign bit.".

Kingston SSDNow V100 Series SV100S2N/64GZ 2.5" 64GB SATA II Internal Solid State Drive
Includes 2.5"->3.5" mounting rails.

Flashed to latest firmware, secure wiped. Still under 3 year warranty.

2.5 BTC shipped USA. Note, "shipped" includes $12.35 postage for priority mail flat rate box.



Since you are looking, Pentium 4 640 CPU - Socket 775, 2M Cache, 3.20 GHz, 800 MHz FSB
This is a newer P4, make sure your motherboard has BIOS support for the newest models.

http://ark.intel.com/products/27480/Intel-Pentium-4-Processor-640-supporting-HT-Technology-2M-Cache-3_20-GHz-800-MHz-FSB
0.5 BTC shipped.

If you are talking about different users in a household, you only need create other user accounts in your operating system. Locking down/encrypting user directories is optional depending on how much you trust local users.

Bitcoin stores it's data in a user's profile on both Windows and Linux (probably Mac too). If someone logs in with a different user name and launches Bitcoin, it will create a new %APPDATA%\Bitcoin for that account with it's own wallet, blockchain, etc. You can speed up the initial download by doing a copy %APPDATA%\Bitcoin\BLK*.DAT C:\Users\LittleJohnny\AppData\Roaming\Bitcoin to each additional user account's profile.

You'd have a hard time figuring out what addresses to remove. If you make a script to "remove addresses with 0 balance and all their transactions if they previously received coins", it may remove persistent receiving addresses like 1gweedo, etc, and such a task would only work correctly if the information in the wallet is actually correct. It would be much better to just dump the private keys of addresses you want to keep and send the balance to a new wallet.

Get a less sucky version of python for mac: http://docs.python.org/2/using/mac.html

Download pywallet by clicking on the blue word pywallet.py on the page https://github.com/joric/pywallet

On the same page, click on the blue word README and read some stuff

Close Bitcoin, back up your wallet.dat

open a console window, change to the directory where you downloaded, type pywallet.py --web

Go to the super-secret web site at http://127.0.0.1:8989/

Under "Delete a key from your wallet:", put in the hash of the transaction you want to delete


Alternately, type "pywallet delete transaction" into Google and go to the first result.