Bitcoin-Qt / bitcoind version 0.8.0 release candidate 1

[Diapolo]

It even solved the status bar icon/menus not showing problem.

I remember there was an open issue on Github, was that yours? Perhaps you can add that update there and close the ticket.

Thanks,
Dia

[1714997692]

1714997692

[1714997692]

1714997692

[1714997692]

1714997692

[1714997692]

1714997692

[Raoul Duke]

It even solved the status bar icon/menus not showing problem.

I remember there was an open issue on Github, was that yours? Perhaps you can add that update there and close the ticket.

Thanks,
Dia

I thought that was solved. It seems it isn't. Just now opened it again and the icon and menus are gone, despite being there the previous 5 or 6 times I started Bitcoin-Qt 0.8.0-RC1 since I installed it.

[Diapolo]

It even solved the status bar icon/menus not showing problem.

I remember there was an open issue on Github, was that yours? Perhaps you can add that update there and close the ticket.

Thanks,
Dia

I thought that was solved. It seems it isn't. Just now opened it again and the icon and menus are gone, despite being there the previous 5 or 6 times I started Bitcoin-Qt 0.8.0-RC1 since I installed it.

Too bad ... seems to be a Qt or OS UI issue though.

Dia

[foo]

Upgraded from 0.7.1 on Windows XP - smooth sailing so far. Syncing is now CPU-limited with very little thrashing of the hard drive, nice work!

[mmortal03]

Am testing it now, completely fresh install on a netbook, Windows 8 64-bit, AMD E-350, 6 GB of RAM, 5400 rpm hard drive, using -dbcache=2000.

Will report back once it's done.

Bummer, midway through downloading the blockchain, with -dbcache=2000, it kept using up RAM all the way to 4GB and then crashed.

On restart, it sits at the wallet picture with "xporting blocks from block databas" (text cut off on left and right hand side).  I can see from the Task Manager that it's doing something, pegged CPU at 50%, and increasing RAM. I'll let it sit and see where it goes.

Edit: It finally came out of the splash screen and CPU usage dropped to normal, but RAM is still increasing. I've got it set to -dbcache=1000 this time, so we'll see if it sticks to that.

[wtfvanity]

The crash-on-exit bug could be this issue:  https://github.com/bitcoin/bitcoin/issues/2204

We may have to live with it for the 0.8 release, and fix it in the next release, because there is a high risk that fixing it will cause more problems than it solves.

Not sure if this is exactly what happened, but it only did it on one machine. After it started back up, it is now working fine. I closed it after it caught up to the block chain and no error. I closed out of one other instance of bitcoin and it didn't error. Opened it back up. I'm going to leave one running and the other three I'm going to close every 24 hours or so and see if it opens up again. Besides giving it extra work the first time it closed, it didn't look like it really had any other side effects.

If there is anything I can do to help squash it or test it, let me know. The ones that don't reproduce consistently are difficult. This machine has identical specs as the other Win 7 machine and the first one didn't do it. Not sure.

[inglian]

All good with bitcoin-0.8.0rc1-win32

• Windows 7
• HP 8440 laptop with 4 cores
• 8GB RAM
• FiOS connection

Good upgrade from 0.7.1-353-g3afefd8-win32

With an empty data directory and bootstrap.dat, 3h 40m to current blockheight. Multithreading doesn't seem to start until after bootstrap.dat is loaded.

Good upgrade from 0.7.2. Reindexing completed through blockheight 216274 in 37m. Update to current block from the network had long periods with no data coming in, but did show good multithreading when data was arriving.

[Grami]

Ubuntu 12.10 64bit. Bitcoin-qt crashed on initial blockchain download (process killed). After program restart - main window doesnt show. After system reboot - works fine.

[deepceleron]

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

Code:

