|
Title: Odd bug, Bitcoin-qt progress bar uses checkpoint 140700 instead of current block Post by: deepceleron on February 10, 2012, 08:21:58 AM I'm running additional Bitcoin installs, and am having them connect only to my main Bitcoin that is on the net with the bitcoin.conf option:
connect=192.168.1.xx:8333 Bitcoin doesn't seem to be able to determine the current blockchain height/block number though, it looks like it is just using the checkpoint in the code. After it passes block 140700, the progress bar completely disappears, even though it is still downloading blocks. How does Bitcoin determine the current block, and why can't it get it from my local node running 0.5.2? Verified in 0.5.2 and 0.6rc1. Unrelated: It's now four hours for a core 2 quad to process the blockchain off a local connection, and it really starts bogging down around block 120000... I wonder if the biggest part of this isn't the database indexing. I also realized that we have added 200MB to the blockchain in two months, the blk0001.dat is now about 1GB. At 2GB (http://en.wikipedia.org/wiki/Large_file_support) it may start causing problems for some users, but at 4GB, real big problems, as that is the file size limit for FAT32 systems. Time to start planning for multiple databases for storing the blockchain before this happens. Another line so the above doesn't look like a sig... Title: Re: Odd bug, Bitcoin-qt progress bar uses checkpoint 140700 instead of current block Post by: gmaxwell on February 10, 2012, 02:19:29 PM How does Bitcoin determine the current block, and why can't it get it from my local node running 0.5.2? It's not a bug, its a feature. The client hears about it in the version messages, but it can't just trust it or some trouble maker will claim that the height is ten trillion. So, IIRC it takes a median and won't provide one if you only have a few peers. If it doesn't have an estimate from the peers it uses the highest checkpoint. Title: Re: Odd bug, Bitcoin-qt progress bar uses checkpoint 140700 instead of current block Post by: SomeoneWeird on February 10, 2012, 02:21:33 PM How does Bitcoin determine the current block, and why can't it get it from my local node running 0.5.2? It's not a bug, its a feature. lmao Title: Re: Odd bug, Bitcoin-qt progress bar uses checkpoint 140700 instead of current block Post by: btc_artist on February 10, 2012, 02:53:56 PM How does Bitcoin determine the current block, and why can't it get it from my local node running 0.5.2? It's not a bug, its a feature. lmao Title: Re: Odd bug, Bitcoin-qt progress bar uses checkpoint 140700 instead of current block Post by: gmaxwell on February 10, 2012, 04:52:07 PM I also realized that we have added 200MB to the blockchain in two months, the blk0001.dat is now about 1GB. At 2GB (http://en.wikipedia.org/wiki/Large_file_support) it may start causing problems for some users Sorry, Missed this part the first time. The file will automatically split. Thus the 0001. :) Title: Re: Odd bug, Bitcoin-qt progress bar uses checkpoint 140700 instead of current block Post by: deepceleron on February 10, 2012, 05:50:54 PM How does Bitcoin determine the current block, and why can't it get it from my local node running 0.5.2? It's not a bug, its a feature. The client hears about it in the version messages, but it can't just trust it or some trouble maker will claim that the height is ten trillion. So, IIRC it takes a median and won't provide one if you only have a few peers. If it doesn't have an estimate from the peers it uses the highest checkpoint. That sounds like a bugfix that was put in 0.6, IIRC. I might have to bust out zee code and see how it works, though it may be a lot longer for me to understand it than for the person who wrote it to tell me. Title: Re: Odd bug, Bitcoin-qt progress bar uses checkpoint 140700 instead of current block Post by: gmaxwell on February 11, 2012, 12:16:33 AM That sounds like a bugfix that was put in 0.6, IIRC. I might have to bust out zee code and see how it works, though it may be a lot longer for me to understand it than for the person who wrote it to tell me. Nope. |