Tranz, one other question - After it finished syncing, my recent transactions shows the orphans I've generated rather than the most recent transactions. So like it shows 2 orphan transactions from 4/9 and one from 4/7, but if I go to the full transactions list and sort by date then I can clearly see several transactions on 4/10, 4/11, and 4/12 - so why is it randomly deciding to show me those three orphaned mining attempts from 4/9 and 4/7 under recent transactions?
It sorts by status by default. You can resort it by date. You can also do as suggested and run repair wallet, which will remove them. |
|
|
|
well it went from 750k blocks or so remaining to 250k blocks remaining in just a few hours so it seems like the full re-sync doesn't take too long for anyone who was wondering. And, the wallet loads insanely fast now, took about 10 seconds to load for me, great work as always Tranz!!
No problem, just remember once you are done, just do a quick shutdown and make a backup copy of txleveldb and blk001.dat. So you can always get up to speed even faster in the future should something go awry with that computer. |
|
|
|
I have released 1.4.0.1 tonight. I put in on the release page. https://github.com/Tranz5/HoboNickels/releasesThis version will require you to re-index, as the block hash is now added to the index. This speeds up start up time by 10-20x. I personally went from 5 minutes to 15 seconds. The re-index will happen automatically, so if you want to keep your old version of files, please be sure to make a backup for blk001.dat and txleveldb folder before you start this up. I have had mix results from re-indexing from peers. 2 out of 7 times, after I was up to current block and closed and re-opened it. I got the dreaded assert failure. One thing that can be done, to help, is to stop the client every 200k blocks and take a quick snapshot of the blk0001.dat and txleveldb folder. Then start it backup. I have also put a copy for my blk0001.dat and txleveldb folder here http://www.fileswap.com/dl/SnNNULZqH/ You can use this to overlay your files and then you should only have a few thousand blocks to catchup on. md5sum block_chain_backup_April_10_1.4.1.zip 5910921e0633794c15343431ac88e4df *block_chain_backup_April_10_1.4.1.zip These are only compatibly with version 1.4.0.1+ Please let me know if you have any problems. Thanks all! |
|
|
|
Using this is ok. Best to create your own index, but this is safe enough. However you shouldn't replace your database directory, this is used for the wallet.dat. Just need the blk0001.dat and the leveldb directory. Those 2 are for the block chain. wallet.dat and database directory work for the wallet.dat It should have only been syncing about 4 days worth because i gave it my saved complete roaming folder to read however now i let it download complete new blockchain and gave it my "saved database" directory and ".wallet" file and everything seem's fine but i do have a warning saying "checkpoint too old" ?? If it says "checkpoint too old" it means its not something is still wrong. I'll suggest downloading or compiling a new wallet. Do you blocks match the explorer, in height and difficulty? http://162.217.249.198:1080/chains or http://hbn.blockx.info/get/chain/HoboNickelsIf so you are ok. next time you restart the wallet it will go away. If you don't match, (off by many thousand or more) then yes you have some type of issue. |
|
|
|
Using this is ok. Best to create your own index, but this is safe enough. However you shouldn't replace your database directory, this is used for the wallet.dat. Just need the blk0001.dat and the leveldb directory. Those 2 are for the block chain. wallet.dat and database directory work for the wallet.dat |
|
|
|
|
Moving to version 1.4 should not require a re-index. Unless you were on a very old version before.
Was it trying to sync with the whole block chain? Or are we only talking about a few blocks to get to current?
Version 1.4.0.1 will require full re-sync.
|
|
|
|
Good news and bad news. Good news. After fixing a small issue with the Pi, it staked quite easily within 10 minuets of 1500 coins at 20 days weight, after getting up to current. https://cryptocointalk.com/topic/8233-pihobonickels/I am considering loading up a few of these bad boys with version 1.4.0.1 and some coins, and selling them. Fast load time, easy staking, should be perfect for the pi. If you are interested in buying or helping, let me know. Bad News. I am going to release 1.4.0.1 as a pre-release only. I have a been able to create a stable index by shutting down the client every 200k blocks, during initial download. If I let it go from start to finish i get an assert failure on the next shut down, and restart. But all seems fine, if I give it a break. Not sure what is going on, but I wouldn't mind a bit of feed back from the community. I'll put this up tomorrow, so we can get a few tests and feedback in. Thanks! The Pi sounds awesome! I just wish they had expandable RAM! Still considering it though. So small. Version 1.4.01 should not be a problem if you already have the chain downloaded then right? yes. |
|
|
|
Good news and bad news. Good news. After fixing a small issue with the Pi, it staked quite easily within 10 minuets of 1500 coins at 20 days weight, after getting up to current. https://cryptocointalk.com/topic/8233-pihobonickels/I am considering loading up a few of these bad boys with version 1.4.0.1 and some coins, and selling them. Fast load time, easy staking, should be perfect for the pi. If you are interested in buying or helping, let me know. Bad News. I am going to release 1.4.0.1 as a pre-release only. I have a been able to create a stable index by shutting down the client every 200k blocks, during initial download. If I let it go from start to finish i get an assert failure on the next shut down, and restart. But all seems fine, if I give it a break. Not sure what is going on, but I wouldn't mind a bit of feed back from the community. I'll put this up tomorrow, so we can get a few tests and feedback in. Thanks! |
|
|
|
New wallet is working really well for me... now if only the price of HBN would take a dip so that I can load up!
Yes mine has also been very nice. Been testing the new start up, so far it is working. Load time on full block chain with empty wallet was less then 10 seconds. Old version was about almost 5 minutes. Still had a few issue with Asserts, so changed the coding a bit and getting good success. Doing 1 more full network sync test from scratch. If that goes well I will look to move this into production. |
|
|
|
HBN Lesson for the day #1 Why orphans happen? Here is one example as to why you might get an orphan block with PoS. 04/10/14 03:25:33 SetBestChain: new best=0000000005cadad37032 height=746269 trust=1931039688483 date=04/10/14 03:24:40 (peer sent block)
04/10/14 03:25:33 ProcessBlock: ACCEPTED (Block is good)
04/10/14 03:25:33 ProcessSyncCheckpoint: sync-checkpoint at 0000000005cadad37032e692be2124d6d876c423888e9fd8a5e5e7cc09eec4bd (checkpoint agrees)
04/10/14 03:25:34 getblocks -1 to 00000000000000000000 limit 500 (network asks for current block)
04/10/14 03:25:34 getblocks -1 to 00000000000000000000 limit 500 (network asks for current block)
04/10/14 03:25:34 getblocks -1 to 00000000000000000000 limit 500 (network asks for current block)
04/10/14 03:25:34 getblocks -1 to 00000000000000000000 limit 500 (network asks for current block)
04/10/14 03:25:34 getblocks -1 to 00000000000000000000 limit 500 (network asks for current block)
04/10/14 03:25:34 getblocks -1 to 00000000000000000000 limit 500 (network asks for current block)
04/10/14 03:25:34 getblocks -1 to 00000000000000000000 limit 500 (network asks for current block)
04/10/14 03:25:34 getblocks -1 to 00000000000000000000 limit 500 (network asks for current block)
04/10/14 03:25:35 CheckStake() : new proof-of-stake block found ( I find PoS!)
hash: b6dfb34b7df788a
.....
04/10/14 03:25:36 SetBestChain: new best=b6dfb34b7df788a9f841 height=746270 trust=1931056500073 date=04/10/14 03:25:30 (I accept my own block as valid)
04/10/14 03:25:36 ProcessBlock: ACCEPTED (looks good by me, from me!)
04/10/14 03:25:36 getblocks 746270 to 00000000000000000000 limit 500 (network wants the block)
....
04/10/14 03:25:38 REORGANIZE (uh oh)
04/10/14 03:25:38 REORGANIZE: Disconnect 1 blocks; 0000000005cadad37032..b6dfb34b7df788a9f841 ( my block is no good)
04/10/14 03:25:38 REORGANIZE: Connect 1 blocks; 0000000005cadad37032..f6593834a47b8f920358 ( connect new block)
04/10/14 03:25:38 REORGANIZE: done
...
04/10/14 03:25:38 ProcessSyncCheckpoint: sync-checkpoint at f6593834a47b8f920358a809d106d35bdfda5c1f08feaebf462f7764ef38de0d (CP agrees his was first)
04/10/14 03:25:39 getblocks 746270 to f6593834a47b8f920358 limit 500 (network wants this block instead)
All within 6 seconds, for world wide network, with 30 second block time. Not bad really! |
|
|
|
|
Acutally I just found the issue.
1 line.
READWRITE(blockHash);
I will be testing this over the next few days and then re-releasing 1.4.0.1. I think it might be it!
|
|
|
|
1.4 running fine. I just wish the startup time was faster. Loading block index takes forever.
Yes I have been thinking of more ways to speed it up. Such as compiling with 64 bit(may help) and/or threading the init load. Difficulties arrise on both. Perhaps take a look at what PHS is doing? One of the more recent updates to the PHS client lowered loading time significantly. For comparison PHS load time: 14s HBN load time: 281s The code is very close, and comes from NVC's fast start. PHS is at block ~200,000, HBN is approaching 750,000. So PHS will also slow as time goes. However I will take another look at sometime and see if I missed something. |
|
|
|
1.4 running fine. I just wish the startup time was faster. Loading block index takes forever.
Yes I have been thinking of more ways to speed it up. Such as compiling with 64 bit(may help) and/or threading the init load. Difficulties arrise on both. |
|
|
|
Hey I just wanted to let every know I will be releasing v1.4 tonight. To fix the open ssl bug. I would suggest everyone upgrade ASAP.
There was some more things I wanted to get done, but we'll be working on it for v1.5 along with some hard forks. Big discussion later.
Tranz, after releasing of 1.4, 1.3x versions will still be working, so it is not hard fork yet, right? Correct v 1.3 and 1.4 are compatible. We will begin talking about v1.5 which will have a series have hard forks to fix many issues. Is there going to be an option to see PoS diff in the client like in NVC? "difficulty" : { "proof-of-work" : 445.30749834, "proof-of-stake" : 0.59503705, BTW, as I see, the main disscussion (concerning 1.5 too) is going on at cryptocointalk.com forums? Yes, it is there. you can do getinfo true, or getmininginfo, or getdifficulty. You can also click the green PoS arrow and it will give you PoS information. |
|
|
|
Hey I just wanted to let every know I will be releasing v1.4 tonight. To fix the open ssl bug. I would suggest everyone upgrade ASAP.
There was some more things I wanted to get done, but we'll be working on it for v1.5 along with some hard forks. Big discussion later.
Tranz, after releasing of 1.4, 1.3x versions will still be working, so it is not hard fork yet, right? Correct v 1.3 and 1.4 are compatible. We will begin talking about v1.5 which will have a series have hard forks to fix many issues. |
|
|
|
|
Hey I just wanted to let every know I will be releasing v1.4 tonight. To fix the open ssl bug. I would suggest everyone upgrade ASAP.
There was some more things I wanted to get done, but we'll be working on it for v1.5 along with some hard forks. Big discussion later.
|
|
|
|
I bet if you had combined blocks your pent 4 would have been fine.
OK, thanks for the info. .. Maybe it is a silly question, but this got me wondering: If I have the same addresses in wallets open on different machines at the same time, would the faster CPU get all the stake ? .. or would there be any other curious consequences ? Your wallets would create a worm hole and be sucked into an alternate dimension! I would guess you would see a lot of orphans, and would likely be not very efficient |
|
|
|
|
Show Posts