2013-02-11 06:35:35 SetBestChain: new best=000000000000044263dc2253bdd2a31a4194ae13321b25e41f422e148c417cec  height=216113  work=714355361457244290318  tx=11010043  date=2013-01-11 10:45:37
2013-02-11 06:35:35 ProcessBlock: ACCEPTED
2013-02-11 06:35:35 SetBestChain: new best=0000000000000234440faa3ee1a84b457e5f79515a2b19853d7e72422e3183f0  height=216114  work=714369318379402124429  tx=11010572  date=2013-01-11 10:56:20
2013-02-11 06:35:35 ProcessBlock: ACCEPTED
2013-02-11 06:35:35 SetBestChain: new best=00000000000000f97afdf8ccba49919bb998313ec67e3654798b86a3f6631c1e  height=216115  work=714383275301559958540  tx=11010714  date=2013-01-11 10:59:18
2013-02-11 06:35:35 ProcessBlock: ACCEPTED
2013-02-11 06:35:35 connection timeout
2013-02-11 06:35:36 SetBestChain: new best=00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e  height=216116  work=714397232223717792651  tx=11011160  date=2013-01-11 11:11:30
2013-02-11 06:35:36 ProcessBlock: ACCEPTED
2013-02-11 06:35:36 Loaded 216116 blocks from external file in 2218342ms

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.

[jgarzik]

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/10/2013  08:44 PM     2,841,903,993 bootstrap.dat.lzma

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.

This would make a useful contribution to this thread,

   [BETA] Bitcoin blockchain torrent
   https://bitcointalk.org/index.php?topic=117982.0

The semi-official bootstrap.dat torrent is about to be updated, as it is for each bitcoin release.  The 2GB issue has already been raised in that thread, and the FAT32 4GB issue would also be a good one to raise.

Ideally we would like everyone to seed the same torrent -- it's the same data, as guaranteed by bitcoin (as well as torrent) hashes.

[caveden]

Thank you all for this development. This version is a major one for scalability, with bloom filters and the pruned index.

However, this release includes a bug
fix that makes it a little bit more difficult for attackers to double-spend a
certain type ("lockTime in the future") of zero-confirmation transaction.

Could somebody point me to some clarification on what exactly does this means?
Because, AFAIK, time locked transactions should be reversible, up until the block they are supposed to be included. That's the whole point of time locking, isn't it?

[Mike Hearn]

Yes that's how they're supposed to work. However that functionality is disabled.

[jonathan]

reporting back in from a debian squeeze box running bitcoind 0.8.0rc1-linux 64bit.

bitcoind has been running fine for over 24 hours. I just closed it down then started it again. All working, fast and smooth. No problems to report here.

[caveden]

Yes that's how they're supposed to work. However that functionality is disabled.

What does "disabled" means?
Does it means that bitcoind gives you no way to deal with nLockTime, but if some miner accepts, relays and mines them, his blocks will be accepted?

[jgarzik]

Yes that's how they're supposed to work. However that functionality is disabled.

What does "disabled" means?
Does it means that bitcoind gives you no way to deal with nLockTime, but if some miner accepts, relays and mines them, his blocks will be accepted?

Blocks only contain "final" transactions, and by definition, a transaction with non-zero nLockTime is not final.  Transaction replacement occurs before miners mine blocks.

Thus, to answer your question, such a miner's blocks would be rejected as invalid by all existing versions of bitcoin software.

[caveden]

Blocks only contain "final" transactions, and by definition, a transaction with non-zero nLockTime is not final.  Transaction replacement occurs before miners mine blocks.

Thus, to answer your question, such a miner's blocks would be rejected as invalid by all existing versions of bitcoin software.

That was not exactly my question (I meant time-locked tx after their time locking expires) but never mind, I got an answer in the other thread. Thanks,

[phatsphere]

hi, i did some unethical "stress testing". Deleted all the data, started to re-download everything. after some time, i repeatedly killed it via pkill -9 bitcoin. well, that worked fine.

then I started to delete some random files and now it no longer loads!

What I would expect is to detect a corrupt database, some re-indexing action, or just a nice notice that it has to redo everything due to corruption. instead:

