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

[Tranz]

I think I got the kinks all worked out of 1.5.5. I am finalizing some testing and should have it released today or tomorrow.  On my big wallet with a TON of weight I get about 40-50% orphan rate. On some smaller wallets I get much lower. But the wallet no longer gets caught up in the millions of unresponsive orphans.  And when no new blocks are in, the wallet drops to 1-2% CPU.

[1713886524]

1713886524

[1713886524]

1713886524

[1713886524]

1713886524

[daemonfox]

I think I got the kinks all worked out of 1.5.5. I am finalizing some testing and should have it released today or tomorrow.  On my big wallet with a TON of weight I get about 40-50% orphan rate. On some smaller wallets I get much lower. But the wallet no longer gets caught up in the millions of unresponsive orphans.  And when no new blocks are in, the wallet drops to 1-2% CPU.

This is great news Tranz thank you for your hard work. I will test once you put it up.

I had a question about syncing and P2P connections... is there something in the base QT that limits connection speeds? It seems like all these old coins sync really slow no matter what... but all of these newer Java based swing wallets sync the chain like a damn torrent! Or is it just bandwidth from the peers? Or is this just a result of the bulk from 20 second block target?

Examples:

HBN (QT) gets 14 or so connections and still takes 3 to 5 hours or more to sync 2 days of blocks.
ZEN (JAVA) gets 7 to 10 connections and syncs a couple days worth of blocks in about 3-5 minutes tops.
HUSH (JAVA) gets 5 to 8 connections and syncs a couple days worth of blocks in about 3-5 minutes tops.

Just curious if you had encountered anything pointing to QT limitations on this.

[Tranz]

I think I got the kinks all worked out of 1.5.5. I am finalizing some testing and should have it released today or tomorrow.  On my big wallet with a TON of weight I get about 40-50% orphan rate. On some smaller wallets I get much lower. But the wallet no longer gets caught up in the millions of unresponsive orphans.  And when no new blocks are in, the wallet drops to 1-2% CPU.

This is great news Tranz thank you for your hard work. I will test once you put it up.

I had a question about syncing and P2P connections... is there something in the base QT that limits connection speeds? It seems like all these old coins sync really slow no matter what... but all of these newer Java based swing wallets sync the chain like a damn torrent! Or is it just bandwidth from the peers? Or is this just a result of the bulk from 20 second block target?

Examples:

HBN (QT) gets 14 or so connections and still takes 3 to 5 hours or more to sync 2 days of blocks.
ZEN (JAVA) gets 7 to 10 connections and syncs a couple days worth of blocks in about 3-5 minutes tops.
HUSH (JAVA) gets 5 to 8 connections and syncs a couple days worth of blocks in about 3-5 minutes tops.

Just curious if you had encountered anything pointing to QT limitations on this.

Partiality due to fact that HBN does 5 to 6 times more blocks per day.  There are things that can be done, including doing a headers first and then sync. That is in the works for sure.

Making a Java client sounds great.  But it seems I am alone here and no one else is willing to step up and help with code. BTC has 100s of coders, PeerCoin, NVC, LTC have 50 to 10. Even HYP has 4 or 5. So far for a community coin, I have done 99.8% of the code work.  I would love to mess around with Java but based on the current work load, its about a 2020 goal. 

[daemonfox]

I think I got the kinks all worked out of 1.5.5. I am finalizing some testing and should have it released today or tomorrow.  On my big wallet with a TON of weight I get about 40-50% orphan rate. On some smaller wallets I get much lower. But the wallet no longer gets caught up in the millions of unresponsive orphans.  And when no new blocks are in, the wallet drops to 1-2% CPU.

This is great news Tranz thank you for your hard work. I will test once you put it up.

I had a question about syncing and P2P connections... is there something in the base QT that limits connection speeds? It seems like all these old coins sync really slow no matter what... but all of these newer Java based swing wallets sync the chain like a damn torrent! Or is it just bandwidth from the peers? Or is this just a result of the bulk from 20 second block target?

Examples:

HBN (QT) gets 14 or so connections and still takes 3 to 5 hours or more to sync 2 days of blocks.
ZEN (JAVA) gets 7 to 10 connections and syncs a couple days worth of blocks in about 3-5 minutes tops.
HUSH (JAVA) gets 5 to 8 connections and syncs a couple days worth of blocks in about 3-5 minutes tops.

Just curious if you had encountered anything pointing to QT limitations on this.

Partiality due to fact that HBN does 5 to 6 times more blocks per day.  There are things that can be done, including doing a headers first and then sync. That is in the works for sure.

Making a Java client sounds great.  But it seems I am alone here and no one else is willing to step up and help with code. BTC has 100s of coders, PeerCoin, NVC, LTC have 50 to 10. Even HYP has 4 or 5. So far for a community coin, I have done 99.8% of the code work.  I would love to mess around with Java but based on the current work load, its about a 2020 goal. 

