Topic: [HYP] HyperStake | Generous Reward Staking | Advanced Staking Controls & Wallet - page 147. (Read 679332 times)

That isn't exactly bad though, it would mean that the active Stakers are receiving more Coins. If only 20% of the network were Staking then in theory you are gaining 4-5X more Coins you would otherwise.

I am rerunning the numbers on this in with more precise code... and I am thinking I was way off

Still checking my code, but this is what my current calcs are showing:

When I read that sentence with so many "horribles" in it, there's only one POS coin that comes to mind. Could you be talking about XPY by any chance? I dumped most of my holdings there when I got the opportunity.

I put a bunch of the proceeds from said dump operation into HYP. I seem to have reached a critical mass where I'm staking every day now. What's not to like?

I just cannot accept purposely miscasting a type to solve a computation issue on a computer. To me, that is just too many shades of wrong. My head explodes just thinking about it.  


I believe I found the solution.The nutty part of it is that it will simplify the database loader code even more then it already is.  

Wow that is insane. Solution... store everything as a string LOL

As a last resort, I would grudgingly go that route with CCE.

1. One of the original principals of CCE from the beginning was the generation of completely human readable database. The storage of decimal values as integers reduces this by forcing one to convert the values to get useful information.

2. As a developer, it is a HUGE PET PEEVE of mine that in this day and age we are still dealing with the float/decimal accuracy/precision problem.

An example of this madness is the Decimal module in Python. The whole purpose of which to create a class that is accurate over precision(floats).
In the below examples, I have already tried changing context ,prec, rounding and using quantize, it does not change anything.

The Decimal type casting is converting the literal to a float and back to Decimal. What is the point of having the Decimal class in this situation!!

Now for really the crazy part:



I would be embarrassed to publish code with double casting like that.  

Have you ever considered getting rid of the decimal and storing the numbers as long long ints like they are in the wallet client?

Or has not successfully staked since Apr 22. I would guess the majority of those coins are not actively staking.

interesting

so in theory, 80% of the coin supply is not staking?

Hmm good question. I think the wallet accounts for it as one tx hash = one tx. Probably best to keep it using the same logic?

Nope not hard, and nifty tool to add to my collection. I will see if I can throw up a chart.

There are
No activity after block #:
50,000: 14,816 addresses holding 9,011,300 HYP
100,000: 38,796 addresses holding 9,799,091 HYP
200,000: 101,276 addresses holding 44,440,892 HYP
250,000: 112,902 addresses holding 82,474,920 HYP
300,000: 120,138 addresses holding 148,268,693 HYP


Block 200k was Jan 10th, so I don't think its quite accurate to label those as all written off. Block 100k was in September, it could be fair to assume that most of those are not coming back from the dead.

With any assumption, the point here is that there is a significant amount of coins that is held by addresses that haven't staked for a considerable amount of time. Maybe this is why difficulty seems to be pinned in the 20-40 range instead of continually increasing further.

According to my wallet
pRb: 8,474,645.521656
pDr: 4,732,980.250775

This shows the same balances too, so seems to be accurate at the moment (data is handled in their native form inside the wallet so there isn't issue with translation) http://www.presstab.pw/phpexplorer/richlist.php

The explorer normally counts it as 2 transactions, atleast that is what I normally see.

I have a question I need to pose to the users of POS chains.

When accounting for the number of transactions on an address, would you consider the address on a POS stake TX to have one or two transactions?

I can see it both ways.

Technically, it appears to be one transaction as it is one transaction hash.

However, the address is in both the TXIN and TXOUT in the transaction, so the argument can me made that it should count as two.

How do you think an explorer should count it?

well isnt that kinda the same? they are not competing for the PoS blocks and that is kinda what I am interested in

I highly doubt it. A cold wallet and a dead wallet would both show the same amount of activity

press is there any easy way to figure out how much of the coin supply is in dead wallets?

While working on CCE 4, I found some interesting things about the account balances. Some people have mentioned some discrepancies in account balances, but for the most part I believed they were just misunderstandings about how the transaction system works in regards to txin/txout and change addresses, and many were.

However,

A short time after I started work on CCE4, I discovered the MySQL has a strange way of handling float type fields over 7/8 digits in either direction from the decimal regardless of how you set the field parameters.
Even so, logic dictated that it would only vary by a small amount, within rounding generally <= 1.
The first solution was simply to change the database fields in 4.0 to the Double and later to the Decimal type. I could not change the current live databases, because it would require complete database rebuilds as values entered into the database before the change would still have the float rounded values.

In later versions of the database loader itself, I changed all the float types to Decimal types to account for any strangeness in Python float handling.
However, I was still finding a significant difference difference between the account balances CCE 4 and the live version. I expected to find a small difference due to the float rounding in the live version, but not as large as I saw.

In CCE 4, one of the added features is tracking the amount of transactions on each account, in live versions this is not kept track of in any way.

I saw some of the top ranked addresses had 40K+ transactions!  

It hit me. A small rounding issue in a transaction or even a hundred would not be largely noticeable, but multiplied by 40,000 would most certainly make a difference.

As of a short time ago, this is what the top 6 addresses look like on my local development system.

To the holders of these addresses, do these balances look closer to what is shown in your wallets?  

Just upgraded some of the visual things on my RPC based explorer. Made a little live chain on the side of the front page that updates the chain automatically. I will try to expand the charting capabilities soon. http://presstab.pw

In fact, BTC wallet code allows RPC commands only from local host by default. It surely means that you don't have any malware.