a box "error initializing block database" -> OK -> core dumped :-(

the random files i deleted:

Code:

rm ./blocks/index/000189.sst ./chainstate/000012.sst

debug.log:

Code:

Bitcoin version v0.8.0rc1-beta (2013-02-06 16:06:43 -0500)
Using OpenSSL version OpenSSL 0.9.8k 25 Mar 2009
Startup time: 2013-02-11 11:12:57
Default data directory /users/XXX/.bitcoin
Used data directory /users/XXX/.bitcoin
Using 2 threads for script verification
init message: Verifying wallet integrity...
dbenv.open LogDir=/users/XXX/.bitcoin/database ErrorFile=/users/XXX/.bitcoin/db.log
Bound to [::]:8333
Bound to 0.0.0.0:8333
init message: Loading block index...
Opening LevelDB in /users/XXX/.bitcoin/blocks/index
Opened LevelDB successfully
Opening LevelDB in /users/XXX/.bitcoin/chainstate
Opened LevelDB successfully
LoadBlockIndex(): last block file = 0
LoadBlockIndex(): last block file: CBlockFileInfo(blocks=86483, size=37352096, heights=0..86479, time=2009-01-03..2010-10-20)
LoadBlockIndex(): transaction index disabled
LoadBlockIndex(): hashBestChain=00000000001aa62850aea3dda34b3a9af269a0cac44c3ea481206bdfdf5dfd91  height=79504 date=2010-09-13 13:05:59
Initializing databases...
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
CBlock(hash=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, ver=1, hashPrevBlock=0000000000000000000000000000000000000000000000000000000000000000, hashMerkleRoot=4a5e1e4baa, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1)
  CTransaction(hash=4a5e1e4baa, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, 4294967295), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73)
    CTxOut(nValue=50.00000000, scriptPubKey=04678afdb0fe5548271967f1a67130)
  vMerkleTree: 4a5e1e4baa 
ERROR: AddToBlockIndex() : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f already exists
ERROR: LoadBlockIndex() : genesis block not accepted

PS: relevant files that are still alive:

Code:

./chainstate/000022.log
./chainstate/000015.sst
./chainstate/MANIFEST-000021
./chainstate/CURRENT
./chainstate/LOCK
./chainstate/000013.sst
./chainstate/LOG
./chainstate/LOG.old
./blocks/rev00000.dat
./blocks/blk00000.dat
./blocks/index/MANIFEST-000221
./blocks/index/000188.sst
./blocks/index/000222.sst
./blocks/index/000223.log
./blocks/index/000191.sst
./blocks/index/000216.sst
./blocks/index/000219.sst
./blocks/index/CURRENT
./blocks/index/LOCK
./blocks/index/000224.sst
./blocks/index/000190.sst
./blocks/index/000187.sst
./blocks/index/000211.sst
./blocks/index/LOG
./blocks/index/000213.sst
./blocks/index/LOG.old

PPS: and after deleting everything, I also had a corrupted wallet. (nothing lost, don't worry, but just let you know that for some reason, it got corrupted during that  treatment! likely (?) due to the forced shutdown while it was still open). … and yes, it was fine before, and it's size was around 100k before and afterwards.

[mmortal03]

Am testing it now, completely fresh install on a netbook, Windows 8 64-bit, AMD E-350, 6 GB of RAM, 5400 rpm hard drive, using -dbcache=2000.

Will report back once it's done.

Bummer, midway through downloading the blockchain, with -dbcache=2000, it kept using up RAM all the way to 4GB and then crashed.

On restart, it sits at the wallet picture with "xporting blocks from block databas" (text cut off on left and right hand side).  I can see from the Task Manager that it's doing something, pegged CPU at 50%, and increasing RAM. I'll let it sit and see where it goes.

Edit: It finally came out of the splash screen and CPU usage dropped to normal, but RAM is still increasing. I've got it set to -dbcache=1000 this time, so we'll see if it sticks to that.

I closed the instance running -dbcache=1000 to see how it would handle it, and it closed no problem. I've restarted it with -dbcache=1500, and have let it run for a while. Memory use is now up to 1,660,316 KB, so, similar to my results using -dbcache=2000 where it went up to 4GB, it doesn't seem to be minding the value chosen in this setting as a limit.

[hazek]

Successfully updated on Win7x64. Reindexing took a 7 hours or so, did it with -dbcache=2000, after it was finished I closed it without a problem and I have since ran it again without that command and it works. I haven't tried sending or receiving anything.


I'd still like to get an answer when, if at all, will there be an option to enter a username and password for a proxy server?

Running now for over 36hours without a problem.

[Technomage]

I've been running it for a good while as well. Many sent and received transactions also. No problems whatsoever.