Topic: HoboNickels - HBN - High Fast Stake - Version 2.0! More Secure, Less Intensive - page 60. (Read 478895 times)

Might just need to do a -rescan  Could take sometime so just wait until the debug.log says it is complete.



Hmmm I don't have any Stakes from Change, but I will try to generate some in test. Thanks for the report.
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.

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

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.

Seems to be working here? Did you compile yourself?


09:11:05

validateaddress F1D7xQKugtYCDmKeZyNTqeGQxgutDcorXa


09:11:05

{
"isvalid" : true,
"address" : "F1D7xQKugtYCDmKeZyNTqeGQxgutDcorXa",
"ismine" : false
}

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

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

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

Tip in the Console :

getblockbynumber 5520337

and you have the "hash"

Good blocks:

ok ? 

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.

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:

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.

Hey thanks.

So there does appear to be a invalid chain out there that some clients are getting caught up on.


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.

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 ?

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

Started at 10:18 AM EDT

yeah what is the main change in this built? its crazy how good it works now im really interested

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

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.

"What do we want?", "HoboNickels!", "When do we want th...." -- said no one, ever.

i will re-run my wallet and test, im sure i have some coins left there

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.

Why is synchronization now faster than before? One week passed in half hour