HoboNickels - HBN - High Fast Stake - Version 2.0! More Secure, Less Intensive

[daemonfox]

Just for funz and lulz I kicked off a fresh block sync with the new client.

Started at 10:18 AM EDT

[1714944640]

1714944640

[Turrican]

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]

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=0B8Vvuskew8TmSDk1TWF4bk0xeGs

Hey 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]

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/latest

If 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.zip

You can tell if you are on the right or wrong chain by looking at your wallets block browser.

Good blocks:

Code:

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]

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=0B8Vvuskew8TmSDk1TWF4bk0xeGs

Hey 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]

Open Console (In the Wallet click "Help/Debug windows/Console)

Tip in the Console :

getblockbynumber 5520337

and you have the "hash"

Good blocks:

Code:

5499330 - aed47152a5cc2db3859dd9428089b8da1d0bdd445cd76e9711f3e304d727330f
5499331 - 00000000050e13566f81f688f2edd372415685b3c048d5b051457d170c2ea848
5499332 - 000000003806a3ee782ebc103bd7d7f47aeb753d4cce911a19dab453051e3ce5
5500000 - a8f0c882004f2f976ec8af49fa42c45620d4b33d7a1a95de748c9e19fc917962
5520337 - 0d464c4cb9c8f0b99ca2c432b820068d4fc37b3713cd881286db7787b5cda171

ok ? 

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/latest

If 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.zip

You can tell if you are on the right or wrong chain by looking at your wallets block browser.

Good blocks:

Code:

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]

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

[HCLivess]

I also noticed the fork, updating now. I like this tempo of development!

[Tranz]

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]

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.

[2xjO9M3P]

@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:

Code:

listtransactions

returns only transactions/stakes with named address

Code:

listtransactions ""

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]

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

[Tranz]

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:

Code:

listtransactions

returns only transactions/stakes with named address

Code:

listtransactions ""

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.

[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.

[Tranz]

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]

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 !

[Tranz]

Ok 1.5.5.3 released.

https://github.com/Tranz5/HoboNickels/releases/latest

No need to update unless you use validateaddress rpc command.

Thanks for the bug reports! Keep em coming.

[woogod]

Tranz you are awesome! Thanks for the hard works 

[Rumhurius]

Tranz you are awesome! Thanks for the hard works 

Good jawb.
This one really feels a megaton better.
Nice Update.
Keep em coiming +1

[2xjO9M3P]

@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:

Code:

listtransactions

returns only transactions/stakes with named address

Code:

listtransactions ""

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.