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

[Tranz]

I am trying to understand how this new split and combine threshold is going to work, but I guess I need some help.

I wonder what happens if you stake 8 coins. Will it split? I guess yes cause it's bigger than 5.
But will it combine again since the result is twice an amount lower than 5 coins.

Just curious

And good luck the the stake-improvement. I don't mind waiting a little longer.

The output of 8 coins that stake would be say 2 blocks of 4.2. One of those blocks could combine with a stake that is very small, say a .5 that staked. Assuming that didn't happen, those 4.2 would stake and not split, so you would be get 1 block of 4.4 the next time and then 4.8 and then eventually over 5. Once over 5 it will split, and since you ill then have smaller blocks, 2.6 ish, they would have a chance to combine with another block. If not they will stake but not split until over 5 again.


Does that help?

Yes, thanks, I think so! I never realized the combining was possibly done with other blocks than the ones just created after splitting. That brings up another question: how does the algorithm decides which block to pick to combine with? A block that brings the combined amount closest to 5 or a smaller block with as less coin age as possible?

Here is the section of code that does the combining.

Code:

// Attempt to add more inputs
        // Only add coins of the same key/address as kernel
        if (txNew.vout.size() == 2 && ((pcoin.first->vout[pcoin.second].scriptPubKey == scriptPubKeyKernel || pcoin.first->vout[pcoin.second].scriptPubKey == txNew.vout[1].scriptPubKey))
            && pcoin.first->GetHash() != txNew.vin[0].prevout.hash)
        {
            // Stop adding more inputs if already too many inputs
            if (txNew.vin.size() >= 100)
                break;
            // Stop adding more inputs if value is already pretty significant
            if (nCredit > nCombineThreshold)
                break;
            // Stop adding inputs if reached reserve limit
            if (nCredit + pcoin.first->vout[pcoin.second].nValue > nBalance - nReserveBalance)
                break;
            // Do not add additional significant input
            if (pcoin.first->vout[pcoin.second].nValue > nCombineThreshold)
                continue;
            // Do not add input that is still too young
            if (pcoin.first->nTime + nStakeMaxAge > txNew.nTime)
                continue;
            txNew.vin.push_back(CTxIn(pcoin.first->GetHash(), pcoin.second));
            nCredit += pcoin.first->vout[pcoin.second].nValue;
            vwtxPrev.push_back(pcoin.first);
        }

So basically whatever block staked, the wallet will try to combine other blocks with it, that are the same key, are not going to put it over the limit, and have weight.

[1714969505]

1714969505

[1714969505]

1714969505

[Zer0Sum]

Nice to see all the Stake Devs here.

I own a non-trivial amount of HBN and other stake niche coins...
And have been mining a few of these scrypt stakers...
BUT as of last week I can no longer buy/sell HBN.

Cryptsy pretty much out-of-the-blue freezes my account...
And notifies you that you MUST be verified to unfreeze your account.

Verification at Cryptsy involves actually taking a picture of yourself holding your ID...
(Probably one of the most bizarre demands I've ever seen)...
And answering a number of intrusive questions about your mining activities.

Cryptsy has chosen to form a close partnership with the US Government...
So that they can pursue a specific business model and are planning to make a lot of $$$$...
At the expense of the fine people here.

As a former US broker-dealer, I can positively assure you of one thing...
Cryptsy is sending detailed reporting to the US Government...
And their reports are certainly riddled with errors and omissions and mixups.

The US Govt is then passing these dodgy reports on to every country with which they have a Tax Treaty.

I know several people in North America...
That have been getting tax bills originating from false IRS information...
And these bills go back 5-6 years or even more... and are very difficult to disprove.

Basically, about 5 years from now...
All you guys on the RichList are going to start getting tax bills from the IRS or your local Revenue Agency...
Based on all this money you allegedly made based on Cryptsy reports way back in the day.

I would bet within 6 months... "out-of-the-blue"...
100% of Cryptsy accounts will have to be "verified"...
Verified at the point of a gun with your coins frozen.

Since all you Devs are here...
You better diversify your coins to several exchanges like HYP smartly did...
Or Cryptsy will kill your coin sooner or later.

[Tranz]

This is news to me as well. They have never stated they will force verification. But I also have a feeling it might happen.

Regarding getting HBN on another exchange. I think this is a good idea. We have tried, we have succeed, and then once we get added there is no volume and eventually the coin is delisted.

I would like to see it on polo. Perhaps we can start a campaign for that.

[Majormax]

This is news to me as well. They have never stated they will force verification. But I also have a feeling it might happen.

Regarding getting HBN on another exchange. I think this is a good idea. We have tried, we have succeed, and then once we get added there is no volume and eventually the coin is delisted.

I would like to see it on polo. Perhaps we can start a campaign for that.

+1

I agree. I'd like to see CAP and HBN on Poloniex. Maybe it can become high PoS Mecca

The catch is that low volume exchanges will add, but there will be low publicity and exposure. Higher vol exchanges may delist coins that dont generate enough relative revenue.

Mintpal, Bittrex, Poloniex are the 3 top ones for volume + large numbers of trading pairs, (in addition to Cryptsy),and BTER is on the rise : worth a shot... They seem open to new proposals.

[igl00]

installed the beta - works great. way faster than old one

[PressF1]

Here is the section of code that does the combining.

Code:

// Attempt to add more inputs
        // Only add coins of the same key/address as kernel
        if (txNew.vout.size() == 2 && ((pcoin.first->vout[pcoin.second].scriptPubKey == scriptPubKeyKernel || pcoin.first->vout[pcoin.second].scriptPubKey == txNew.vout[1].scriptPubKey))
            && pcoin.first->GetHash() != txNew.vin[0].prevout.hash)
        {
            // Stop adding more inputs if already too many inputs
            if (txNew.vin.size() >= 100)
                break;
            // Stop adding more inputs if value is already pretty significant
            if (nCredit > nCombineThreshold)
                break;
            // Stop adding inputs if reached reserve limit
            if (nCredit + pcoin.first->vout[pcoin.second].nValue > nBalance - nReserveBalance)
                break;
            // Do not add additional significant input
            if (pcoin.first->vout[pcoin.second].nValue > nCombineThreshold)
                continue;
            // Do not add input that is still too young
            if (pcoin.first->nTime + nStakeMaxAge > txNew.nTime)
                continue;
            txNew.vin.push_back(CTxIn(pcoin.first->GetHash(), pcoin.second));
            nCredit += pcoin.first->vout[pcoin.second].nValue;
            vwtxPrev.push_back(pcoin.first);
        }

So basically whatever block staked, the wallet will try to combine other blocks with it, that are the same key, are not going to put it over the limit, and have weight.
[/quote]

Thanks, I think I got a pretty good idea now. I am looking forward to test it with a new version. Got some old wallets with just about the right weight and amounts. thanks again!

 

[PressF1]

should i update wallet or no need? im on windows

No need yet. I will be releasing a final beta version here soon, you can try it out then if you like. It will have everything except for the hard forks. You can also just wait for 1.5 officially, which should be the same as the beta 1.5s , minus any bugs found.

I am looking forward to testing it!

As for the VIP idea, being within top 20 range, I would still favor the same wallet for everyone. Feels better that way to me. You made me wondering though, maybe the same thing could be achieved in an other way without the need for a special wallet.

Would it be possible to make the combine/threshold limit dependent on the size of the address staking?
At this moment number 20 is about 50K, so if the threshold would be 0,05% of this amount, it would be 25. So you would end up being able to select between 5 to 20 or the percentage which only makes sense if you are a large stakeholder.

I have no clue though if such thing is programmable. I am only being enthusiastic!

Not a bad idea, I did think of this as well. I think it could only be done via a RPC command once the wallet(s) have been loaded.  May not make it for 1.5, but will keep it in mind.

I did some thinking and came to the conclusion that if this option becomes available, using a percentage of 0,05% will eventually result in wallet containing at least 2000 blocks (probably some more, because not all blocks can combine and hover exactly beneath the splitting threshold all the time).

I'd say that's maybe a little too much? what's your idea/community in this matter?   

[johnywalker]

HoboNickels (HBN) was added to Comkort exchange.
Three markets are live HoboNickels <-> BTC, LTC, DOGE.

[Majormax]

should i update wallet or no need? im on windows

No need yet. I will be releasing a final beta version here soon, you can try it out then if you like. It will have everything except for the hard forks. You can also just wait for 1.5 officially, which should be the same as the beta 1.5s , minus any bugs found.

I am looking forward to testing it!

As for the VIP idea, being within top 20 range, I would still favor the same wallet for everyone. Feels better that way to me. You made me wondering though, maybe the same thing could be achieved in an other way without the need for a special wallet.

Would it be possible to make the combine/threshold limit dependent on the size of the address staking?
At this moment number 20 is about 50K, so if the threshold would be 0,05% of this amount, it would be 25. So you would end up being able to select between 5 to 20 or the percentage which only makes sense if you are a large stakeholder.

I have no clue though if such thing is programmable. I am only being enthusiastic!

Not a bad idea, I did think of this as well. I think it could only be done via a RPC command once the wallet(s) have been loaded.  May not make it for 1.5, but will keep it in mind.

I did some thinking and came to the conclusion that if this option becomes available, using a percentage of 0,05% will eventually result in wallet containing at least 2000 blocks (probably some more, because not all blocks can combine and hover exactly beneath the splitting threshold all the time).

I'd say that's maybe a little too much? what's your idea/community in this matter?   

I do not understand why so many blocks can be acceptable. I try to keep my wallets (in all PoS coins) below 50 blocks.

[PressF1]

As far as I know a large amount of blocks staking contributes to the safety of the network. Isn't that why they split up in the first place? In the HBN-wiki it says the following:  

It is recommended that users find the optimal block size composition for their wallet and goals. Although the state of the HoboNickels network is always evolving and user computer equipment varies, the current state of the HoboNickels network comfortably accommodates the following block conditions:

    Up to 500 blocks, no real need to combine anything, maybe check for really small blocks (dust transactions, below 1 HBN) and combine those.
    Between 500 and 1000 block, start analyzing your blocks and combine the youngest blocks into fewer blocks.
    Over 1000 blocks, you might actually see your computer or the wallets performance affected by the PoS process, there is a lot of block trying to stake. Definitely try to combine into fewer blocks.


This was a while back. But 500 seems pretty ok to me for not needing to recombine manually all the time.

[Majormax]

As far as I know a large amount of blocks staking contributes to the safety of the network. Isn't that why they split up in the first place? In the HBN-wiki it says the following:  

It is recommended that users find the optimal block size composition for their wallet and goals. Although the state of the HoboNickels network is always evolving and user computer equipment varies, the current state of the HoboNickels network comfortably accommodates the following block conditions:

    Up to 500 blocks, no real need to combine anything, maybe check for really small blocks (dust transactions, below 1 HBN) and combine those.
    Between 500 and 1000 block, start analyzing your blocks and combine the youngest blocks into fewer blocks.
    Over 1000 blocks, you might actually see your computer or the wallets performance affected by the PoS process, there is a lot of block trying to stake. Definitely try to combine into fewer blocks.


This was a while back. But 500 seems pretty ok to me for not needing to recombine manually all the time.

OK.. I will let the numbers build up a bit.

[Tranz]

Sorry for the lack up update recently. Worked on the new NVC faster stake for a while, but even after starting from scratch and trying on CAPs I wasn't successful.  So I scratched it for now and moved on to make the code more compatible by switching to int64_t.  Got that working and decided to go a few steps further and remove all the PRI64d stuff.

Well was on the last few updates, one of them called for a global replace. I used the IDE find and replace, instead of sed. And it severely messed up the code. I had failed to commit the changes up to that point, and my last backup was a 4 days ago. So lost a fair amount of work. Oh well, live and learn, although I have already learned this one a few times....

[Majormax]

Sorry for the lack up update recently. Worked on the new NVC faster stake for a while, but even after starting from scratch and trying on CAPs I wasn't successful.  So I scratched it for now and moved on to make the code more compatible by switching to int64_t.  Got that working and decided to go a few steps further and remove all the PRI64d stuff.

Well was on the last few updates, one of them called for a global replace. I used the IDE find and replace, instead of sed. And it severely messed up the code. I had failed to commit the changes up to that point, and my last backup was a 4 days ago. So lost a fair amount of work. Oh well, live and learn, although I have already learned this one a few times....

Well, some of the best advances often come after setbacks.

I am not a coder, but I know this stuff does not progress in a straight line 

[PressF1]

Sorry for the lack up update recently. Worked on the new NVC faster stake for a while, but even after starting from scratch and trying on CAPs I wasn't successful.  So I scratched it for now and moved on to make the code more compatible by switching to int64_t.  Got that working and decided to go a few steps further and remove all the PRI64d stuff.

Well was on the last few updates, one of them called for a global replace. I used the IDE find and replace, instead of sed. And it severely messed up the code. I had failed to commit the changes up to that point, and my last backup was a 4 days ago. So lost a fair amount of work. Oh well, live and learn, although I have already learned this one a few times....

I wish I could help out here but since I am no coder as well, I am sure I would do a lot more damage than an IDE find and replace can do. (whatever that may be! )

[PressF1]

I have noticed that when i send some coins and my wallet is locked sometimes after sending my wallet stays open and I have to manually lock it again. Does anyone else encounters this behavior too? I use 1.4.8.0. It's not a big deal of course but I though it would be good to report it.

[Tranz]

I have noticed that when i send some coins and my wallet is locked sometimes after sending my wallet stays open and I have to manually lock it again. Does anyone else encounters this behavior too? I use 1.4.8.0. It's not a big deal of course but I though it would be good to report it.

It should re-lock, but I will take a look and make sure that is working correctly. Thanks!

[Flam]

Tranz,

Can you please reupload a downloadable blockchain ? The link is broken.

Regards,

Flam.

[presstab]

moved on to make the code more compatible by switching to int64_t.  Got that working and decided to go a few steps further and remove all the PRI64d stuff.

Oh jeez this is a lot more time consuming then you are letting everyone know! I have done this before and it sucks!

[Tranz]

moved on to make the code more compatible by switching to int64_t.  Got that working and decided to go a few steps further and remove all the PRI64d stuff.

Oh jeez this is a lot more time consuming then you are letting everyone know! I have done this before and it sucks!

Ya it can be a pain.  I am just about 1/2 back to the point I was, but this time commits and saves have been taken.

[Tranz]

Tranz,

Can you please reupload a downloadable blockchain ? The link is broken.

Regards,

Flam.

Sure I will here in a bit. Thanks for letting me know.

Edit: How is this?

http://www.mediafire.com/download/y5y9au1f5doxt5d/HoboBlockChain10-12-14.zip