getbalance, getinfo, ... all report balance minus coins in unconfirmed staking blocks, how do i get the whole balance ?
Should work for you |
|
|
|
Nice! I installed it today as it seems that all runs fine and smooth. Good job again, Tranz!   Thanks! Looks like the weight is still showing incorrectly in coin control. I'll have to take a closer look at that. |
|
|
|
One thing I noticed with 2.0.1.0
The s4c doesn't seem to be working. I've had 5 stake blocks without any sending to the charity address after 25 confirmations... Latest stake has 38 confirmations as of this post.
EDIT: I disabled and re-enabled the s4c. I'll edit again when I get another stake to let you know the outcome.
EDIT 2: That fixed it. Had to disable and then enable s4c in order for it to work right.
You can also now use the Min to "accumulate" your S4C portion before you send it. Nice for not sending dust. |
|
|
|
HBN uses a lot of memory, planned to optimize that?
Plans yes. Right now every PoS Coin based on BTC Core -> PPC uses the same memory per block. I will be looking to improve this. Or watching to see if others can conquer this big hurdle. No small task, but needs to be done for the longevity of the coin for sure. |
|
|
|
maybe we make masternodes like in EXCL or even SYS plans ?
Again these are a type of update that takes quite a bit of work. Something to think about, but gain vs work is important. My time is limited, and doesn't seem to be much else out there able to assist in development and testing..
You removed the code for old client disconnection ?
No, I removed the section that was based on time. Now it will always disconnect based on the version.h file. I have the offical version compiled, but I haven't gotten a chance to fully test it out yet. Crazy day...... |
|
|
|
2.0.1.0 is pushed to Github https://github.com/Crypto-Expert/HoboNickels/pull/32/commits/b3bff705029c3d48a7367879e19aba69fbff95e4Added SplitBlock to GUI. @presstab Hyperstake
Increasing default splitthreshold and combinethreshold, plus updated Max
for each. This will work in startup and config switches up to 2500/5000.
And further increases in gui.
Changed max percentage for Stake For Charity to 100%
Renamed SetStakeMinAge to GetStakeMinAge
Renamed SetTargetSpacing to GetTargetSpacing
Created stub function for GetModiferInterval. Will be used to fork and
allow for 1 day min stake period.
Fixed CoinControl Weight to correct show at 8.8 days until fork fixes
it.
Fixed Stake Estimate in GUI.
Fixed Fee Estimate when using CoinControl.
Bumped version to 2.0.1.0 Please review and give feedback. I plan to compile the offical release here tonight or tomorrow. |
|
|
|
So other then the split/combine threshold max anything else???
I plan to release 2.0.1.0 next few days. So I am looking for quick hitters, nothing hugely complex, at least right now.
i need splitblock option/function in Send, HYP-like (® presstab) This is do-able. Might take me another week or so to implement, but I will call 2.1 complete after this then.. |
|
|
|
I have a suggestion.
In Coin Control, can you add the ability to hold shift and click multiple amounts at once? Or am I doing it wrong by single clicking a bunch of small stacks into a large stack?
You can use the space bar and down or up button to select quickly. I also suggest playing with the select coins (amount/age/weight >< ) feature. It is a way to grab certain coins quickly |
|
|
|
I hear you everyone!! At the risk of alienating people and sounding like a broken record. I don't think I can give free rein to the split and combine threshold, at least not yet. There is too much at risk with the network. Keeping the difficulty going up requires more blocks ready to stake then the chain will allow. But I do hear you!! So what I set it at, not yet committed so it can yet change, is; The standard max, which can be set in the config and startup switch is Split 2500, Combine 5000. The old was 100/200 so it is a big jump now. In the wallet I also increased the amount you can set manually. It is now Total of all loaded wallets / 400 for split, and /200 for combine. The old divisor was 500/250. Now in my opinion these numbers are way to high! They are putting the block chain at risk by not getting more stakes out there. So It is unlikely I change them again until we are at 1 day staking and/or we are in the double digits for stake difficulty. The wallet is efficient at staking, and I have plans to further increase this, so there is not much need to make this much higher. If you want higher, you will have to compile the wallet and add your own settings. Hint, it is 2 lines.. So other then the split/combine threshold max anything else??? I plan to release 2.0.1.0 next few days. So I am looking for quick hitters, nothing hugely complex, at least right now. |
|
|
|
Since we now have a network that appears to be fairly stable. I am going to code up some of the user requests we have had over the days. Here is what I have so far anything else I maybe missing? - Fix Coin Control to only show weight after 8.8 days (Temporary until fork is coded and date set)
- Allow for larger split/combine threshold settings
- Allow for 100% stake for charity
- Fix the estimated time to stake in gui
- Code up stub function, but do not yet implement the stake modifier change. To get stake min at 1 day.
What else? Seqwit is a huge undertaking. I would love to implement it. But unless I have a team of developer and testers, it is not going to happen anytime soon. I want to focus my time for now, on bettering the wallet and network, continuing to re-base with newest bitcoin, creating a light weight and Android wallet that can stake, and adding other functionality. |
|
|
|
Bye the way; Do you have a twitter account Tranz???
Cool bot! No I don't have a twitter. But thanks!
I have a block that is 19 days old which has not staked. Other blocks, younger than this one have staked. Is this normal? Is there anything I need to do for this block?
Thanks again.
Luck and weight are the 2 main ingredients. If those that are that old are smaller in size they could take longer. I have some that are approaching 30 days 1 -2k in size. You can never predict when a block will stake, you can only, with fairly good accuracy, predict when the half of a group of blocks will hit. Similar to half life of a decaying atom.
@Tranz
My new organized stakes have reached an aging time of over 8.8 days, but nevertheless the message is "not staking because you don't have mature coins", and "Current Wallet PoS Weight: 0". I hope staking begins after day 10, otherwise we had a real problem.
Well it's no worse then the 10 days it was, but at 8.8 you should start gaining weight. If you type getmininginfo in the rpc console the minimum still says 0? |
|
|
|
|
Thanks lightspeedy and hi Randall.
The original development of the coin did not have long term value and use in mind. It was meant to be one and done. Due to this things were major issues. Most notably starting with wallet lag and bad orphan rate. This was due to among many things 20 second block time. For a global network of wallets that were accepting blocks, relaying transactions and creating PoS blocks, it was not a long term feasible setting.
Also the PoW structured allowed for pools and users with high hash power to basically take over the chain and potentially cause other issues. To fix this I first made the first change to limit PoW by only allowing it to come after a PoS block, and eventually at block 6.0 million it will be turned off.
Then I made further enhancements to the wallet to allow for more efficient quicker staking. This has the unintended consequences of causing lager wallets the ability take over chain, because they could calculate stake so quickly. This only increased the issue of wallet lag and orphans and eventually caused a network split.
So the answer was to slow the chain down. The slow down of the chain triggered a higher PoS difficulty and in turn a lower stake rate. This is what you are seeing now. The benefits are much lower inflation rate, very little wallet lag, much lower orphan rate, and a network that works much better.
|
|
|
|
what is the ideal block size for staking?
is it still 5000 HBN?
I think you can safety double it at this point and not worry about hitting the cap. Would hit it around day 30. |
|
|
|
I think those attacks are hashpools who still think we have full PoW - they calculate how rewarding mining is and switch
Might be possible. But I would still assume they are using wallet 2.0 and it would limit which blocks are even allowed to make it the network. But the odd thing was other wallets accepted it and relayed it. They should have just ignored it and banned that one bad block. |
|
|
|
|
Socket errors aren't bad in and of themselves. They simply mean the connection was lost for some reason. Those reasons can be a bad internent connection between the peers, it can be that the peer you are connected too will not accept any more connections because they are at the max.
The reason I had brought it up is that, it can also be if a peer bans you for misbehaving. That was what I saw. I banned 3 or 4 clients, and I think 5 banned me as well. before I knew it i was down to 3 or 4. Now I am back to normal since the bans only last 24hrs. But for the most part, they are nothing to worry about.
|
|
|
|
|
Anyone experiencing any turbulence recently?
A few of my clients have received a large number of socket 10054 errors, followed by Misbehaving peers for too little proof of work?
|
|
|
|
@Tranz
I can live with 8.8 days of mature time, can't see a real problem with it. But correct the showed metrics of the wallet in one of the next patches, please.
No this is BAD ... It means you can manipulate the interest rate without committing your coins to the risk of staking .... 24 hours to play the difficulty for legitimate coins aged up to 9 days FlungSpun, not sure what you mean here. This issue is small. There is no way to game the system based on this. Your coins are not up for stake until 8.8 days as it sits right now. It used to be 10 days. So it is better now, but not what I wanted. I will fix this and we will get to the 1 day min stake rate. But it is not an issue that needs fixed immediately. The risk of splitting the network again via another hard fork so soon, is magnitudes more risk then letting it lie for now. As development continues and we find more issues or adjustments necessary we can wrap all of those in another fork, but we are looking a while before that happens. Well while I'm willing to go with your judgement on this from a technical fix point of view I don't see it a small issue at all. Perhaps I misunderstand something but .. I can see a very clear way to game the difficulty in this situation with only a 24 hour window. If a very big holder is able drive difficulty changes at specific time windows capturing high(er) rewards for themselves and ramping difficulty between maturity windows. Simply put A (group of) big wallet can put huge pressure on the network within 24 hours and remove it at a moments notice. While average holders have to consider block size over an 8.8 day time frame. It Just can't be a sensible way forward, even in the short term. If I'm wrong please enlighten. *edit Also don't want to come off as an unappreciative douche here. The work you have done recently has been right on the money 115Mb RAM down from 2GB :0 this just bothers me greatly. So I do see your concern, but from what I see the min stake time really doesn't change this issue much. Any wallet can choice when they stake and when they don't want to. So even if the min time was at 24hours, that doesn't mean the whale's wallet has to start staking then. He can hold off, gain weight, and wait until the % is where he wants and let his stakes go. The longer he waits though the higher the chances each stake will get capped and they could lose money in the long run. The only thing that 24 min time can help with would be if no one else did this, then the difficulty would be higher over time, and that would give them less opportunity to control the block chain. Though this is negligible. The 2 things that do help prevent a whale from controlling the chain are max weight and cap. No matter how long they weight the highest they get up to is 30 days. Also the reward cap is incentive not to do what you say as well. No worries. I am open to discussion even criticisms. I won't cry in my beer  Also you say 115mb ram? I have not observed this at all ! I am still at 2 gb on all my wallets. Now granted all my wallets go back to the first few months, but 115mb?! |
|
|
|
@Tranz
I can live with 8.8 days of mature time, can't see a real problem with it. But correct the showed metrics of the wallet in one of the next patches, please.
No this is BAD ... It means you can manipulate the interest rate without committing your coins to the risk of staking .... 24 hours to play the difficulty for legitimate coins aged up to 9 days FlungSpun, not sure what you mean here. This issue is small. There is no way to game the system based on this. Your coins are not up for stake until 8.8 days as it sits right now. It used to be 10 days. So it is better now, but not what I wanted. I will fix this and we will get to the 1 day min stake rate. But it is not an issue that needs fixed immediately. The risk of splitting the network again via another hard fork so soon, is magnitudes more risk then letting it lie for now. As development continues and we find more issues or adjustments necessary we can wrap all of those in another fork, but we are looking a while before that happens. |
|
|
|
Good news and bad. Good news I found the issue. The setting for the kernel Modifier is set for 6 hours. static const unsigned int MODIFIER_INTERVAL = 6 * 60 * 60; On the surface this seems fine. But it runs through this function: // Get selection interval section (in seconds)
static int64_t GetStakeModifierSelectionIntervalSection(int nSection)
{
assert (nSection >= 0 && nSection < 64);
return (nModifierInterval * 63 / (63 + ((63 - nSection) * (MODIFIER_INTERVAL_RATIO - 1))));
} Which changes it to 8.8 days(seem familiar?). So no stake can be calculated that is below this ModiferSelection. Bad News? I can't change this without a hard fork  Sorry I didn't catch this earlier. I did test this quite a bit. But the testnest setting: bool LoadBlockIndex(bool fAllowNew)
{
LOCK(cs_main);
if (fTestNet)
{
pchMessageStart[0] = 0xcd;
pchMessageStart[1] = 0xf2;
pchMessageStart[2] = 0xc0;
pchMessageStart[3] = 0xef;
bnProofOfStakeLimit = bnProofOfStakeLimitTestNet; // 0x00000fff PoS base target is fixed in testnet
bnProofOfWorkLimit = bnProofOfWorkLimitTestNet; // 0x0000ffff PoW base target is fixed in testnet
nStakeMinAge = 2 * 60 * 60; // test net min age is 2 hours
nCoinbaseMaturity = 10; // test maturity is 10 blocks
nStakeTargetSpacing = 1 * 60; // test block spacing is 3 minutes
} Is set in a complete different modal. So my test passed there. And I didn't realize it was different. But this is one of those settings that can't be tested on main net unless you fork off your own chain. I think for the time being we have been through enough forks. I will plan for another one in the next 6-12 months or possible sooner that will fix this issue. Plus other things we may decide. Another hint: The message "You have 50% chance of producing a stake within TIME" delivers an at least 10 times higher time span than the real minting occurs.
This I can and have fixed for the next release.
I can see why there might be cause for concern as I have some blocks at 8.8 days which have 10x the weight of much smaller blocks at 13-14 days and only blocks over 10 days have staked since the fork .. but its no scientific.
8.8 is the min, so those should be up for stake now. |
|
|
|
|
Show Posts
