Topic: Bitcoin-Qt / bitcoind version 0.8.0 release candidate 1 - page 5. (Read 20790 times)
Does it work with Armory?
All four of the first machines are running just fine.
I did another test on a more recent CPU plenty of ram running Windows 7. I let it run overnight and download the whole blockchain. This morning I ran windows updates that were pending and prepared for a reboot. The block chain had not finished downloading all of the way yet (I used add IP from a local node for all these, probably why my results were faster than most others posted here)
I did a file exit on Bitcoin-qt and got this exception:
These are the last entries in the debug log
I opened Bitcoin back up and it pegged all cores of the CPU for a while. I had some stuff minimizing and maximizing so I'm not sure what the splash screen said that it was doing. This was much longer by a significant amount vs. the other machines when I close Bitcoin and open them back up. In fact, it is still not open now after about 10 minutes and after it opens I'll post more details. But for now, there is a crash on RC1 with Windows 7. It did not crash until I asked it to shut down. I checked the resource usage, Bitcoin-qt was using about a gig of ram, machine has 8 GB and wasn't even at 50% utilization for ram.
I did another test on a more recent CPU plenty of ram running Windows 7. I let it run overnight and download the whole blockchain. This morning I ran windows updates that were pending and prepared for a reboot. The block chain had not finished downloading all of the way yet (I used add IP from a local node for all these, probably why my results were faster than most others posted here)
I did a file exit on Bitcoin-qt and got this exception:
Code:
A fatal error occurred. Bitcoin can no longer continue safely and will quit.
Exception: St9pad_alloc
std:bad_alloc
C:\Program Files\Bitcoin\bitcoin-qt.exe in Runaway exception
These are the last entries in the debug log
Code:
SetBestChain: new best=000000000000018829028b3af6d47eac9dab3f4b233c77aff1ee2262fcd0faaa height=214069 work=687730958631335352866 tx=10451422 date=2012-12-28 19:24:59
SetBestChain: new best=000000000000002aeab1c5b9fc27e14f759ab16a3e4cde600d98718b93e50416 height=214070 work=687743756268435510981 tx=10451918 date=2012-12-28 19:35:21
SetBestChain: new best=000000000000057d76f8d7a62f3de9a874055874614c6423fce82f60b0177d9a height=214071 work=687756553905535669096 tx=10452418 date=2012-12-28 19:40:47
I opened Bitcoin back up and it pegged all cores of the CPU for a while. I had some stuff minimizing and maximizing so I'm not sure what the splash screen said that it was doing. This was much longer by a significant amount vs. the other machines when I close Bitcoin and open them back up. In fact, it is still not open now after about 10 minutes and after it opens I'll post more details. But for now, there is a crash on RC1 with Windows 7. It did not crash until I asked it to shut down. I checked the resource usage, Bitcoin-qt was using about a gig of ram, machine has 8 GB and wasn't even at 50% utilization for ram.
45 minutes later it starts up and finishes the block chain very quickly. I closed it down and opened it back up just fine nice and fast. Not sure what other information I can provide about this but it seems that everything is okay now.
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.
Will report back once it's done.
Running great here.
Linux nas1 2.6.33-rc6-00219-gf5c72e7-svn #8 PREEMPT Tue Feb 9 16:38:20 CET 2010 armv5tel GNU/Linux
Wanted to setup an electrum server, did not notice that I downloaded the 0.8.0 source until I recognized the dbcache parameter in this topic.
tl;dr bitcoind with electrum-patch runs fine on armv5 and old kernel
Linux nas1 2.6.33-rc6-00219-gf5c72e7-svn #8 PREEMPT Tue Feb 9 16:38:20 CET 2010 armv5tel GNU/Linux
Wanted to setup an electrum server, did not notice that I downloaded the 0.8.0 source until I recognized the dbcache parameter in this topic.
tl;dr bitcoind with electrum-patch runs fine on armv5 and old kernel
nice work
All four of the first machines are running just fine.
I did another test on a more recent CPU plenty of ram running Windows 7. I let it run overnight and download the whole blockchain. This morning I ran windows updates that were pending and prepared for a reboot. The block chain had not finished downloading all of the way yet (I used add IP from a local node for all these, probably why my results were faster than most others posted here)
I did a file exit on Bitcoin-qt and got this exception:
These are the last entries in the debug log
I opened Bitcoin back up and it pegged all cores of the CPU for a while. I had some stuff minimizing and maximizing so I'm not sure what the splash screen said that it was doing. This was much longer by a significant amount vs. the other machines when I close Bitcoin and open them back up. In fact, it is still not open now after about 10 minutes and after it opens I'll post more details. But for now, there is a crash on RC1 with Windows 7. It did not crash until I asked it to shut down. I checked the resource usage, Bitcoin-qt was using about a gig of ram, machine has 8 GB and wasn't even at 50% utilization for ram.
I did another test on a more recent CPU plenty of ram running Windows 7. I let it run overnight and download the whole blockchain. This morning I ran windows updates that were pending and prepared for a reboot. The block chain had not finished downloading all of the way yet (I used add IP from a local node for all these, probably why my results were faster than most others posted here)
I did a file exit on Bitcoin-qt and got this exception:
Code:
A fatal error occurred. Bitcoin can no longer continue safely and will quit.
Exception: St9pad_alloc
std:bad_alloc
C:\Program Files\Bitcoin\bitcoin-qt.exe in Runaway exception
These are the last entries in the debug log
Code:
SetBestChain: new best=000000000000018829028b3af6d47eac9dab3f4b233c77aff1ee2262fcd0faaa height=214069 work=687730958631335352866 tx=10451422 date=2012-12-28 19:24:59
SetBestChain: new best=000000000000002aeab1c5b9fc27e14f759ab16a3e4cde600d98718b93e50416 height=214070 work=687743756268435510981 tx=10451918 date=2012-12-28 19:35:21
SetBestChain: new best=000000000000057d76f8d7a62f3de9a874055874614c6423fce82f60b0177d9a height=214071 work=687756553905535669096 tx=10452418 date=2012-12-28 19:40:47
I opened Bitcoin back up and it pegged all cores of the CPU for a while. I had some stuff minimizing and maximizing so I'm not sure what the splash screen said that it was doing. This was much longer by a significant amount vs. the other machines when I close Bitcoin and open them back up. In fact, it is still not open now after about 10 minutes and after it opens I'll post more details. But for now, there is a crash on RC1 with Windows 7. It did not crash until I asked it to shut down. I checked the resource usage, Bitcoin-qt was using about a gig of ram, machine has 8 GB and wasn't even at 50% utilization for ram.
The *nix x64 binary works wonderfully on Ubuntu 12.04 64bits.
It even solved the status bar icon/menus not showing problem.
Downloaded and verified the complete blockchain in less than 5 hours on a 2.2GHz Pentium dual-core laptop with 4GB RAM.
It even solved the status bar icon/menus not showing problem.
Downloaded and verified the complete blockchain in less than 5 hours on a 2.2GHz Pentium dual-core laptop with 4GB RAM.
bitcoind 0.8.0rc1 64bit on debian squeeze. Started a fresh download of the blockchain, came back five hours later, it was downloaded up to the present block. No hitches to report. Sweet!
My PC: Windows 7 with an old Intel Quad-Core. 4 GB memory. 7200 RPM regular hard drive. Decent computer.
First impressions: the reindexing is fairly fast. I've now been at it for a little more than 1,5 hours and there are only 2800 blocks left. However, at around the 5000 blocks left mark, my PC started lagging big time. I checked that CPU usage (with a quad-core OC'd to 3 ghz) was pretty much 100% and there was 0 memory free. Low usability of the computer, barely usable.
That's it for now, I will keep it running for a good while to see how it works.
Edit: The last few thousand blocks went fairly quickly as well. Total reindex took 2hrs approx. Now I'll just keep it running.
First impressions: the reindexing is fairly fast. I've now been at it for a little more than 1,5 hours and there are only 2800 blocks left. However, at around the 5000 blocks left mark, my PC started lagging big time. I checked that CPU usage (with a quad-core OC'd to 3 ghz) was pretty much 100% and there was 0 memory free. Low usability of the computer, barely usable.
That's it for now, I will keep it running for a good while to see how it works.
Edit: The last few thousand blocks went fairly quickly as well. Total reindex took 2hrs approx. Now I'll just keep it running.
Testers:
Another good, simple test: leave it running for 24+ hours, especially on Windows.
This helps verify longer term stability, and verifies that it keeps up with the network.
There had been some crash reports early in development, on Windows. Pretty sure those are solved, but extra testing through normal use cannot hurt.
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?
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?
Please test! Even an "it works for me" report is useful (just make sure to include your OS version and other helpful details in your "it works" post...)
In the spirit of this:
Deleted complete blockchain, upgraded: Blockchain downloaded in under 4 Hours
Send / receive works fine.
No Bugs seen so far.
Awesome Work.
OS: Win 7
Edit:
Testers:
Another good, simple test: leave it running for 24+ hours, especially on Windows.
This helps verify longer term stability, and verifies that it keeps up with the network.
There had been some crash reports early in development, on Windows. Pretty sure those are solved, but extra testing through normal use cannot hurt.
My PC runs 24/7. I will post if I have any crashes. (None so far)
Successfully updated on Win7x64. Reindexing took a couple of hours, and the last 5000 blocks or so pegged the cpu. Also brought up testnet from scratch in under 12 minutes. Well done everyone!
It works for me, self-compiled bitcoin-qt v0.8.0-rc1 from git on Ubuntu 12.10 64bit.
I tested migration by re-indexing once and also completely downloading the block chain once. Also a couple of payments both directions.
Specifically, tested Bloom Filtering a lot, in combination with Bitcoin Wallet for Android (bloom enabled previews can be downloaded here).
I can say that bitcoin-qt is a lot faster, I'd even say it jumped from unusable to very well usable. Good work everyone!
I tested migration by re-indexing once and also completely downloading the block chain once. Also a couple of payments both directions.
Specifically, tested Bloom Filtering a lot, in combination with Bitcoin Wallet for Android (bloom enabled previews can be downloaded here).
I can say that bitcoin-qt is a lot faster, I'd even say it jumped from unusable to very well usable. Good work everyone!
I ran bitcoind 0.8rc provided 64bit linux binary (with -dbcache=1000), it synced in just 1 hour using single connection to locally running bitcoind 0.7, while being responsive to RPC queries all the time. I like it 
Quick question regarding this. Does importprivkey still work? It rescans the block chain to see if it has been used, would this still work with the way it stores the historical transaction ids? Or would I need to use the txindex=1 if I plan on importing keys?
No problem - rescan just goes through all old blocks again, one by one. Those are still available in 0.8. The only thing that changes is that no information in the index is kept about spent transactions, so without txindex, it's impossible to find a transaction given just its txid. In practice, really the only thing affected is the getrawtransaction RPC.
Oh duh, I knew that. I've read what we are doing here and also about light nodes. I mistook the spent tx as creation of a light node. My mistake. I understand now. The bloom feature is groundwork for a light node. I'm going to test on another windows machine and a linux machine later. But so far I love what I see.
This really opens up the, hey, download bitcoin and try it out I'll send you some coins instead of; hey, check out bitcoin, but get an alternate client because of the official one takes too long.
Quick question regarding this. Does importprivkey still work? It rescans the block chain to see if it has been used, would this still work with the way it stores the historical transaction ids? Or would I need to use the txindex=1 if I plan on importing keys?
No problem - rescan just goes through all old blocks again, one by one. Those are still available in 0.8. The only thing that changes is that no information in the index is kept about spent transactions, so without txindex, it's impossible to find a transaction given just its txid. In practice, really the only thing affected is the getrawtransaction RPC.
Quote
This release no longer maintains a full index of historical transaction ids
by default, so looking up an arbitrary transaction using the getrawtransaction
RPC call will not work. If you need that functionality, you must run once
with -txindex=1 -reindex=1 to rebuild block-chain indices (see below for more
details).
by default, so looking up an arbitrary transaction using the getrawtransaction
RPC call will not work. If you need that functionality, you must run once
with -txindex=1 -reindex=1 to rebuild block-chain indices (see below for more
details).
Quick question regarding this. Does importprivkey still work? It rescans the block chain to see if it has been used, would this still work with the way it stores the historical transaction ids? Or would I need to use the txindex=1 if I plan on importing keys?
I've tested on a couple of set up of windows:
Windows XP New install, download block chain: Works okay. Much faster than previous versions on downloading.
Windows 7 New install, download block chain: Works okay. Much faster than previous versions on downloading.
Windows XP block chain was at about 190,000 never finished downloading because it took too long for what this used to be used for. Took about an hour minutes to reindex what it had then it downloaded the rest nice and quickly. This was an older P4 machine.
Windows 7, had full block chain. It reindexed fine nice and fast in about an hour. I did notice during the first 3/4 of the block chain it didn't really use extra CPU. It's near the end when it started to crank up the engine. This machine was a more modern machine multiple cores and I set the dbcache to 2000.
i'm just curious, are there plans to speed up the data transfer rates? on weaker connections like mine, it will still take a long time to sync. this applies even more to less well connected 3rd world countries!
There are known problems with the current block synchronisation mechanism. Not exactly a bug, but just a crappy implementation. It's certainly intended to be changed, but it's not a trivial thing to do. Using the bootstrap.dat torrent, or using -connect=
1. Can we now delete the legacy blk000x.dat behemoth files?
Yes, you can if you don't intend to downgrade to 0.7.x (or below) code anymore. Note that the old and the new block files are hardlinked on supported platforms/filesystems, so you won't actually gain any space by deleting them. You can however delete blkindex.dat.
What's the disk space requirement of LevelDB vs the old BDB? (In percent.)
There's no simple answer to this, as it's not just a change from BDB to LevelDB: the actual layout and organisation of the databases changed as well. The actual blocks haven't changed (they are in different, more and smaller files, but the data is the same). The old blkindex.dat (BDB, ~1650 MiB) was replaced by:
- the block index (LevelDB, $DATADIR/blocks/index, ~ 30 MiB)
- the chain state (LevelDB, $DATADIR/chainstate, ~ 170 MiB)
- the undo data (custom format, $DATADIR/blocks/rev*.dat, ~ 700 MiB)
Gavin, there's a typo
You actually want the content of blktree end up in blocks/index, so it should read
Quote
1. Subdirectories in the data directory changed names; to avoid re-indexing
the blockchain, rename:
mv $DATADIR/blktree $DATADIR/blocks/index
mv $DATADIR/coins $DATADIR/chainstate
the blockchain, rename:
mv $DATADIR/blktree $DATADIR/blocks/index
mv $DATADIR/coins $DATADIR/chainstate
You actually want the content of blktree end up in blocks/index, so it should read
Quote
mv $DATADIR/blktree/* $DATADIR/blocks/index
Strictly speaking, it is not a typo; $DATADIR/blocks simply has to exist first, in order for it to work.
So the instructions need "mkdir $DATADIR/blocks"
Jump to: