daemonfox
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 09, 2017, 02:19:45 PM |
|
Just for funz and lulz I kicked off a fresh block sync with the new client.
Started at 10:18 AM EDT
|
|
|
|
Turrican
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 227
Merit: 26
“BitCloud [BTDX]”
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 09, 2017, 08:57:10 PM |
|
Version 1.5.5.1 run good ... put have many checkpoint error in the log
2017-08-09 20:41:13 ERROR: AcceptBlock() : rejected by synchronized checkpoint 2017-08-09 20:41:13 ERROR: ProcessBlock() : AcceptBlock FAILED
is the checkpoint on ?
|
|
|
|
Tranz (OP)
Legendary
Offline
Activity: 1540
Merit: 1060
May the force bit with you.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 09, 2017, 10:33:12 PM |
|
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
|
|
|
|
Tranz (OP)
Legendary
Offline
Activity: 1540
Merit: 1060
May the force bit with you.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 10, 2017, 02:57:10 AM |
|
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.
|
|
|
|
daemonfox
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 10, 2017, 04:15:21 AM |
|
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 Should have corrected that... at first post it appeared to be staking but when I swapped back after posting it had started balking at the bad block. Giving the new version a try tomorrow.
|
|
|
|
Turrican
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 227
Merit: 26
“BitCloud [BTDX]”
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 10, 2017, 05:20:52 AM |
|
Open Console (In the Wallet click "Help/Debug windows/Console) Tip in the Console : getblockbynumber 5520337 and you have the "hash" Good blocks: 5499330 - aed47152a5cc2db3859dd9428089b8da1d0bdd445cd76e9711f3e304d727330f 5499331 - 00000000050e13566f81f688f2edd372415685b3c048d5b051457d170c2ea848 5499332 - 000000003806a3ee782ebc103bd7d7f47aeb753d4cce911a19dab453051e3ce5 5500000 - a8f0c882004f2f976ec8af49fa42c45620d4b33d7a1a95de748c9e19fc917962 5520337 - 0d464c4cb9c8f0b99ca2c432b820068d4fc37b3713cd881286db7787b5cda171
ok ? ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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.
|
|
|
|
dnp
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 10, 2017, 07:11:08 AM |
|
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
|
Explorer and full node hosting at explorer.dognose.net
|
|
|
HCLivess
Legendary
Offline
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 10, 2017, 12:18:52 PM |
|
I also noticed the fork, updating now. I like this tempo of development!
|
|
|
|
Tranz (OP)
Legendary
Offline
Activity: 1540
Merit: 1060
May the force bit with you.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 10, 2017, 01:11:55 PM |
|
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 }
|
|
|
|
Digi7ech
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 121
Merit: 10
HBN <3
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 10, 2017, 07:30:32 PM |
|
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.
|
Hobo Nickel rocks! HBN: ErCmri4PCGc1HAQtsufpWA7M1M9tjRdTb6
|
|
|
2xjO9M3P
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 10, 2017, 08:00:48 PM |
|
@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
|
|
|
|
dnp
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 10, 2017, 09:08:45 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) ) 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) ps: 64bit windoze 7 ultimate svc.pack 1, AMD phenom quad processor
|
Explorer and full node hosting at explorer.dognose.net
|
|
|
Tranz (OP)
Legendary
Offline
Activity: 1540
Merit: 1060
May the force bit with you.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 10, 2017, 09:48:38 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) ) 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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.
|
|
|
|
dnp
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 11, 2017, 12:06:03 AM Last edit: August 11, 2017, 12:44:35 AM by dnp |
|
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.
|
Explorer and full node hosting at explorer.dognose.net
|
|
|
Tranz (OP)
Legendary
Offline
Activity: 1540
Merit: 1060
May the force bit with you.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 11, 2017, 12:27:10 AM |
|
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.
|
|
|
|
dnp
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 11, 2017, 12:33:26 AM |
|
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. thank-you fast person ! ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
Explorer and full node hosting at explorer.dognose.net
|
|
|
Tranz (OP)
Legendary
Offline
Activity: 1540
Merit: 1060
May the force bit with you.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 11, 2017, 01:59:05 AM |
|
Ok 1.5.5.3 released. https://github.com/Tranz5/HoboNickels/releases/latestNo need to update unless you use validateaddress rpc command. Thanks for the bug reports! Keep em coming.
|
|
|
|
woogod
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 94
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 11, 2017, 08:10:33 PM |
|
Tranz you are awesome! Thanks for the hard works ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
|
Rumhurius
Legendary
Offline
Activity: 1672
Merit: 1046
Here we go again
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 12, 2017, 12:34:46 AM |
|
Tranz you are awesome! Thanks for the hard works ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) Good jawb. This one really feels a megaton better. Nice Update. Keep em coiming +1
|
|
|
|
2xjO9M3P
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 12, 2017, 06:45:10 AM |
|
@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.
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.
|
|
|
|
|