[HYP] HyperStake | Generous Reward Staking | Advanced Staking Controls & Wallet

[dreamwatcher]

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?

[1714686937]

1714686937

[1714686937]

1714686937

[Crestington]

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?

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

[presstab]

Code:

Rank 	Address 	                        Balance 	              Number of TX
1	p73uYHEB6eRC51HqB8Z6gU2xNRXyUtXByy 	10216824.908994000011       16875
2	pRbwpBsgumVu2pUA4u2BajC9NU5HEQ7Xuq	8434645.521655999985	      41074
3	pUJ3ezaz8RLoU41xGLovQQaWPmbY7gGhtc	6063668.166964000001	      22154
4	pM5CVBkTXUkbQmuyouHa267LM6Ro4SsAKo	6002632.044782000036	      15443
5	pDrF5118EMcjGKxs3yfow6fhkELyLoiC4u	4712980.250774999973	     7861
6	pSCDj9QScyCCGwmHHo7WFra7ZDhk7iXUo4	4400883.232435999998	      37258

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

[presstab]

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

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.

[presstab]

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?

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?

[billotronic]

interesting

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

[presstab]

interesting

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

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

[presstab]

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.

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

[dreamwatcher]

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

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.

Code:

>>> from decimal import *
>>> txin = Decimal(8813.021351)
>>> print txin
8813.021350999999413033947349
>>> txout = Decimal(9813.021351)
>>> print txout
9813.021350999999413033947349
>>> print type(txin)
<class 'decimal.Decimal'>
>>> print type(txout)
<class 'decimal.Decimal'>

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:

Code:

>>> txin = Decimal(str(8813.021351))
>>> txout = Decimal(str(9813.021351))
>>> print txin
8813.021351
>>> print txout
9813.021351
>>> print type(txin)
<class 'decimal.Decimal'>
>>> print type(txout)
<class 'decimal.Decimal'>

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

[presstab]

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

[dreamwatcher]

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

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.  

[ruddsd01]

I'm surprised to notice the price of HYP dropping below 100sat today with how advanced and well functioning the wallet is and how damn hard it is getting to stake.  I think over the longer term HYP is a great buy.

I think HYP is getting some blow back from the few horrible, horrible...I mean REALLY horrible, ultrahigh% POS coins that have salted the earth lately.  I think people see original 750% and think similar out of control inflation. 

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?

[presstab]

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

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.

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:

[Crestington]

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

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.

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:

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.

[presstab]

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:

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.

But I like getting more coins

[dreamwatcher]

Two new posts about open source CCE 4.0:


https://bitcointalk.org/index.php?topic=922515.msg11303913#msg11303913

[LiteBit]

Incoming buy support could be coming to the project. HYP chatter increasing 5 fold (#7 most talked about coin today)
https://twitter.com/crypto_chatter/status/596007161219706880

[billotronic]

oooooOOOoooo

https://twitter.com/CryptocoinAPI/status/596000244892102656

4 BTC and we could win that

[presstab]

oooooOOOoooo

https://twitter.com/CryptocoinAPI/status/596000244892102656

4 BTC and we could win that

My hesitation is that the market needs to have good enough buy support to be able to use a gateway like that.

[billotronic]

damn you and your reasonable thinking.