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! |
|
|
|
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 |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
I just found out that Tranz was back and reopened my wallet. I have some coin in there, but the wallet seems to be syncing very slow. Any special bootstrap, etc that I need to know about or just wait. Noob instructions would be awesome.
BootStrap here: http://hobonickels.info/explorers.phpDownload, unzip, turn off wallet and replace blk000?.dat and the txleveldb folder out of %appdata%HoboNickels |
|
|
|
combinethreshold depend on how much coin you have in total. More you have, higher you will be able to combine your coin  For now if you want to keep block between 1500-2500, you have to do it manually since your balance allow you only to auto combine up to 752 I think I need to ask a little more detalized.)) I have 145 blocks between 1500-2500 coins. Is it amount enough to be able to combine my coins higher? I need keep the size of blocks around 2500 coins. It's a little complicated to do it manually. What should be my conf file text or console command for it? EDIT: All coins in one address. Wallet will only allow up to a certain amount to help keep the chain moving. So with your amount of coins the highest you can put is what the the rpc command returns. On a side note, it has been a very crazy week and I have only had a short amount of time to work on the wallet. Made some strides in fixing up 1.5.5 but not complete yet. Hopefully this weekend if I can get a few hours.. |
|
|
|
Hello iam trying to post
Sucessed! |
|
|
|
|
Thanks for the feedback everyone, much appreciated!
So there are some things that are working well and some that are not. I was able to re-create some of the issues, so I will be working on some updates for those. One of the things that I need to flesh out is what happens when a wallet comes online with a ton of weight. So I will have to idle my wallet for a while to see how 1.5.5 reacts and make changes based on that.
For now I have removed 1.5.5 release and I will post as soon as I have a 1.5.5.1 or 2 ready for further testing. If you are on 1.5.5.0 and it is working for you, feel free to keep on it. If not please revert back to 1.5.3.
Thanks again for the user testing. Stay tuned!
|
|
|
|
Tried the 1.5.5 version,
Syncing seemed even slower than the 1.5.3 version.
Went back to the 1.5.3 version for now.
Instead of making everyone continue to suffer with slow performance.
Why not go ahead and Kill PoW Mining and move to a 90 Second BlockSpeed in a hard fork.
And schedule the hard fork within 30 to 45 days, because to be honest I doubt anything is going to make a difference til you complete those two changes.
Thanks for your efforts.
╥Aztek
PoW Mining is already slated to be dead by block 6 million. Can't change it now. 90 seconds change will likely come but not ready yet. Also I never said this was for faster sync? This was for better staking performance. Did you let it sync and stake? What was the CPU usage like for you? How was the gui performance? Etc.. |
|
|
|
What is the minimum number of coins should be in the purse for the start of the mining?
thank you in advance
No min, even just 5 HBN would stake. Might take a while, but it should eventually. 5 or 10k in blocks of 100 - 200 is a good starting point. I have these compilation issues in ubuntu linux: hbn@xu14-cc-burn:~/opt/HoboNickels-1.5.3.0$ qmake
Project MESSAGE: Building with UPNP support
Project MESSAGE: Building with DBUS (Freedesktop notifications) support
Project MESSAGE: Building with LevelDB
Warning: ignoring <defaultcodec> element
Warning: ignoring <defaultcodec> element
Warning: ignoring <defaultcodec> element
hbn@xu14-cc-burn:~/opt/HoboNickels-1.5.3.0$ make
cd /home/hbn/opt/HoboNickels-1.5.3.0/src/leveldb && CC=gcc CXX=g++ make OPT="-m64 -pipe -fstack-protector-all --param ssp-buffer-size=1 -O2" libleveldb.a libmemenv.a
make[1]: Entering directory `/home/hbn/opt/HoboNickels-1.5.3.0/src/leveldb'
make[1]: *** No rule to make target `libleveldb.a'. Stop.
make[1]: Leaving directory `/home/hbn/opt/HoboNickels-1.5.3.0/src/leveldb'
make: *** [/home/hbn/opt/HoboNickels-1.5.3.0/src/leveldb/libleveldb.a] Error 2
hbn@xu14-cc-burn:~/opt/HoboNickels-1.5.3.0$ They are the same in version 1.5.3 and 1.5.5, and they are the same in ubuntu 14.04.5 LTS and 16.04.2 LTS. Issue with the make file, I will fix here soon. You can build the leveldb yourself and put the .a files in the correct dir and then comment out that section. Give me a few days I will see if I can get it corrected. Windows 7 SP1 Pro 64b AMD Fx 6350 @ 3.9Ghz 16 GB ram Only running 1 wallet on this machine, not using s4c. 2nd Try, started wallet 1.5.5, wait like 5min for wallet to get peer, about 5 - 6 peers and wallet is running fine, not lag at all. I unlock my wallet with my passphrase and stacking start, wallet get laggy as hell ( My current weight is 1798991 soo many block ready to stack  ) This wallet produce only orphan, with the 1.5.3 most of the block pass and mature with nearly the same weight Tried using the new "Stop Staking" but he keep trying to stake or still laging and processing older transaction? My launch parameter are D:\HoboNickels\HoboNickels-qt.exe -datadir=D:\HoboNickels -splitthreshold 50000 -combinethreshold 50000 -debug (normal to see 2017-07-30 12:56:47 splitthreshold set to 0 in debug log? ) Log sent to you in private. Hope it will help Yes helpful, thank you. I think I have an idea of what the issue is and a potential fix. Hi Tranz
Great effort on 1.5.5.0 - My CPU load is at 1% and when stacking a block it rises to 13%.
On all recent versions the CPU load was 13% all the time.
Thanks for that.
RAM usage is still 2.198GB - same usage as before.
Can you refer some information about the mergecoins RPC?
What's good for?
Ram usage is not changed in this version, that is still a ways down the road. But on my map for sure. mergecoins will allow you to quickly take smaller blocks of your choice and make bigger blocks of your choice. It doesn't take in account weight, it will just grab whatever small blocks you say. The usage is a follows: mergecoins <amount> <minvalue> <outputvalue> <amount> is resulting inputs sum <minvalue> is minimum value of inputs which are used in join process <outputvalue> is resulting value of inputs which will be created All values are real and and rounded to the nearest 0.00001 (code -1) So an example and explanation is helpful. 11:57:43
mergecoins 100 5 20 11:57:58
[
"243022d6265c9c54c77fa1deecf70edd02f55dfab39eb170b88885583ffc6438",
"81b377a5ac0f5ae9d2a29d238e0f646278b1213f51af6c77c2e769508c4bd04f",
"3ec12970cc30a5e0f3f033a91ac24f0467350c41deaab19776d10a60a37d5188",
"d3e2be8d233c662196070964f92e04dc1589a1d3a381f5893abf78588cb0e179",
"dcd9e55dc5c49a7713692ca32160dfa64e6b9fff445471f943cceb811057f593"
] In this case I said take up to 100 coins of my wallet, using only blocks of 5 or less and create new inputs of ~20. It created 5 transactions (100/20 = 5) that looked all about like this. Debit: -5.00 HBN Debit: -5.00 HBN Debit: -5.00 HBN Debit: -5.00 HBN Credit: 19.999 HBN |
|
|
|
Even worse than the 1.5.3 here. Wallet use "only" 20% cpu, but can't do anything within the wallet. Wallet not responding for 2 - 3min each clic, he try to stake even when arrow is grey telling not stacking while acquiring node. Back to 1.5.3 here  I have not experienced this on any machine yet, more information would be helpful. Have you tried restart of the wallet? Can you also give me information about your system? Win Ver/CPU/RAM, how many wallets and How many blocks up for stake? Are you using S4C? Just trying to get information for future improvements. Going forward the hard forks will be coded into 1.5.5+ so need to ensure it is working well for everyone. So a debug may help as well. Especially if you use the -debug startup switch and let it run for a bit. You can also try to use the "Stop Staking" command in the wallet menu and see if that is helps, and then after the wallet is caught up and well connected try to start it back up. |
|
|
|
Tranz, have you looked at the HUSH and ZEN wallets? They forked from ZCASH in some way and are java based, clean and quick to sync with minimal connections. HUSH also joined SuperNET DEX.
ZEN is implementing NODE incentive where 3.5% of every block mined is paid to the node operators. Just requires static IP and creating a certificate for your node, but I think that is more for ZEN's encrypted transactions than the node itself.
...
All of those are challenging and time consuming and I (we) in no way expect you to do any of that Tranz, though you have already made such good progress on 1 and 2 above. But the possibilities there are awesome!
No, but I will have a look. ----------------------------------------------- Version 1.5.5.0 is released. https://github.com/Tranz5/HoboNickels/releases/tag/1.5.5.0Please try this and give me your feedback regarding CPU usage. Good/bad timing. It's less than 2 hrs since I got 1.5.3 running on linux. Which on its own, feels alot smoother than running on windows. Time to do some comparisons across both version and platform. Good deal, thanks! Well seeing 0% and lots of 0.x% CPU synced 3 hours of chain fast, despite seeming a bit slow to acquire peers ( bit subjective ) It's gone back up to 2GB ram usage from 1.6 ..... meh .... I'm going to post now before the first stake orphans and ruins this glowing school report. *EDIT** oooh and clicking on the little staking arrow now works ... every time without delay *thumbs* You will still get Orphans, no way to prevent that with such a fast chain. I am getting about 50% maybe less orphans with 1000 blocks of 5HBN up for stake. |
|
|
|
Tranz, have you looked at the HUSH and ZEN wallets? They forked from ZCASH in some way and are java based, clean and quick to sync with minimal connections. HUSH also joined SuperNET DEX.
ZEN is implementing NODE incentive where 3.5% of every block mined is paid to the node operators. Just requires static IP and creating a certificate for your node, but I think that is more for ZEN's encrypted transactions than the node itself.
...
All of those are challenging and time consuming and I (we) in no way expect you to do any of that Tranz, though you have already made such good progress on 1 and 2 above. But the possibilities there are awesome!
No, but I will have a look. ----------------------------------------------- Version 1.5.5.0 is released. https://github.com/Tranz5/HoboNickels/releases/tag/1.5.5.0Please try this and give me your feedback regarding CPU usage. |
|
|
|
I now you are working on a new version that probably addresses some of these, but just in case ... Often when I stake the chain gets stuck. I will have my new staked block, and then nothing happens (except cpu works overtime) for up to 15 minutes. Then suddenly it realises, the blockchain has moved on, invalidates my new found block, and catches up on the missing blocks. Either way, looking forward to the coming version Yes, I have also had this problem. It comes from someone spamming blocks seconds apart. Sometimes the wallet misses one in the middle and is waiting for it to come in but it doesn't know for sure if it is part of the main block chain or not. So eventually it creates its own block and the other wallets tell it sorry no good, so it ask again for the missing block. All the while all of rest of the wallets are also very busy with the huge number of block coming in quickly, and they may not get to your request right away. Eventually you get it and any bock that you staked you now know is no good, and they are orphaned. If you notice this, it is best to shut down and restart. I also notice using the repair wallet and removing the orphan transactions does help as well. It can take a long time. like 30 mins or more if you haven't done it for years, like me. Again this can be solved with a slower block time!!!! No this poor CPU was solid at 60-62% and it's been synced for hours now with a blank wallet.
If this is still the case I would like a full copy of the debug.log file. Especially if you can run it in -debug mode for a while. I have never experienced a blank wallet pegging a CPU for so long, unless it is catching up or the block chain is getting spammed. Otherwise is should idle between 1-5%. |
|
|
|
Not having done this for a long time I think there might be a more fundamental issue than the staking algo
I have a synced client with a fresh and empty wallet.dat using 61% of an A6 6400. OK its only 2 cores but 4GHz
By my reckoning it should be doing next to nothing.
Watch the debug log file tail -f using msys. You will notice each time a new block comes in the CPU spikes. Blocks roll in VERY fast so the CPU is high a lot. Ala 20 second block time. You can also turn off stake via version 1.5.4+ or by encrypting the wallet. So if I understand you correctly the wallet is crushing that machine simply accepting new blocks with nothing else to do? I wouldn't call it spiking exactly, more .. erm balls out. Come to mention it I don't think it was working that hard while it was syncing (I wasn't watching particularly) more CPU variance for sure So possible it could be current network activity making it work harder? Roll on improvements Mine idles at 1-2% CPU, then spikes to 50% with a new block, then back down in 5 seconds or less. This with the staking improvements I am testing! 90 sec block time and plus other improvement will use 1-5% of a core average over 24 hrs. ...
I've been doing a bit of tinkering over here and beginning to feel I'm on the outskirts of the network .
There is a dude in Kiev helping me out but most peers have shocking ping times. (I believe some of the reported times are WAAAY off also)
...
These are wallet to wallet ping times, not computer ping times. If their wallet is very busy, it could take a while to respond or it may never respond. You wallet will eventually drop any ping that that is too high |
|
|
|
Not having done this for a long time I think there might be a more fundamental issue than the staking algo
I have a synced client with a fresh and empty wallet.dat using 61% of an A6 6400. OK its only 2 cores but 4GHz
By my reckoning it should be doing next to nothing.
Watch the debug log file tail -f using msys. You will notice each time a new block comes in the CPU spikes. Blocks roll in VERY fast so the CPU is high a lot. Ala 20 second block time. You can also turn off stake via version 1.5.4+ or by encrypting the wallet. |
|
|
|
Gonna have to face facts.
Even with big blocks and huge weight orphans are strangling the process.
Minimum stake size or any other method to kill off the staking spam
I'm not convinced 90 second block times will help if the wallet continues to be so unresponsive.
I have recently aggregated all blocks into a new wallet and saved 6-700 MB of RAM
can't say I'm noticing any improvements.
The wallet is thrashing 30% of a 4GHz quad core and falls into long periods of orphans on fixed by a wallet restart.
Also if everyone is creating so many potential POS solutions why are we always near 100% reward?
Better staking algo and 90 sec block time will be a huge difference.. I have 1.5.5 just about ready. THis will be the first part to help staking. Plenty of other things to do, and then we can talk about hard forks for 1.6. I think 90 second block time HAS to be among them. |
|
|
|
Is there any decent Windows Wallet that works?
Latest Win Wallet from the hp is still a mess in terms of connectivity and res usage for me.
Why not Coinswapping it and simply forking a decent wallet with masternodes, like Pivx or something.
Exclusive Coin made a decent Cumback with a reset and a new wallet.
Be my guest. I will never do a swap. And if the community is serious, I will dump and leave. End of story on swaps. I will however continue to invest my time, what little there is, improving the current wallet. I run this on many computers, beside startup issues, addnodes and blockchain catch-up, the wallet keeps on staking and talking to peers. Things work pretty well for a 20 second block network. |
|
|
|
cant we get good Windows wallet that wont freeze on opening ? it would help a lot, i still have some HBN (i thought i sold all but didnt) and keep it for better times
Yes it is slower to open, so far I have only had it not open once. I killed it via task man and restarted it with no further problems. I can look into options for faster load times. I rebuilt a HBN wallet on a different computer.
I checked, the new build sync'd fine, and staked. Then I noticed it wasn't encrypted. I remembered it being encrypted before.
Is it possible that:
1) I had a wallet.dat that was before I encrypted, and rebuilt the wallet to a state before encrypted?
2) I rebuilt the wallet and the encryption didn't transfer?
anyway that is possible?
I guess I could have just never encrypted the original wallet, but I had the key written down and everything...
The wallet is stored in a different location then the executable, so rebuilding the wallet binary shouldn't have any effect on the wallet.dat Perhaps you used the startup switch -datadir= and started the wallet.dat in a different location when you encrypted it? |
|
|
|
|
Show Posts
