My wallet synced when I updated to the latest version days ago, but for the past few days it is still trying to sync after loading the wallet again it re-scans the blockchain, takes hours to do so.
The last block number 5610710
Last block time: Thu Aug 31 14:28:17 2017
Rescan can take time, depending on how deep it had to go. Shouldn't take to much time if you just sync'd a day or so ago. What does your debug say? After it is complete the catch up should be pretty quick. 2017-09-02 02:06:22 SetBestChain: new best=4422b58b8521fadb83fc height=5618484 trust=87133663234171 blocktrust=16821621 date=09/02/17 02:05:32 |
|
|
|
Not sure what is quite up yet. All wallets should be at block
2017-08-31 00:51:21 SetBestChain: new best=13a32b329188aed1f56d height=5609925 trust=86985634388565 blocktrust=17255903 date=08/31/17 00:50:57
Cryptopia is on the correct chain.
chainz.cryptoid.info does not appear to be. I will contact them.
I will release version 1.5.5.5 here tonight or tomorrow that will disconnect bad clients. Pleas ensure you are at version least version 1.5.3+ or preferably at 1.5.5.4 (soon 1.5.5.5).
I will also update the block chain download on hobonickels.info so we can ensure everyone is on the correct chain, who maybe having trouble.
I'm guessing height is the latest block? So your saying 5609925 My client says, when I go to Network, then Current Block info I get: Last Block Number: 5605101 POW Diff: 0.234283 POW Mh/s: 0.545091 Hash-to-Coins pool has the HBN coin offline - I didn't notice (I mine HBN too). I know I checked it, at least a week ago. It says wallet is fine with connections. I wonder if they are on the wrong client and began to mine PoW and some of the other wallets jumped on that chain. The most current block right now is. SetBestChain: new best=cfde0008286d2ed7d3c5 height=5610188 trust=86990034241448 blocktrust=17473922 date=08/31/17 02:23:12 If you are not at least there right now, then you will have to update. The blockchain and new version are uploading now. Done in a few hours. |
|
|
|
|
Not sure what is quite up yet. All wallets should be at block
2017-08-31 00:51:21 SetBestChain: new best=13a32b329188aed1f56d height=5609925 trust=86985634388565 blocktrust=17255903 date=08/31/17 00:50:57
Cryptopia is on the correct chain.
chainz.cryptoid.info does not appear to be. I will contact them.
I will release version 1.5.5.5 here tonight or tomorrow that will disconnect bad clients. Pleas ensure you are at version least version 1.5.3+ or preferably at 1.5.5.4 (soon 1.5.5.5).
I will also update the block chain download on hobonickels.info so we can ensure everyone is on the correct chain, who maybe having trouble.
|
|
|
|
Updated and syncing now... a couple days worth to catch up with.
Will report back with results in the morning.
It is going to be interesting watching the hard stop until a PoS block is minted...
Thing seem to have gone pretty well from my perspective. I am noticing the block chain seems a bit cleaner right now. PoW is low, yet no flash miners!  Still have a few older version connected, but they don't' seem to be causing any issues. So the next big test will be at block 6.0 million. Also I will begin working on the 1.5.6 which will be more internal changes and a few external. And then few more PoS mining changes. I think it will be around block 6.5(maybe 6.4) million where we will move to longer block times, and perhaps a few other forks at that time. In the mean time, just sit back and enjoy a bit smoother ride! |
|
|
|
|
Just about two thousand more blocks until the first part of version 1.5.3 takes. The initial phase only allow PoW after a successful stake block. This will prevent flash mining. However since stake blocks are happening fairly regularly and quickly then even those on versions before 1.5.3 should be ok for a while. But they may they may go through some large re-orgs if fast PoW blocks come in from an old client. Worse they could be disconnected from the main network if they relays too many blocks.
So upgrade soon, if you haven't!
|
|
|
|
I'm having an issue with staking on 1.5.5.2
The program says not staking because I don't have mature coins but I look and I have numerous blocks of coins at 12-13 days old.
/////
EDIT
Rebooted the software and it started to stake
Hey Digi7ech. Yes I noticed this myself. I am releasing a new version tonight that will address that. Basically after your coins were all staked, it stopped looking for new ones. It will now double check every 10 blocks. Newest Release is ready: https://github.com/Tranz5/HoboNickels/releases/tag/1.5.5.4HBN up almost 400% at one point today, someone is buying, or at least trying to generate some volume
I came here to see, if there was any news
Nothing I know of?
Tranz all good now, trying to sync chain after this fault block that was keeping it down, HBN looks good again
Ok good! FYI I have sent out an alert to the older clients(pre 1.5.3), to upgrade before block 5.6 million. So there might be a bit of chaos for a bit! ;-) |
|
|
|
I'm having an issue with staking on 1.5.5.2
The program says not staking because I don't have mature coins but I look and I have numerous blocks of coins at 12-13 days old.
/////
EDIT
Rebooted the software and it started to stake
Hey Digi7ech. Yes I noticed this myself. I am releasing a new version tonight that will address that. Basically after your coins were all staked, it stopped looking for new ones. It will now double check every 10 blocks. |
|
|
|
where to get full blockchain ? i go stuck on wallet restart, nothing works now
hobonickels.info What do you mean nothing works. Do you look at your debug.log to see what is going on? |
|
|
|
Tranz, can you add autogluing inputs feature to the next updates?
Can you give an example please? I have a proposal to ignore or automatically delete orphans
Yes, but this will add over head to the wallet. You can do repair wallet on a daily or weekly basis, that will remove the orphans. I'll think about this more. Hi Dev,
Do you have any whitepaper I can read.
What is special about our project?
Is your code was written from scratch?
What algorithm are you using?
Thanks,
Hello I see tha u are asking similar/same question on many btcalk site? May I ask what is your motivation? Hi, I start reading lately about some projects in crypto to invest. This project seems good and it has some potential (The price seems very low) and the dev is very active to fixing bugs. I'm just asking few basic questions Thanks I'll bite. The OP and coin started from a different dev. Tranz picked it up a long time ago and fostered it into a stable coin. The whitepaper I believe was part of the first thread. Tranz has created this thread and the OP plus the first several posts have all relevant info. Take a moment, go through the first page of the thread completely, and then if you still have questions we will be glad to assist. TIP: we would all benefit from more users, so while you begin your reading, download the latest wallet and the bootstrap, get it syncing and join us! Yes all of these answer are readily available. I think HBN is unique because it has some features that other coins don't have. Multi-Wallet, Stake for Charity, unique coin logo. I also plan to add other cool things in the future, but have to do more wallet maintenance first. |
|
|
|
This one (1.5.5.3) is generating an error while starting (Error loading blkindex.dat) Before i was running 1.5.5.0 like a charm. Since i dont neeed the validateaddress RPC command, i stay at 1.5.5.0 Keep on track Tranz Hmm interesting. Really no change to indexing at all between 1.5.5.0 and .3 Not sure why that would become an issue here? Also on a side note. I have compiled my first Mac Wallet. I think it only works on 10.12 Can someone test it for me who is on that version? https://github.com/Tranz5/HoboNickels/releases/download/1.5.5.3/MacOSXV1.5.5.3.zipAlso does anyone have any experience on getting this to be better backward compatible? |
|
|
|
Thanks for looking into this.
I should mention that the "issue" can easily be solved by naming the change address w/ setaccount, and then it shows up in listtransactions as expected.
I assume you have also tried listtransactions '*' |
|
|
|
validaddress fault is a BEX error?
a buffer overflow?
everything on google simply says put the program into the DEP exception list,
but that kinda ignores that it's a buffer overflow...
ps: i run under the cardinal sin. i have full admin privs when i run programs.
yes I am testing a fix right now. |
|
|
|
Saw my 1.5.3 wallet was out of date foe about 8 days so just updated to 1.5.5.2 and downloaded the blockchain from your link.
It's up to date now but is saying none of my coins are aged yet, but they're all at least 15 days old. or did I miss a remark about coin age maturity changing?
///
Edit.
Just saw that my coin totals are off by waaay too much. Only saying I have 38k.
Might just need to do a -rescan Could take sometime so just wait until the debug.log says it is complete. @Tranz a preliminary potential bug report for a minor display bug. I will see if I can't find time this weekend to test further and write something more complete, assuming I haven't missed something obvious or stupid. System: Ubuntu Server 16.04 x64, HoboNickels 1.5.5.0 Affected: listtransactions RPC Reference: named address, any address associated with an account unnamed address, any address not associated with an account change address, self-explanatory Issue: returns only transactions/stakes with named address returns transactions/stakes with unnamed address neither returns stakes created on change addresses, and I found no suitable RPC command to actually list these, outside of parsing blocks/transactions Expected behaviour: listtransaction lists all transactions regardless of the "type" of address Hmmm I don't have any Stakes from Change, but I will try to generate some in test. Thanks for the report. Seems to be working here? Did you compile yourself?
no. downloaded from your repository are there any dependency libs the QT may be finding on my system from years of older wallets? or is the .exe totally self contained (well, except for the C runtime ) perhaps this weekend i can find some time to investigate and narrow things down further. but as i type that validateaddress command into my console window, it faults and likewise as UNOMP sends the same request it faults. oh well, i'm sure it will reveal its true nature eventually  ps: 64bit windoze 7 ultimate svc.pack 1, AMD phenom quad processor It is self contained. But possible if you have a .dll in your path it is trying to use it. Do you have another user to try it under or just another simular machine to test. I have tested it on 3 different windows machines and seems to be work ok.. Edit: Ok I had it fail on me on a different machine. I will have a look here as soon as I can. |
|
|
|
windows qt v1.5.5.2 console/rpc directive
validateaddress F1D7xQKugtYCDmKeZyNTqeGQxgutDcorXa
causes the program to fault
this is the first thing unomp mining pool software (i use unomp to solo mine multiple altcoins) does
when it connects
it seems if you feed validateaddress an invalid address it properly returns 'false'
but feed it a good address and the program fault happens
Seems to be working here? Did you compile yourself? 09:11:05  validateaddress F1D7xQKugtYCDmKeZyNTqeGQxgutDcorXa 09:11:05  { "isvalid" : true, "address" : "F1D7xQKugtYCDmKeZyNTqeGQxgutDcorXa", "ismine" : false } |
|
|
|
Hi Everyone. So there was definitely an invalid chain out there. I have a new release available that will prevent others from getting on that chain and continuing to propagate it. It is now the default wallet to grab. https://github.com/Tranz5/HoboNickels/releases/latestIf you are on the invalid chain you can try the new release, but the wallet will have a hard time getting back to the right chain. The easiest way will be to grab the block chain from hobonickels.info, and replace your txleveldb folder and blk0001.dat and blk0002.dat files and then bring up 1.5.5.2. http://hobonickels.info/HBNBlockChain.zipYou can tell if you are on the right or wrong chain by looking at your wallets block browser. Good blocks: 5499330 - aed47152a5cc2db3859dd9428089b8da1d0bdd445cd76e9711f3e304d727330f
5499331 - 00000000050e13566f81f688f2edd372415685b3c048d5b051457d170c2ea848
5499332 - 000000003806a3ee782ebc103bd7d7f47aeb753d4cce911a19dab453051e3ce5
5500000 - a8f0c882004f2f976ec8af49fa42c45620d4b33d7a1a95de748c9e19fc917962
5520337 - 0d464c4cb9c8f0b99ca2c432b820068d4fc37b3713cd881286db7787b5cda171
If you match those, keep on staking. If you don't stop and fix your block chain. So how did this happen and what can be done? Well I can only speculate as to why. But from what I see, during this time there was some flash mining going on. This may have caused some wallets to to lag and possibly disconnect from other node. Eventually they started to create their own chain. Usually when this happens, they eventually catch the real chain and then orphan all of their blocks. Why they didn't this time I can't say. Could be they were only connected to 1 other wallet, and they both simply kept on going. What can be done. Well first off I will add more hard-coded checkpoints into each release. Which will help. We are also going to slow down PoW in about 75,000 more blocks, and then 500,000 more after that PoW is gone. This will prevent flash mining and keep the network running more smoothly. I am also going to move to 90 second (or higher) block time. This will again keep the network smoother and a single wallet will not be able to flash mine blocks with high weight. Finally with the new release staking is now more efficient and the wallets will use less CPU so they will be able to keep up with the faster block time for now. |
|
|
|
Tranz! Excellent work! 4 days of blocks synced in 25 seconds and I am up to date! Staking now too. Curious what made the difference here in this version... what parameters tweaked this? EDIT: I would like to note one issue I see and IDK what the root cause is... I can go from 8+ connections syncing... to 2 connections when done and I have ALWAYS had to sit and wait for something to kick in for it to pick up peers again and catch the updated chain. This version just did it to me after I posted the above. EDIT2: Log file https://drive.google.com/open?id=0B8Vvuskew8TmSDk1TWF4bk0xeGsHey thanks. So there does appear to be a invalid chain out there that some clients are getting caught up on. 2017-08-09 13:19:11 SetBestChain: new best=00000000050e13566f81 height=5499331 trust=85313787170553 blocktrust=12409 date=08/05/17 03:01:27
2017-08-09 13:19:11 ProcessBlock: ACCEPTED
2017-08-09 13:19:11 SetBestChain: new best=4eae80db8b34cfc616bd height=5499332 trust=85313804483242 blocktrust=17312689 date=08/05/17 03:02:33
2017-08-09 13:19:11 ProcessBlock: ACCEPTED
The block 5499331 is valid but from block 5499332 you are getting invalid blocks form a peer that is generating a completely invalid chain. What is weird is that the checkpoint server was rejecting these and they shouldn't have made their way into chain, unless people are ignoring the checkpoints, which is allowed but not advisable. I will update the block chain download on hobonickels.info which can be grabbed to get past the bad block. Give me till later tonight. I will also put some new hard-coded checkpoints in a release that I will try to get out here in the next day or so. That should prevent any invalid chains from getting further propagated. Also you said you were staking now? Can you send me your most current debug.log? No need to shutdown just send me what you have now. Also include you getpeerinfo rpc command output at the bottom or top please. This the most current block as of typing this. 2017-08-09 22:36:14 SetBestChain: new best=000000000956f3c0dee8 height=5519496 trust=85607040993258 blocktrust=15361 date=08/09/17 22:35:50 |
|
|
|
Why is synchronization now faster than before? One week passed in half hour  Small change to syncing in version 1.5.5.1, wouldn't think it would have that much effect. Usually the newest days are slower as there has to be more in depth test. The older back in the chain the faster the syncing is. 1.5.5.1 version 4 days synced very quickly, then it has refused to sync any further, restarts make no difference This is what is in the debug log for hours without syncing anymore. 2017-08-09 02:41:30 Misbehaving: 173.244.48.198:53131 (3000 -> 3100) BAN THRESHOLD EXCEEDED 2017-08-09 02:41:30 ERROR: ProcessBlock() : block with too little proof-of-work 2017-08-09 02:41:30 Misbehaving: 173.244.48.198:53131 (3100 -> 3200) BAN THRESHOLD EXCEEDED 2017-08-09 02:41:30 ERROR: ProcessBlock() : block with too little proof-of-work 2017-08-09 02:41:30 Misbehaving: 173.244.48.198:53131 (3200 -> 3300) BAN THRESHOLD EXCEEDED 2017-08-09 02:41:30 ERROR: ProcessBlock() : block with too little proof-of-work 2017-08-09 02:41:30 Misbehaving: 173.244.48.198:53131 (3300 -> 3400) BAN THRESHOLD EXCEEDED 2017-08-09 02:41:30 ERROR: ProcessBlock() : block with too little proof-of-work 2017-08-09 02:41:30 Misbehaving: 173.244.48.198:53131 (3400 -> 3500) BAN THRESHOLD EXCEEDED 2017-08-09 02:41:30 ERROR: ProcessBlock() : block with too little proof-of-work 2017-08-09 02:41:30 ProcessBlock: ORPHAN BLOCK, prev=35cbc2069ff9a30d6cb4 2017-08-09 02:41:49 connection from 98.71.70.41:57555 dropped (banned) 2017-08-09 02:42:33 ping timeout: 1200.030000s 2017-08-09 02:42:38 connection from 92.30.32.29:63078 dropped (banned) 2017-08-09 02:42:52 connection from 104.207.128.75:63738 dropped (banned) 2017-08-09 02:44:52 connection from 104.230.143.200:33369 dropped (banned) ╥Aztek Hmmm. Would you mind to stop the client. Start it back up with the -debug flag passed to it. And then zip up the debug.log file and send it to me. Not sure why this happened I will play around a bit with syncing with 1.5.5.1 to see if I can re-create. |
|
|
|
Why is synchronization now faster than before? One week passed in half hour Small change to syncing in version 1.5.5.1, wouldn't think it would have that much effect. Usually the newest days are slower as there has to be more in depth test. The older back in the chain the faster the syncing is. |
|
|
|
|
Show Posts
