HIP-406: Staking #408
Replies: 59 comments 72 replies
-
|
Which account pays the fee for the reward payment transaction? |
Beta Was this translation helpful? Give feedback.
-
|
There is no fee for the reward transfer. The hbars simply move from 0.0.800
to the recipient.
A free query wouldn’t trigger a reward payment.
…On Tue, Mar 29, 2022 at 4:04 PM rblinton ***@***.***> wrote:
Which account pays the fee for the reward payment transaction?
CryptoGetAccountBalance is currently a fee-free transaction, is calling it
sufficient to initiate the reward payment?
—
Reply to this email directly, view it on GitHub
<#408 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDBYW3M6HD7Y5SRA4TYKYLVCNV6BANCNFSM5RYRXVHQ>
.
You are receiving this because you were mentioned.Message ID:
<hashgraph/hedera-improvement-proposal/repo-discussions/408/comments/2465031
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
To achieve this, will changes be made to privileged transactions (https://github.com/hashgraph/hedera-services/blob/master/docs/privileged-transactions.md) to prevent the Council from adding keys to 0.0.800 in the future by performing an CryptoUpdate using the treasury account 0.0.2 or system admin account 0.0.50 to waive signing requirements? |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
One example: the Hedera Council could stake from its treasury, and choose
to not accept rewards for it.
…On Fri, Apr 1, 2022 at 1:11 AM Georgi Yazovaliyski ***@***.***> wrote:
1. An account stakes to a node but elects to earn no rewards. Why
would anyone even stake just for the sake of the influence the node gets
and *not want rewards?*?
—
Reply to this email directly, view it on GitHub
<#408 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDBYW7HJ4WZSURPKI6MKELVC2HQFANCNFSM5RYRXVHQ>
.
You are receiving this because you were mentioned.Message ID:
<hashgraph/hedera-improvement-proposal/repo-discussions/408/comments/2483471
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
That is a great idea and I think there would be motivation from different parties to do something like this. |
Beta Was this translation helpful? Give feedback.
-
|
current uncertainty over how staking rewards will be taxed might cause some to opt-out |
Beta Was this translation helpful? Give feedback.
-
|
The last setting described at that link says the accounts that can be
updated are set to be those below 1000. That should be 750, and will be by
the time 0.0.800 is created. So there will be no way for any transactions
to add keys to 0.0.800.
On Thu, Mar 31, 2022 at 8:29 AM mthometech ***@***.***> wrote:
That account (staking reward account, 0.0.800) has no keys associated with
it, and therefore no transaction can ever transfer hbars out of it, not
even a transaction signed by the Council
To achieve this, will changes be made to privileged transactions
(https://github.com/hash
graph/hedera-services/blob/master/docs/privileged-transactions.md
<https://github.com/hashgraph/hedera-services/blob/master/docs/privileged-transactions.md>)
to prevent the Council from adding keys to 0.0.800 in the future by
performing an account update using the treasury account 0.0.2 or system
admin account 0.0.50 to waive signing requirements?
… —
Reply to this email directly, view it on GitHub
<#408 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDBYW3Y2CUP3VUYQ4GESRLVCWSCDANCNFSM5RYRXVHQ>
.
You are receiving this because you were mentioned.Message ID:
<hashgraph/hedera-improvement-proposal/repo-discussions/408/comments/2478313
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
Does maxStake include both the node operator's stake plus accounts that proxy stake? If yes, can a node operator refuse proxy stake that would cause his node to exceed maxStake so the node operator's rewards are not diminished in that instance? |
Beta Was this translation helpful? Give feedback.
-
|
I believe maxStake includes all hbar staked to that node. Regarding a node refusing to stake for someone in the FAQ part of the proposal it says
|
Beta Was this translation helpful? Give feedback.
-
|
Is there a reason for the network to simply not permit over-staking a node? Is it a mechanism to keep account holders who stake active and involved with the network or is it something else? |
Beta Was this translation helpful? Give feedback.
-
|
That's a good question. I had the same question and was hoping to find a different answer when reading over the FAQ (i.e. some mechanism to prevent a node operator from becoming over proxied and thus diluting the rewards for previous people who might have been of the 'set it and forget it' mindset.) |
Beta Was this translation helpful? Give feedback.
-
|
It's the node operator who could be most impacted as there is a cost to operating a node. Proxy rewards have a 100% margin, node rewards would not, so the dilution from exceeding the maxStake hits the node operator harder. In an extreme scenario, over proxy staking a node could make the economics of being a node operator unappealing especially if the proxy stakers simply set it and forget it and a node is staked for an extended period. |
Beta Was this translation helpful? Give feedback.
-
|
Suppose I have staked my account to a node, and at the time of staking I had 100 HBAR in my account and the sum of all hbars of all accounts staked to that node is exactly maxStake. Now suppose I have an additional 10 HBAR transferred into my account. The transfer should not fail because I happen to have been the first transaction that contributed over maxStake to the node, or we can get into all kinds of trouble (such as scheduled transactions failing because at the time they were executed the node I happened to be staked too had too much staked to it). And it isn't fair to penalize me for "over staking" and not others (and even if we wanted to, the implementation would be prohibitively expensive). So if we accept that we want free, liquid staking and we want a maxStake, then I think the conclusion is we have to penalize everyone equally who stakes to an overstaked node. I imagine wallets will have some "auto-stake" feature and will intelligently select nodes to stake to such that it will maximize the rewards earned by an account, and I imagine the natural economics of it will be that people will be incentivized to seek out lower-staked honest nodes. This is good, as it will cause stake to be distributed more widely and contribute to the security of the network (which, after all, is the real reason for native staking on the network). |
Beta Was this translation helpful? Give feedback.
-
|
A design questions Is this an intentional design limitation or would we like to consider breaking this out to support these additional User Stories in the future
|
Beta Was this translation helpful? Give feedback.
-
|
I think a future HIP could introduce percentage-based staking so a single account could stake a certain percentage of the account balance to different nodes and/or accounts. However this takes more state to represent making each account larger and more time to compute on each crypto transfer, so there are real costs to all accounts, so it would need to be a justified addition. The |
Beta Was this translation helpful? Give feedback.
-
Do we want to consider adding a mechanism to ensure that an account can't lose out on earning rewards. |
Beta Was this translation helpful? Give feedback.
-
|
isn't there an automatic renewal process that would prevent this and ensure at least 1 transactions happens per year? |
Beta Was this translation helpful? Give feedback.
-
|
I believe there is and it was alluded to under the scenario where an account holder (probably Alice) stakes to a node and then loses the keys. As long as the account can pay the automatic renewal fee, the balance will continue to grow. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, but this is only in the case where |
Beta Was this translation helpful? Give feedback.
-
|
As part of |
Beta Was this translation helpful? Give feedback.
-
|
If the max autorenew period is ever increased, then the staking history can
be increased at the same time. So autorenew will always ensure no missed
rewards.
…On Fri, Apr 1, 2022 at 6:09 PM Nana-EC ***@***.***> wrote:
Yes, but this is only in the case where autoRenewPeriod is capped under a
year.
If it's ever set over a year then the scenario of lost earned rewards may
occur.
—
Reply to this email directly, view it on GitHub
<#408 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDBYW3HJCAFN2DSAI7DENDVC562LANCNFSM5RYRXVHQ>
.
You are receiving this because you were mentioned.Message ID:
<hashgraph/hedera-improvement-proposal/repo-discussions/408/comments/2489032
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
The HIP doesn’t have the concept of proxy staking. There’s only one kind of
staking. A user can stake to any node. And a person who runs a node can
also stake their own hbars to any node (not just their own). And the
staking reward is the same, regardless of who is doing the staking.
There will also be a mechanism for rewarding node operators for running the
node. But that will be a future HIP. And the reward will be for keeping the
node running, and will not be affected by what hbars the owner of the node
has.
…On Sat, Apr 2, 2022 at 12:42 PM hashpool-network ***@***.***> wrote:
It's the node operator who could be most impacted as there is a cost to
operating a node. Proxy rewards have a 100% margin, node rewards would not,
so the dilution from exceeding the maxStake hits the node operator harder.
In an extreme scenario, over proxy staking a node could make the economics
of being a node operator unappealing especially if the proxy stakers simply
set it and forget it and a node operator is staked for an extended period.
—
Reply to this email directly, view it on GitHub
<#408 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDBYW5IRB6GGGSBKYH4N23VDCBJ7ANCNFSM5RYRXVHQ>
.
You are receiving this because you were mentioned.Message ID:
<hashgraph/hedera-improvement-proposal/repo-discussions/408/comments/2491960
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
hi @lbaird , a scenario. I run a node, and stake my account to that node. As other accounts stake to my node, the value of the |
Beta Was this translation helpful? Give feedback.
-
|
Why is this bad? It seems like the incentive is for people to distribute stake across as many trustworthy nodes as possible, which is exactly what a Proof of Stake network wants. If a node operator stakes their account to some other trustworthy node because a very large percentage of the user base staked to its node, then for the network that is a good thing, and for the node operator it isn't a bad thing. |
Beta Was this translation helpful? Give feedback.
-
|
The semantic of staking to a node is 'I believe the target node is credible, honest and will be able to support the burden of contributing to consensus'. For a node operator to pick some other node implies that they believe the other node meets the above criteria better than they themselves do - which seems ..... odd :-) |
Beta Was this translation helpful? Give feedback.
-
|
Leemon, There is a bit of an issue with the requirement for a change in an account being the trigger for rewards being released. The end result of what this suggests, is that a person will just have two accounts, then use the scheduled transactions feature to automate a transfer of a small amount of hbar/tinybar each day to trigger the rewards in both accounts, effectively allowing the rewards to be compounded daily. Initially, I believe it was implied that daily payouts would be compounded daily. Rather than having a work around to achieve the goal, I think it'd be wise to incorporate it from day 1. Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
You could do scheduled transactions to trigger daily payments with just a
single account. You don’t need two. Updates to keep setting the decline
reward to false would do it. And you can decide whether you want to do this
daily or monthly or quarterly.
…On Sun, Apr 3, 2022 at 9:10 AM wolfofthekirb ***@***.***> wrote:
Leemon,
There is a bit of an issue with the requirement for a change in an account
being the trigger for rewards being released. The end result of what this
suggests, is that a person will just have two accounts, then use the
scheduled transactions feature to automate a transfer of a small amount of
hbar/tinybar each day to trigger the rewards in both accounts, effectively
allowing the rewards to be compounded daily. Initially, I believe it was
implied that daily payouts would be compounded daily. Rather than having a
work around to achieve the goal, I think it'd be wise to incorporate it
from day 1.
Thoughts?
- @wolfofthekirb <https://github.com/wolfofthekirb>
—
Reply to this email directly, view it on GitHub
<#408 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDBYW3GCMCT7FIB4F6SWO3VDGRDRANCNFSM5RYRXVHQ>
.
You are receiving this because you were mentioned.Message ID:
<hashgraph/hedera-improvement-proposal/repo-discussions/408/comments/2494981
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
I understand the implications of the network automatically sending the rewards each day with a potentially large spike in network demand. There should be a better way than essentially "tricking" the system. Just brainstorming here, is there a way to take [total network accounts] divided by 86400 seconds in a day, and disperse rewards on a per second basis? e.g. Total accounts are 8640000, divided by 86400 seconds in a day, the system would disperse rewards at a rate of 100 tps all day long, starting with account 0.0.1, finishing with 0.0.100 in the first second of the day, 0.0.101 to 0.0.200 in the second, and so on. It'd spread the network demand over the full day to keep things fast. |
Beta Was this translation helpful? Give feedback.
-
|
If we have a hundred million accounts, it becomes expensive to reward them
daily. That’s 1100 TPS just for the rewards, which is a significant
amount. It’s better to have a guaranteed quarterly reward, which is what
the current proposal has with autorenewals every 3 months.
There is only a small difference in total reward for daily reward
compounding versus quarterly reward compounding. For example, if you earn
100 hbars for quarterly compounding, you might have earned 101 hbars for
quarterly compounding. And that difference can easily be compensated for by
just slightly increasing the reward emission rate, to give you 101 hbars
with quarterly compounding.
(Here’s an example of the math that shows the reward changing by only one
part in a hundred for daily vs quarterly:
https://finance.zacks.com/difference-between-interest-compounding-daily-quarterly-1209.html
)
…On Sun, Apr 3, 2022 at 10:49 AM wolfofthekirb ***@***.***> wrote:
I understand the implications of the network automatically sending the
rewards each day with a potentially large spike in network demand. There
should be a better way than essentially "tricking" the system. Just
brainstorming here, is there a way to take [total network accounts] divided
by 86400 seconds in a day, and disperse rewards on a per second basis? e.g.
Total accounts are 8640000, divided by 86400 seconds in a day, the system
would disperse rewards at a rate of 100 tps all day long, starting with
account 0.0.1, finishing with 0.0.100 in the first second of the day,
0.0.101 to 0.0.200 in the second, and so on. It'd spread the network demand
over the full day to keep things fast.
—
Reply to this email directly, view it on GitHub
<#408 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDBYW37VOA6DNMSOKHTRGDVDG4YDANCNFSM5RYRXVHQ>
.
You are receiving this because you were mentioned.Message ID:
<hashgraph/hedera-improvement-proposal/repo-discussions/408/comments/2495315
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
A typo: if it’s 100 hbars earned for quarterly, then it might be 101 hbars
for *daily*.
…On Sun, Apr 3, 2022 at 11:18 AM Leemon Baird ***@***.***> wrote:
If we have a hundred million accounts, it becomes expensive to reward them
daily. That’s 1100 TPS just for the rewards, which is a significant
amount. It’s better to have a guaranteed quarterly reward, which is what
the current proposal has with autorenewals every 3 months.
There is only a small difference in total reward for daily reward
compounding versus quarterly reward compounding. For example, if you earn
100 hbars for quarterly compounding, you might have earned 101 hbars for
quarterly compounding. And that difference can easily be compensated for by
just slightly increasing the reward emission rate, to give you 101 hbars
with quarterly compounding.
(Here’s an example of the math that shows the reward changing by only one
part in a hundred for daily vs quarterly:
https://finance.zacks.com/difference-between-interest-compounding-daily-quarterly-1209.html
)
On Sun, Apr 3, 2022 at 10:49 AM wolfofthekirb ***@***.***>
wrote:
> I understand the implications of the network automatically sending the
> rewards each day with a potentially large spike in network demand. There
> should be a better way than essentially "tricking" the system. Just
> brainstorming here, is there a way to take [total network accounts] divided
> by 86400 seconds in a day, and disperse rewards on a per second basis? e.g.
> Total accounts are 8640000, divided by 86400 seconds in a day, the system
> would disperse rewards at a rate of 100 tps all day long, starting with
> account 0.0.1, finishing with 0.0.100 in the first second of the day,
> 0.0.101 to 0.0.200 in the second, and so on. It'd spread the network demand
> over the full day to keep things fast.
>
> —
> Reply to this email directly, view it on GitHub
> <#408 (reply in thread)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABDBYW37VOA6DNMSOKHTRGDVDG4YDANCNFSM5RYRXVHQ>
> .
> You are receiving this because you were mentioned.Message ID:
> <hashgraph/hedera-improvement-proposal/repo-discussions/408/comments/2495315
> @github.com>
>
|
Beta Was this translation helpful? Give feedback.
-
|
Just been thinking about this.. If the main motive of the lockup period is to ensure that attackers will lose $$ if they wanted to attack the Hedera network, then perhaps we should continue to explore what other options there are to achieve the same goal without the need of a lockup. After all, all the lockup does is adding some friction to the attacker when it comes to selling their HBAR to prevent loss prior to the attack, but doesn't prevent the actual attack from happening if the attacker doesn't mind losing $$. So really, the main focus here is: "How can we ensure that the attack is expensive?" or "How can we discourage attackers from thinking about attacking the network?" instead of "How can prevent the attack from being successful if it occurs" Furthermore, and importantly, retail HBAR holders can get in a undesired scenario where they cannot sell their HBAR to limit loss if they found out about the attack > 48 hours later. This in turn will damage the retail confidence and faith when it comes to staking their HBAR and this will have a cascading effect on the security of Hedera as a whole and in the long run. We cannot expect that most retail users will stay up to date with the health of the network on a daily basis Liquid staking is attractive because you can unstake anytime to limit loss following an attack, so is therefore less risky. This in turn will attract more users (and whales) to our network and therefore HBAR will be better distributed throughout = better security. I know users who couldn't unstake UST / LUNA during the crash because of a prolonged lockup period and they had to take a massive loss. These affected users will think twice about lockup staking in the future. In my mind:
Therefore we should keep exploring how we can add more friction to ensure that the attack is expensive or impractical with the liquid staking option without the need of a lockup. For example, have these ideas been considered:
There could be other ideas I haven't though of yet. |
Beta Was this translation helpful? Give feedback.
-
|
I added on lock up in other post- I am shocked it has been even considered, putting upside down the original proposal from 2019, entirely undermining network growth and not helping security at all (negatively affecting network long term) |
Beta Was this translation helpful? Give feedback.
-
|
i think a previous post of mine was deleted, which is a shame. maybe now i will have better luck! how does one plausibly sell the volume of hbars required to make an attempt on the the network, without tanking the price for those hbars? this seems like the inverse mechanics to the' cornering the market' security feature of pos networks where prices rise as an attacker tends toward 1/3 of the stake . if, as now, the price and volume of hbars is low, a large volume of hbar sales will cause the investment to be lost with certainty. if, in some future time period the value of hbars is high, then, due to the total number of hbars either the attack is too expensive or such volume would have insufficient buyers causing the price to crash and the investment to be lost. how does a lockup change this calculation? presumably policies which raise the price of hbars offer a more effective approach, which is also consistent with the interests of network participants and holders of hbar stake. lockups would be similar to airport security scans and shoe checks; they do not plausibly improve security and are, on balance an unnecessary friction to all participants. final question. what do enterprise types think of this feature? does it make the network sound like the bleeding edge of web3/metaverse that you have to tell the bank 24hrs before you can use your token? |
Beta Was this translation helpful? Give feedback.
-
|
This anarchist concept that nodes can be anonymous or should be is wrong in either POW or POS. Lock up period is not going to protect from attacks- as attacker is prepared to lose all the Hbar holdings (mission sacrifice, write off) if it puts another leverage short bet on exchanges against Hbar making more money that way. It can act like that in any POS or POW network really. |
Beta Was this translation helpful? Give feedback.
-
|
@lbaird Once staking functionality is deployed to mainnet, users can elect to stake to a node ID or to another account at any time and this election will be stored in state. At some point in the future, staking rewards will be activated once the balance of Will the account Or in other words, if a user stakes to node ID 0 via HAPI and then it takes 6 months for |
Beta Was this translation helpful? Give feedback.
-
|
A few thoughts on a lock-up...
|
Beta Was this translation helpful? Give feedback.
-
|
"Why was the network previously considered secure without a lock-up but suddenly its security requires a lock-up?" Leemon answered earlier in the thread: "The focus of securing the network should be on raising the value of HBAR to make a 1/3 stake impossible to acquire, not on the hoped-for behavior of an attacker after the 1/3 stake is acquired." I agree |
Beta Was this translation helpful? Give feedback.
-
|
Very good point that the attacker could just short on a different coin such as BTC after sending TerraUSD into a death spiral. That is a loophole we need to keep in mind for lockup staking. In Hedera scenario, the attacker could simply short other coins build on HSC ($DOVU, $SAUCE etc.) that would get affected by the attack to limit loss. So the lockup of HBAR doesn't really help much in this scenario. "If an attack on the network can not be dissuaded by an attacker losing his stake, then the only defense against an attack is to make the necessary stake required to carry out an attack prohibitively expensive." I agree. This is a better defense mechanism vs lockup. If the attack is too expensive to start with, then the attacker won't do it. That is the ideal scenario. And for that to happen, the price of HBAR needs to go up. And for it to go up, there needs to be more demand for it (on top of use cases) and I think lockup staking will reduce demand for HBAR as risk adverse investors will avoid it. So far I'm leaning towards not having lockup staking. |
Beta Was this translation helpful? Give feedback.
-
|
Just realized that they can just do a short on HBAR to gain profit following the attack so the 48 hours lockup doesn't really matter to the attacker. I've never done shorting before, so for those who are more familiar with this, please chip in here if what I said is true or false. |
Beta Was this translation helpful? Give feedback.
-
Hedera has still not that big market cap- but with time there will be more shorting vehicles out there, with higher price attacks will be more difficult too- but any damage they can do could affect reputation and price in fact. I don't think any lock up period has any benefit here, definitely not for users. |
Beta Was this translation helpful? Give feedback.
-
They could short any asset that can be short in Hedera ecosystem not even Hbar, but Hbar too. You cannot have secure network with random anonymous nodes in POS as running in the network, that is not even aspect of price but that matters too in POS. If there will be unknown nodes you monitor them, if they break the rules they should be excluded from network even with voting power. Miners can have a lots of hash power- if they does not follow network rules block is rejected, by honest miners even with smaller hash power. Hash alone does not even secure anything in network here, it is just a message that miner is heavily invested and cannot afford to cheat and produce invalid blocks as has skin in the game. Chess game analogy- I gave that analogy on the telegram. When The Garry Kasparov as chess master played the famous game with computer at a time, he could not cheat by changing chess game rules, despite he was The known Kasparov. He could not do that even if playing with nobody as school kid. He had to follow rules otherwise everyone else would notice he did invalid move if decided to invent his own chess game rules to cheat a smart kid. He could not fool that way, neither miners with lots of hash power can, if they break network rules their block is rejected no matter what hash power they have. Bitcoin is only economically secured network, and nothing else secures it and network rules are set in stone. If you need to pay people significant amount for staking in order for community to put effort to secure the network - that is not security. Community need to understand that, they should not need to be financially convinced to do that, and make wise choice regardless if they paid or not as then network is not secure and it is binary, they lose everything. For attacker it will not matter and if people are blinded by $$ a main reason to make staking choice then they put security as second aspect. For attacker is even better. Attacker can pretend for long to be good citizen (honest node & get paid) and then unleash attack after luring people financially, especially if they will be able to share their own node reward stake with users to motivate them financially to stake to their node. It would be comparable as dishonest candidate in election bribing people for their votes by money. |
Beta Was this translation helpful? Give feedback.
-
|
Account decides not to stake (auto-staking, no rewards)- to add security if the account decides not to stake then as per 2019 proposal no reward will be paid but staking power will be used. In that case the staking should only go by default to the KYC nodes (as network rule). KYC from The HBAR Foundation- the Foundation should offer accounts option to KYC them. Then they can make a list on website of KYC accounts -users will be encouraged to find ideally both fast and KYC account. The new account can be added periodically (quarterly, or longer during next protocol update) to list of KYC accounts for them also to receive auto staking votes. Then any nodes that prefer not to have KYC can still particulate, but they will never be able to receive stakes from those automatically staked accounts. They will be incentives to do KYC with Foundation to:
Symbolic staking rewards as higher security - as I wrote, the reason people fail easy to Ponzi schemes (bad actor accounts luring with fees) as they promise a lot of reward. Here staking person don’t risk anything apart from not getting paid (slashing- I reject as idea, good as it is in HIP & 2019 blog with no slashing). Reward as account fee cancellation- as user I should not be paying even symbolic account fee even if tiny bars/per year if helping network. This will also prevent situation of larger account to become larger and get more voting power (Oligarchy) if % reward fees are significant as main criticism of any POS. The Bread & Circus (community expectation) as referred in other post |
Beta Was this translation helpful? Give feedback.
-
|
Any update on when this will be finalized and staking implemented @lbaird ? |
Beta Was this translation helpful? Give feedback.
-
|
The Council TechCom committee usually votes on a HIP about a week after the discussion here ends. The last comment was 2 days ago. So if there are no comments in the next few days, they will be able to vote on whether to approve it. |
Beta Was this translation helpful? Give feedback.
-
|
I'm looking forward to this feature running. Both Swirlds and Swirlds Labs have committed to staking (without rewards) for the foreseeable future. It will be great to see this working! |
Beta Was this translation helpful? Give feedback.
-
|
Another step in the maturation of the network. I'm looking forward to it as well! |
Beta Was this translation helpful? Give feedback.
-
|
Looking forward to it too! |
Beta Was this translation helpful? Give feedback.
-
|
Any guess on reaching threshold in 0.0.800? Are we going to be waiting weeks? Or are the flood gates going to open soon after the update on the 21st? |
Beta Was this translation helpful? Give feedback.
-
|
We’re excited for native staking to hit mainnet and are looking forward to supporting, either by staking or donating to account 800! |
Beta Was this translation helpful? Give feedback.
-
|
Hi Elaine Song we are excited to see native staking also! |
Beta Was this translation helpful? Give feedback.
-
|
Overall- very good concept has been approved. Although there is the 6.5% max cap (with opt out option) at the end it is free market and if private entities wish to donate to account 800, that is their choice. From what I understand from video transactions fees will go at some point but not necessary as big direct subsidy from treasury to account 800. I also like that it is staged approach in releasing as Phases and how the triggering payments of rewards will be done. Not all accounts at the same time and dependent when user sends/receives transaction to account- it will be in users’ interest to keep account active, hence rewards will be paid to acounts randomly in time. Small number of inactive accounts may be receiving it when account pays fee or HTS toke fee is collected, but that is ok. |
Beta Was this translation helpful? Give feedback.
-
|
If you’re staked to a node and someone sends you hbars that would put your
stake over the max, then we could make the transfer fail. But instead, it’s
better to let you receive those hbars, and continue staking with slightly
less reward. Then later, if others stop staking to that node so it drops
below the max, you automatically start to earn more reward.
…On Fri, Apr 1, 2022 at 4:51 PM hashpool-network ***@***.***> wrote:
Is there a reason for the network to simply not permit over-staking a
node? Is it a mechanism to keep account holders who stake active and
involved with the network or is it something else?
—
Reply to this email directly, view it on GitHub
<#408 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDBYW3NOFUK7OSYZPCG3WDVC5VVVANCNFSM5RYRXVHQ>
.
You are receiving this because you were mentioned.Message ID:
<hashgraph/hedera-improvement-proposal/repo-discussions/408/comments/2488788
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
The mechanism to do that is to create several accounts, and stake each of
them separately. This keeps the implementation simpler, and lets the
processing happen faster, to improve throughput (TPS).
…On Fri, Apr 1, 2022 at 2:51 PM Nana-EC ***@***.***> wrote:
A design questions
I believe the current staking logic enforces staking 1) With an accounts
whole balance 2) To a single NodeId or AccountId
Is this an intentional design limitation or would we like to consider
breaking this out to support these additional User Stories in the future
1. An account stakes a portion of their balance to a node for several
staking periods
2. An account stakes a portion of their balance to an AccountId for
several staking periods
3. An account stakes differing portions of their balance to a set of
nodes for several varying staking periods (an extension of 1)
4. An account stakes differing portions of their balance to a set of
AccountIds for several varying staking periods (an extension of 2)
—
Reply to this email directly, view it on GitHub
<#408 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDBYW54PEXLC72Q3WHPQZDVC5HURANCNFSM5RYRXVHQ>
.
You are receiving this because you were mentioned.Message ID:
<hashgraph/hedera-improvement-proposal/repo-discussions/408/comments/2488342
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
There may not be an overstake at the time you choose to stake. But later,
when your balance increases, that might cause an overstake. So there has to
be a mechanism for dealing with overstaking.
…On Mon, Apr 4, 2022 at 11:03 AM rblinton ***@***.***> wrote:
Will you please elaborate on the motivation to have the network allow the
over-staking as opposed to having the network reject it at the time the
request is made.
—
Reply to this email directly, view it on GitHub
<#408 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDBYW5NBOM6H6WYESZVP3DVDMHGVANCNFSM5RYRXVHQ>
.
You are receiving this because you were mentioned.Message ID:
<hashgraph/hedera-improvement-proposal/repo-discussions/408/comments/2501712
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, a Hedera account. At any given time, each hbar will be in some Hedera
“account”. That account has a private key associated with it. And the hbar
can only be moved out of the account if there is a signature created with
that private key.
If you’re using third party wallet software, it may be that it’s helping
you manage your account. If the software actually stores the private key on
your computer or on your phone, then you do have control of your account,
and you should be able to stake it and earn rewards.
On the other hand, if the third party is acting as a custodian of your
hbars, then they will have the private key (not you), and they will
actually own and control the account (not you). In that case, they are free
to stake it and earn rewards. Maybe they will share some of those rewards
with you. Maybe they won’t. You’ll have to ask them.
…On Sun, Apr 3, 2022 at 12:24 PM PixelsWarrior ***@***.***> wrote:
Hi Leemon,
Excuse the noob question, in your article you mention that ‘accounts’ can
stake directly to the node, what type of account is this? A Hedera account?
I hold my hbars currently in a third-party wallet, but would like to stake
them directly to the node when it becomes available and not through a
third-party like the wallet provider. What is the process of creating the
account you mention and transferring my hbars directly to that account for
staking?
Thanks in advance, Leemon! And, again, sorry for the basic question.
Kyle
—
Reply to this email directly, view it on GitHub
<#408 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDBYWZPXOO2AFLSZYHPMPLVDHH3PANCNFSM5RYRXVHQ>
.
You are receiving this because you were mentioned.Message ID:
<hashgraph/hedera-improvement-proposal/repo-discussions/408/comments/2495625
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
Some major concerns around the security of the network caused by the effect of renewal fee triggering staking rewards and thus resetting the clock. This is for accounts that has either private key lost or the sole user of the account is no longer living. By the current rules set for receiving rewards, renewal fees would still end up triggered on the account for "eternity". How does it affect the security of the network? 1. Accounts with HBAR that has no active users associated to it, but still be staked to a node (Deceased, lost private key). 2. Continuous payouts to accounts mentioned above, for as long as the ledger exists due to the renewal fee trigger. 3. As the renewal fee is not enough to offset the reward fee, each accounts will keep increasing exponentially its balance at the pace of the APR. 4. Overtaking ratio in a few years where accounts with no access exceeds the balance of accounts with active users. In other words, half of the APR will eventually be paid to accounts that have forever loss access. This trend and ratio will keep increasing over time. (1:1, 1.1:1, 1.21:1.. 2:1). There would be no limit to prevent HBAR from being locked out of circulation permanently. 5. Price appreciation of HBAR as less and less HBAR exist in active circulation. How is this bad you say? Because of the pricing model of API calls on Hedera (the higher the value in USD, the less HBAR you need for API calls), less HBAR volume circulates towards account 0.0.800 for the same amount of transactions. As less HBAR flows through the same system (even though same USD value), less of it gets distributed to accounts for rewards. Eventually, affecting the APR by lowering it and lowering it over time. 6. Staking then becomes no longer as appealing as the APR finally reaches 0.1%, this can take many years, or maybe even decades for this effect to occur. Low to no APR leads to loss in staking, no increased trust from wallet users, loss in decentralization, loss in security of the network. So if this effect takes a long time to become an issue, why only mention it now? Because it is easier to accept change before it is implemented then after millions of users has gotten used to the current payment reward system. Possible solutions
Conclusion: P.S.: A bit about me. I never go on Github and in the 5 years following the Hashgraph technology, I felt this was too important not too flag this issue. Thank you |
Beta Was this translation helpful? Give feedback.
and others
-
This discussion is to discuss HIP-406 - Staking
master/HIP/hip-406.md
@lbaird
Beta Was this translation helpful? Give feedback.
All reactions