Let me see what I can do about that... i know a few and maybe someone wants a piece of this resurgence.

TBC...

[Tranz]

I think I got the kinks all worked out of 1.5.5. I am finalizing some testing and should have it released today or tomorrow.  On my big wallet with a TON of weight I get about 40-50% orphan rate. On some smaller wallets I get much lower. But the wallet no longer gets caught up in the millions of unresponsive orphans.  And when no new blocks are in, the wallet drops to 1-2% CPU.

This is great news Tranz thank you for your hard work. I will test once you put it up.

I had a question about syncing and P2P connections... is there something in the base QT that limits connection speeds? It seems like all these old coins sync really slow no matter what... but all of these newer Java based swing wallets sync the chain like a damn torrent! Or is it just bandwidth from the peers? Or is this just a result of the bulk from 20 second block target?

Examples:

HBN (QT) gets 14 or so connections and still takes 3 to 5 hours or more to sync 2 days of blocks.
ZEN (JAVA) gets 7 to 10 connections and syncs a couple days worth of blocks in about 3-5 minutes tops.
HUSH (JAVA) gets 5 to 8 connections and syncs a couple days worth of blocks in about 3-5 minutes tops.

Just curious if you had encountered anything pointing to QT limitations on this.

Partiality due to fact that HBN does 5 to 6 times more blocks per day.  There are things that can be done, including doing a headers first and then sync. That is in the works for sure.

Making a Java client sounds great.  But it seems I am alone here and no one else is willing to step up and help with code. BTC has 100s of coders, PeerCoin, NVC, LTC have 50 to 10. Even HYP has 4 or 5. So far for a community coin, I have done 99.8% of the code work.  I would love to mess around with Java but based on the current work load, its about a 2020 goal. 

Let me see what I can do about that... i know a few and maybe someone wants a piece of this resurgence.

TBC...

Thank you! I am willing to and love working on the wallet. I can't move as fast as some would like, just to much that needs done.. So any help is greatly appreciated.

[Turrican]

I think I got the kinks all worked out of 1.5.5. I am finalizing some testing and should have it released today or tomorrow.  On my big wallet with a TON of weight I get about 40-50% orphan rate. On some smaller wallets I get much lower. But the wallet no longer gets caught up in the millions of unresponsive orphans.  And when no new blocks are in, the wallet drops to 1-2% CPU.

Nice one  I like to test the new version

[woogod]

Revered Tranz,

Is there a working HBN pool right now? One linked in first page of the thread all of them doesn't work.
Thank you sir.

[woogod]

Other than Hash-To-Coin multipools that is..

[tokyoghetto]

I am running 1.5.3 and my wallet is stuck on block 5501180 or about 1 day left. anyone having the same issue or know a solution to my problem.

I was able to mine some blocks with 5 connections. The chain I am on is 8 blocks behind https://chainz.cryptoid.info/hbn.

[Tranz]

Revered Tranz,

Is there a working HBN pool right now? One linked in first page of the thread all of them doesn't work.
Thank you sir.

Sorry I don't know of any other right now. Anyone else? I will update the main page with them.

I am running 1.5.3 and my wallet is stuck on block 5501180 or about 1 day left. anyone having the same issue or know a solution to my problem.

I was able to mine some blocks with 5 connections. The chain I am on is 8 blocks behind https://chainz.cryptoid.info/hbn.

Hey Tokyoghetto,

I would be happy to help. No issues that I know of. Have you tired to restart the wallet?  Also I just released 1.5.5.1 you might want to give that a shot. If still no go. Send me your debug.log file in PM I will have a look and advise.

I think I got the kinks all worked out of 1.5.5. I am finalizing some testing and should have it released today or tomorrow.  On my big wallet with a TON of weight I get about 40-50% orphan rate. On some smaller wallets I get much lower. But the wallet no longer gets caught up in the millions of unresponsive orphans.  And when no new blocks are in, the wallet drops to 1-2% CPU.

Nice one   I like to test the new version

Here it is.

https://github.com/Tranz5/HoboNickels/releases/tag/1.5.5.1

[Turrican]

Version 1.5.5.1 its works  put i download the blockgain ... i think is a little faster ... 2-3 Blocks per seconds. The CPU ist on 30-35% (old Intel Core i5-3320M).

[woogod]

I will ask if coincave can start supporting HBN, I will mine with them if so

[Tranz]

I will ask if coincave can start supporting HBN, I will mine with them if so

They have to be on version 1.5.3 or higher.  In about 80,000 more blocks the rules for PoW mining begin to change. By block 6 million, PoW is all but dead. So get em while you still can!

[Cryptorast]

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

[Tranz]

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.

[forzendiablo]

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

[gildinglite]

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

[Tranz]

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.

[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

[forzendiablo]

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