New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Steem Power Delegation for Voting and Bandwidth #818

Closed
bytemaster opened this Issue Jan 20, 2017 · 26 comments

Comments

Projects
None yet
@bytemaster
Contributor

bytemaster commented Jan 20, 2017

The idea behind Steem Power Delegation is to enable new account creation without having to worry about hackers draining an account signup pool. This process also enables 3rd party websites to create new accounts.

An account can delegate their Steem Power to another account which will give that account extra bandwidth and extra voting power. The amount delegated will be denominated in MVESTS and will automatically be retracted in the event that the source account runs out of MVESTS due to power down. The oldest delegated MVEST will be retracted first.

This feature will enable people with multiple accounts to delegate all of their Steem Power to a single account and reduce unnecessary voting spam.

New Operation:

update_vote_delegation from to MVEST

Accounts may not delegate delegated MVESTS, only their own. All accounts will now have the following fields:

vesting_shares // same as today
delegated_vesting_shares // total this account has delegated to others <= vesting_shares
effective_vesting_shares  // vesting_shares - delegated_vesting_shares + total_received

This change will not impact how witness scheduling works because witness scheduling already supports its own delegation system.

When Steem Power is delegated curation rewards do not propagate back to the source, but belong to the account that received delegation.

The minimum delegation amount will be the account creation fee or what ever higher value witnesses set by soft fork.

When removing delegated SteemPower, it needs to be held for the VOTE regeneration period (5 business days)... this would still allow someone to vote for the same post twice from two accounts, so the delay needs to be the POST PAYOUT PERIOD. (7 days).

Delegated bandwidth also needs a delay when it is "revoked" to prevent someone from spamming the network by consuming all bandwidth, re-delegate, consume all bandwidth. Might as well make this 7 days as well.

Once we make reward payouts explicit virtual ops, only nodes processing votes or bandwidth calculations would need to perform these calculations.

All nodes participating in the P2P network need to process bandwidth calculations to prevent network spam of pending transactions.

@xeroc

This comment has been minimized.

Show comment
Hide comment
@xeroc

xeroc Jan 20, 2017

Interesting idea. So this allows me to create an account without(?) paying a fee as long as I delegate some voting power that I can retract later on?
Why would that prevent me from spam the blockchain with accounts?

xeroc commented Jan 20, 2017

Interesting idea. So this allows me to create an account without(?) paying a fee as long as I delegate some voting power that I can retract later on?
Why would that prevent me from spam the blockchain with accounts?

@TimCliff

This comment has been minimized.

Show comment
Hide comment
@TimCliff

TimCliff Jan 20, 2017

Contributor

This sounds really cool!

Would it be possible to include a parameter to allow a portion of the curation rewards to go back to the original SP owner? It would open up a lot of possibilities as far as high stakeholders 'hiring' good curators (who don't themselves have a lot of SP) while retaining some of the benefit of their SP.

Contributor

TimCliff commented Jan 20, 2017

This sounds really cool!

Would it be possible to include a parameter to allow a portion of the curation rewards to go back to the original SP owner? It would open up a lot of possibilities as far as high stakeholders 'hiring' good curators (who don't themselves have a lot of SP) while retaining some of the benefit of their SP.

@abitmore

This comment has been minimized.

Show comment
Hide comment
@abitmore

abitmore Jan 20, 2017

Contributor

due to power down. The oldest delegated MVEST will be retracted first.

Would this need a delay as well? If not, the retracted power can be used to vote on a post again. Or perhaps we can do the retraction in advance?

The minimum delegation amount will be the account creation fee or what ever higher value witnesses set by soft fork.

Since the fee is changing consistently, there would be a case that a fee raising and/or new/changed soft fork code could cause a delegated power be insufficient (less than minimum required value). How to deal with this?

Contributor

abitmore commented Jan 20, 2017

due to power down. The oldest delegated MVEST will be retracted first.

Would this need a delay as well? If not, the retracted power can be used to vote on a post again. Or perhaps we can do the retraction in advance?

The minimum delegation amount will be the account creation fee or what ever higher value witnesses set by soft fork.

Since the fee is changing consistently, there would be a case that a fee raising and/or new/changed soft fork code could cause a delegated power be insufficient (less than minimum required value). How to deal with this?

@abitmore

This comment has been minimized.

Show comment
Hide comment
@abitmore

abitmore Jan 20, 2017

Contributor

I don't think it's appropriate to implement this feature in HF17, since it's not related to protocol cleanup nor simplification. On the 2017 road map, target for this feature is Q3.

Contributor

abitmore commented Jan 20, 2017

I don't think it's appropriate to implement this feature in HF17, since it's not related to protocol cleanup nor simplification. On the 2017 road map, target for this feature is Q3.

@pfunks

This comment has been minimized.

Show comment
Hide comment
@pfunks

pfunks Jan 20, 2017

so the delay needs to be the POST PAYOUT PERIOD. (7 days).

Does this mean the elastic payout period, in other words the extension of the payout period with more weighted votes after time has passed, won't be included in the proposed 7-day period?

Also, am I correct in thinking that delegated SP would not allow power downs on accounts that have less than 10x the current network account creation fee?

I'd also like to second @abitmore's notion that the current proposed hardfork has enough going on already.

pfunks commented Jan 20, 2017

so the delay needs to be the POST PAYOUT PERIOD. (7 days).

Does this mean the elastic payout period, in other words the extension of the payout period with more weighted votes after time has passed, won't be included in the proposed 7-day period?

Also, am I correct in thinking that delegated SP would not allow power downs on accounts that have less than 10x the current network account creation fee?

I'd also like to second @abitmore's notion that the current proposed hardfork has enough going on already.

@aaroncox

This comment has been minimized.

Show comment
Hide comment
@aaroncox

aaroncox Jan 20, 2017

Contributor

I'd rather see this feature over pretty much anything I've seen from upcoming versions (except communities). It's not going to excite blockchain users or the users currently on steemit.com, but it will excite 3rd party developers.

One of the major barriers to many 3rd party app concepts is account creation. Most (myself included) don't have a huge bank roll of STEEM, and cannot simply allow the creation of accounts through any application I make due to the account creation fee. I could only make ~6k accounts if I spent every STEEM I have, which isn't a whole lot.

With some discussions we've had in slack, some of the major concerns brought up was various forms of abuse (name squatting and multiple accounts being prominently discussed). To combat abuse, some requirements should be brought into play that bring this on parity with what it would take to create an account and fully power down an account. Perhaps even greater than what it would take. Here were some of the baseline ideas discussed:

  • When delegating SP, the sponsoring account should have to delegate an amount equal to what it would take for an account to be created, then fully powered down (so roughly 10x account creation fee). That would mean currently for a delegated SP account to be created, it would take ~300SP worth of VESTS.
  • To retrieve the delegated SP from an account, it should act almost identical to a power down, taking 13 weeks to return the delegated amount.

There may be more that should be on this list, but these rules are designed to make it more beneficial for someone (looking to squat names, have more accounts, etc) to use the create_account command rather than just delegating their SP.

Overall, this idea keys into the 2017 goal of acquisition. It won't cause immediate growth the day it's released, but it would allow a new class of 3rd party applications to be developed, which would cause further growth throughout the year as these apps are released.

This specific problem of account creation has caused me to shelve a number of ideas that could potentially attract new users, and slowed down others (like a hosted reprint blogging platform).

There are some questions/issues to be resolved as mentioned above - but the long term impact this could have is potentially enormous. If there are conversations and issues that need to be resolved, I'd love to see those conversations start sooner rather than later.

Contributor

aaroncox commented Jan 20, 2017

I'd rather see this feature over pretty much anything I've seen from upcoming versions (except communities). It's not going to excite blockchain users or the users currently on steemit.com, but it will excite 3rd party developers.

One of the major barriers to many 3rd party app concepts is account creation. Most (myself included) don't have a huge bank roll of STEEM, and cannot simply allow the creation of accounts through any application I make due to the account creation fee. I could only make ~6k accounts if I spent every STEEM I have, which isn't a whole lot.

With some discussions we've had in slack, some of the major concerns brought up was various forms of abuse (name squatting and multiple accounts being prominently discussed). To combat abuse, some requirements should be brought into play that bring this on parity with what it would take to create an account and fully power down an account. Perhaps even greater than what it would take. Here were some of the baseline ideas discussed:

  • When delegating SP, the sponsoring account should have to delegate an amount equal to what it would take for an account to be created, then fully powered down (so roughly 10x account creation fee). That would mean currently for a delegated SP account to be created, it would take ~300SP worth of VESTS.
  • To retrieve the delegated SP from an account, it should act almost identical to a power down, taking 13 weeks to return the delegated amount.

There may be more that should be on this list, but these rules are designed to make it more beneficial for someone (looking to squat names, have more accounts, etc) to use the create_account command rather than just delegating their SP.

Overall, this idea keys into the 2017 goal of acquisition. It won't cause immediate growth the day it's released, but it would allow a new class of 3rd party applications to be developed, which would cause further growth throughout the year as these apps are released.

This specific problem of account creation has caused me to shelve a number of ideas that could potentially attract new users, and slowed down others (like a hosted reprint blogging platform).

There are some questions/issues to be resolved as mentioned above - but the long term impact this could have is potentially enormous. If there are conversations and issues that need to be resolved, I'd love to see those conversations start sooner rather than later.

@sneak

This comment has been minimized.

Show comment
Hide comment
@sneak

sneak Jan 20, 2017

Contributor

We agree, which is why we're going to try to fast-track this and make sure it's out soon. We feel the account creation cost more than any other entity. :)

We've done a lot of thinking about the best ways to combat the abuse of cheap accounts. Accounts will still cost something, just not nearly as much. We also want to simultaneously deploy an account usurpation system so that accounts below a certain funding threshold and a minimum period of idle time can be reclaimed by others who wish to use the username.

Contributor

sneak commented Jan 20, 2017

We agree, which is why we're going to try to fast-track this and make sure it's out soon. We feel the account creation cost more than any other entity. :)

We've done a lot of thinking about the best ways to combat the abuse of cheap accounts. Accounts will still cost something, just not nearly as much. We also want to simultaneously deploy an account usurpation system so that accounts below a certain funding threshold and a minimum period of idle time can be reclaimed by others who wish to use the username.

@sneak

This comment has been minimized.

Show comment
Hide comment
@sneak

sneak Jan 20, 2017

Contributor

Suggestions for appropriate minimum creation costs (we were thinking 0.5-1.0 steem) and usurpation parameters (we were thinking <=10x creation fee balance and >=2y idle) are welcome, along with rationale/justification.

Contributor

sneak commented Jan 20, 2017

Suggestions for appropriate minimum creation costs (we were thinking 0.5-1.0 steem) and usurpation parameters (we were thinking <=10x creation fee balance and >=2y idle) are welcome, along with rationale/justification.

@iamsmooth

This comment has been minimized.

Show comment
Hide comment
@iamsmooth

iamsmooth Jan 21, 2017

As I have stated before, I'm not in favor of attempting to onboard many new users without distributing meaningful stake to them.

Under the loan model, new users would need to earn their stake, but consider the actual numbers. Total stake distributed by content rewards is about 6% per year. Much of that will likely continue to go to existing users for various reasons, which means under this model the totality of new users will likely only be receiving stake at a rate of a few percent a year.

Under the original launch plan, Steemit committed to distribute to new users roughly 40% of the total original supply (perhaps, and I'm guessing here, 30% of the current supply). It is reasonable to assume this would take place over a period of say three years, meaning stake would be redistributed to new users at a rate of approximately 15-18%/year. Replacing that process with a loaned stake model means that stake redistribution is being slowed down by roughly a factor of five or six.

Before opening a loophole that allows creating accounts without distributing stake, there needs to be a clear and detailed plan for how: 1) the stake mined and held by Steemit for the purpose of being given away will in fact be given away, 2) redistribution will occur and new users will acquire stake and become meaningful participants in the system at more than a trivial rate that appears likely to be approximately 80% slower than the original plan, and 3) that the new methods of user acquisition and stake redistribution will be at least as effective in growing the user base as relying on the obvious draw of giving away money (a proven method successfully used countless times to successful grow a customer base).

I do understand the goal of empowering third parties to create new user accounts, but this needs to be accomplished without undermining the also important goal of stake distribution.

iamsmooth commented Jan 21, 2017

As I have stated before, I'm not in favor of attempting to onboard many new users without distributing meaningful stake to them.

Under the loan model, new users would need to earn their stake, but consider the actual numbers. Total stake distributed by content rewards is about 6% per year. Much of that will likely continue to go to existing users for various reasons, which means under this model the totality of new users will likely only be receiving stake at a rate of a few percent a year.

Under the original launch plan, Steemit committed to distribute to new users roughly 40% of the total original supply (perhaps, and I'm guessing here, 30% of the current supply). It is reasonable to assume this would take place over a period of say three years, meaning stake would be redistributed to new users at a rate of approximately 15-18%/year. Replacing that process with a loaned stake model means that stake redistribution is being slowed down by roughly a factor of five or six.

Before opening a loophole that allows creating accounts without distributing stake, there needs to be a clear and detailed plan for how: 1) the stake mined and held by Steemit for the purpose of being given away will in fact be given away, 2) redistribution will occur and new users will acquire stake and become meaningful participants in the system at more than a trivial rate that appears likely to be approximately 80% slower than the original plan, and 3) that the new methods of user acquisition and stake redistribution will be at least as effective in growing the user base as relying on the obvious draw of giving away money (a proven method successfully used countless times to successful grow a customer base).

I do understand the goal of empowering third parties to create new user accounts, but this needs to be accomplished without undermining the also important goal of stake distribution.

@sneak

This comment has been minimized.

Show comment
Hide comment
@sneak

sneak Jan 21, 2017

Contributor

As I have stated before, I'm not in favor of attempting to onboard many new users without distributing meaningful stake to them.

Anything "meaningful" multiplied by the million+ new users we would like to see in 2017 is a significant amount. We may need to onboard several million, depending on retention rates, to reach our initial goals around self-sustaining levels of engagement across a set of communities.

That's a lot of money. Giving away that much "meaningful stake" to free accounts, most of which may not be used very much after signup, is a tremendous waste. Wouldn't you agree that that money is better spent promoting and developing the blockchain than sitting idle in abandoned accounts?

Contributor

sneak commented Jan 21, 2017

As I have stated before, I'm not in favor of attempting to onboard many new users without distributing meaningful stake to them.

Anything "meaningful" multiplied by the million+ new users we would like to see in 2017 is a significant amount. We may need to onboard several million, depending on retention rates, to reach our initial goals around self-sustaining levels of engagement across a set of communities.

That's a lot of money. Giving away that much "meaningful stake" to free accounts, most of which may not be used very much after signup, is a tremendous waste. Wouldn't you agree that that money is better spent promoting and developing the blockchain than sitting idle in abandoned accounts?

@iamsmooth

This comment has been minimized.

Show comment
Hide comment
@iamsmooth

iamsmooth Jan 21, 2017

to free accounts, most of which may not be used very much after signup

I would absolutely support a more gradual method of distributing the stake to new users, perhaps on the basis of "achievements" to be earned over a period of time of based on a level of activity. That would address the issue of idle accounts sitting unused. In no way am I suggesting that the current model of an up-front account fee is the only way it can work. There have also been various discussion of reclaiming new accounts, along with their stake, that turn out to be fraudulent (perhaps could be extended to unused).

Anything "meaningful" multiplied by the million+ new users we would like to see in 2017 is a significant amount.

Please reread my comment. My numbers are aggregate, which means there is no issue of multiplying by the number of users. If we want new users in the aggregate to gain more than about 3% of stake per year then earning it themselves from content rewards can't possibly work.

iamsmooth commented Jan 21, 2017

to free accounts, most of which may not be used very much after signup

I would absolutely support a more gradual method of distributing the stake to new users, perhaps on the basis of "achievements" to be earned over a period of time of based on a level of activity. That would address the issue of idle accounts sitting unused. In no way am I suggesting that the current model of an up-front account fee is the only way it can work. There have also been various discussion of reclaiming new accounts, along with their stake, that turn out to be fraudulent (perhaps could be extended to unused).

Anything "meaningful" multiplied by the million+ new users we would like to see in 2017 is a significant amount.

Please reread my comment. My numbers are aggregate, which means there is no issue of multiplying by the number of users. If we want new users in the aggregate to gain more than about 3% of stake per year then earning it themselves from content rewards can't possibly work.

@matthewniemerg

This comment has been minimized.

Show comment
Hide comment
@matthewniemerg

matthewniemerg Jan 21, 2017

That's a lot of money. Giving away that much "meaningful stake" to free accounts, most of which may not be used very much after signup, is a tremendous waste. Wouldn't you agree that that money is better spent promoting and developing the blockchain than sitting idle in abandoned accounts?

If there's a way to re-claim balances from accounts that are inactive, then this can be avoided.

There are other ways of dealing with 'idle money that has been given away that is now being wasted'.

Solutions that focus on retaining users, increasing engagement, promote user activity should be a focus.

Not to say I don't dislike this idea. But some of the reasoning that you give is completely out of touch with the original model. Let me end by re-iterating a very relevant point.

Under the original launch plan, Steemit committed to distribute to new users roughly 40% of the total original supply (perhaps, and I'm guessing here, 30% of the current supply). It is reasonable to assume this would take place over a period of say three years, meaning stake would be redistributed to new users at a rate of approximately 15-18%/year. Replacing that process with a loaned stake model means that stake redistribution is being slowed down by roughly a factor of five or six.

matthewniemerg commented Jan 21, 2017

That's a lot of money. Giving away that much "meaningful stake" to free accounts, most of which may not be used very much after signup, is a tremendous waste. Wouldn't you agree that that money is better spent promoting and developing the blockchain than sitting idle in abandoned accounts?

If there's a way to re-claim balances from accounts that are inactive, then this can be avoided.

There are other ways of dealing with 'idle money that has been given away that is now being wasted'.

Solutions that focus on retaining users, increasing engagement, promote user activity should be a focus.

Not to say I don't dislike this idea. But some of the reasoning that you give is completely out of touch with the original model. Let me end by re-iterating a very relevant point.

Under the original launch plan, Steemit committed to distribute to new users roughly 40% of the total original supply (perhaps, and I'm guessing here, 30% of the current supply). It is reasonable to assume this would take place over a period of say three years, meaning stake would be redistributed to new users at a rate of approximately 15-18%/year. Replacing that process with a loaned stake model means that stake redistribution is being slowed down by roughly a factor of five or six.

@samupaha

This comment has been minimized.

Show comment
Hide comment
@samupaha

samupaha Jan 22, 2017

As a person who owns steems I don't consider it to be a bad thing that some users abandon their accounts. It means that there will be less liquid steems so my stake will be more valuable.

samupaha commented Jan 22, 2017

As a person who owns steems I don't consider it to be a bad thing that some users abandon their accounts. It means that there will be less liquid steems so my stake will be more valuable.

@mvandeberg

This comment has been minimized.

Show comment
Hide comment
@mvandeberg

mvandeberg Jan 23, 2017

Contributor

Would it be possible to include a parameter to allow a portion of the curation rewards to go back to the original SP owner? It would open up a lot of possibilities as far as high stakeholders 'hiring' good curators (who don't themselves have a lot of SP) while retaining some of the benefit of their SP.

There are some serious technical difficulties with scaling for implementing delegation this way. Right now when a comment is paid out the comment receives a portion of the reward fund proportional to the square of the reward fund, then 25% of that is sent to reward curators. Each curator gets paid based on the weight of their vote and the relative weight to existing votes (not going to get into the math in this post, but it has been discussed at length in other tickets). If we send curation rewards back to those that delegated stake then we have to look up each account that delegated stake and calculate the proportion of the stake was delegated compared to the effective stake of the curator and then weight it by a user defined percentage of how much should be sent back. There are many corner cases here and since we have divided the rewards so much at this point we are likely to be dealing in a lot of dust payments. The blockchain already spends much of the reindex time calculating reward payouts and adding further complexity, both in mental understanding of the process and in the source code itself, is against our goals for this change.

Contributor

mvandeberg commented Jan 23, 2017

Would it be possible to include a parameter to allow a portion of the curation rewards to go back to the original SP owner? It would open up a lot of possibilities as far as high stakeholders 'hiring' good curators (who don't themselves have a lot of SP) while retaining some of the benefit of their SP.

There are some serious technical difficulties with scaling for implementing delegation this way. Right now when a comment is paid out the comment receives a portion of the reward fund proportional to the square of the reward fund, then 25% of that is sent to reward curators. Each curator gets paid based on the weight of their vote and the relative weight to existing votes (not going to get into the math in this post, but it has been discussed at length in other tickets). If we send curation rewards back to those that delegated stake then we have to look up each account that delegated stake and calculate the proportion of the stake was delegated compared to the effective stake of the curator and then weight it by a user defined percentage of how much should be sent back. There are many corner cases here and since we have divided the rewards so much at this point we are likely to be dealing in a lot of dust payments. The blockchain already spends much of the reindex time calculating reward payouts and adding further complexity, both in mental understanding of the process and in the source code itself, is against our goals for this change.

@TimCliff

This comment has been minimized.

Show comment
Hide comment
@TimCliff

TimCliff Jan 23, 2017

Contributor

Ok, thanks for your response!

Contributor

TimCliff commented Jan 23, 2017

Ok, thanks for your response!

@clayop

This comment has been minimized.

Show comment
Hide comment
@clayop

clayop Jan 25, 2017

Sorry about the late input. How does this feature consider different agent's reputation? Is it possible low-rep but rich account delegates his Steem Power to moderate-high rep account to bleach his infamy?

clayop commented Jan 25, 2017

Sorry about the late input. How does this feature consider different agent's reputation? Is it possible low-rep but rich account delegates his Steem Power to moderate-high rep account to bleach his infamy?

@mvandeberg

This comment has been minimized.

Show comment
Hide comment
@mvandeberg

mvandeberg Jan 31, 2017

Contributor

Reputation is a non-consensus metric and we have no plans of making it consensus any time soon. As such, we will not have it impact an account's ability to delegate Steem Power.

Contributor

mvandeberg commented Jan 31, 2017

Reputation is a non-consensus metric and we have no plans of making it consensus any time soon. As such, we will not have it impact an account's ability to delegate Steem Power.

mvandeberg added a commit that referenced this issue Jan 31, 2017

Bandwidth and content voting uses effective vesting shares. New accou…
…nt creation OP that allows delegation on creation #818
@mvandeberg

This comment has been minimized.

Show comment
Hide comment
@mvandeberg

mvandeberg Jan 31, 2017

Contributor

Adding a few more details on delegation.

As stated in the issue, a primary motivation for delegated Steem Power is to allow account creation with a smaller fee. A danger of this is that account's a cheaper to create and consequently easier to name squat. To counter this account creation will be done with a combination of Steem and Delegated Steem Power. If you create an account with only Steem, the required Steem will be a multiple of the lower account creation fee such that it costs roughly the same as today to create an account. However, if you want to delegate Steem Power, you can pay the new minimum fee and agree to delegate Steem Power for a minimum amount of time.

The amount of Steem Power has to be greater than the required amount of Steem or else there would be no incentive at all to create an account with Steem. This creates an effective rate limit on an account limited by how much Steem Power they have. This should be high enough that it is not trivially cheap to create an account but not so expensive that businesses are rate limited to the point of not being able to create accounts at a reasonable rate.

As an example, let's use the the current account creation fee of 30 STEEM and a Steem Power to Steem creation ratio of 5. Under the new system we would reduce the creation fee to 1 STEEM and require a pure Steem creation fee of 30 STEEM. This means that the effective delegation required is 150 STEEM.

initial_delegation = ( STEEM_FEE * 5 ) + DELEGATED_STEEM_POWER

So long as initial_delegation is greater than 150, the account can be created. This means you can create an account with 1 STEEM and 145 Delegated Steem Power, 30 STEEM, 15 STEEM and 75 Delegated Steem Power, or anything in between along the curve defined above.

Contributor

mvandeberg commented Jan 31, 2017

Adding a few more details on delegation.

As stated in the issue, a primary motivation for delegated Steem Power is to allow account creation with a smaller fee. A danger of this is that account's a cheaper to create and consequently easier to name squat. To counter this account creation will be done with a combination of Steem and Delegated Steem Power. If you create an account with only Steem, the required Steem will be a multiple of the lower account creation fee such that it costs roughly the same as today to create an account. However, if you want to delegate Steem Power, you can pay the new minimum fee and agree to delegate Steem Power for a minimum amount of time.

The amount of Steem Power has to be greater than the required amount of Steem or else there would be no incentive at all to create an account with Steem. This creates an effective rate limit on an account limited by how much Steem Power they have. This should be high enough that it is not trivially cheap to create an account but not so expensive that businesses are rate limited to the point of not being able to create accounts at a reasonable rate.

As an example, let's use the the current account creation fee of 30 STEEM and a Steem Power to Steem creation ratio of 5. Under the new system we would reduce the creation fee to 1 STEEM and require a pure Steem creation fee of 30 STEEM. This means that the effective delegation required is 150 STEEM.

initial_delegation = ( STEEM_FEE * 5 ) + DELEGATED_STEEM_POWER

So long as initial_delegation is greater than 150, the account can be created. This means you can create an account with 1 STEEM and 145 Delegated Steem Power, 30 STEEM, 15 STEEM and 75 Delegated Steem Power, or anything in between along the curve defined above.

mvandeberg added a commit that referenced this issue Jan 31, 2017

@tibonova

This comment has been minimized.

Show comment
Hide comment
@tibonova

tibonova Feb 5, 2017

I think delegating SP will help in account creation and I'd be happy to see it in the next HF.

I, as a blogger first, need more accounts (now as a workaround) for bigger, better attention. Now, one couldn't aggregate their VP, and that means less impact of their votes ['cause x²+y² != (x+y)² ] and also unnecessarily spam the network. I'd gladly create new accounts from my SP, rather than pay BTC for it or find the holes in the free account creation. If I were be a developer (one day...) I would like the account creation method even more, because it allows more option to get new users and generates less waste of resources.

I have a question, though.

What happens, when we delegate side accounts' SP to our main account, and UV the side accounts' content with it?

(IMO, it shouldn't count in the rewards allocation process, at least the delegated amount not, like when we UV ourselves. This would also lower abuses, especially indirect ones.)

tibonova commented Feb 5, 2017

I think delegating SP will help in account creation and I'd be happy to see it in the next HF.

I, as a blogger first, need more accounts (now as a workaround) for bigger, better attention. Now, one couldn't aggregate their VP, and that means less impact of their votes ['cause x²+y² != (x+y)² ] and also unnecessarily spam the network. I'd gladly create new accounts from my SP, rather than pay BTC for it or find the holes in the free account creation. If I were be a developer (one day...) I would like the account creation method even more, because it allows more option to get new users and generates less waste of resources.

I have a question, though.

What happens, when we delegate side accounts' SP to our main account, and UV the side accounts' content with it?

(IMO, it shouldn't count in the rewards allocation process, at least the delegated amount not, like when we UV ourselves. This would also lower abuses, especially indirect ones.)

@mvandeberg

This comment has been minimized.

Show comment
Hide comment
@mvandeberg

mvandeberg Feb 6, 2017

Contributor

That is not how vote weights are aggregated. rshares squared is the square of the sum of rshares on a post. So voting with 1M SP on 1 account has the same effect as voting with 100k SP on 10 accounts. Delegated Steem Power has no effect on the potential rewards that a satoshi of Steem Power can allocate.

Contributor

mvandeberg commented Feb 6, 2017

That is not how vote weights are aggregated. rshares squared is the square of the sum of rshares on a post. So voting with 1M SP on 1 account has the same effect as voting with 100k SP on 10 accounts. Delegated Steem Power has no effect on the potential rewards that a satoshi of Steem Power can allocate.

@TimCliff

This comment has been minimized.

Show comment
Hide comment
@TimCliff

TimCliff Feb 18, 2017

Contributor

If a user uses delegates SP to create a bunch of accounts, and then withdraws their delegated SP from those accounts, what happens to them?

Contributor

TimCliff commented Feb 18, 2017

If a user uses delegates SP to create a bunch of accounts, and then withdraws their delegated SP from those accounts, what happens to them?

@mvandeberg

This comment has been minimized.

Show comment
Hide comment
@mvandeberg

mvandeberg Feb 20, 2017

Contributor

There is a minimum delegation period (currently 30 days) and a minimum fee in STEEM even when delegating for account creation. The minimum period enforces a rate limit on account creation and the minimum STEEM ensures that those accounts can transact if the delegation is removed.

Contributor

mvandeberg commented Feb 20, 2017

There is a minimum delegation period (currently 30 days) and a minimum fee in STEEM even when delegating for account creation. The minimum period enforces a rate limit on account creation and the minimum STEEM ensures that those accounts can transact if the delegation is removed.

@mvandeberg

This comment has been minimized.

Show comment
Hide comment
@mvandeberg

mvandeberg Feb 20, 2017

Contributor

I am updating the logic so that delegations made during account creation can be removed immediately if a user misbehaves, but with a longer expiration time. For each delegation expiration, the expiration time will be max( head_block_time() + days( 7 ), min_delegation_time ). Min delegation time is only set on account create with delegation as 30 days after the creation time.'

Contributor

mvandeberg commented Feb 20, 2017

I am updating the logic so that delegations made during account creation can be removed immediately if a user misbehaves, but with a longer expiration time. For each delegation expiration, the expiration time will be max( head_block_time() + days( 7 ), min_delegation_time ). Min delegation time is only set on account create with delegation as 30 days after the creation time.'

@mvandeberg mvandeberg reopened this Feb 20, 2017

mvandeberg added a commit that referenced this issue Feb 20, 2017

Fix some issues with the delegation logic for removing delegations. M…
…akes removing delegation from account creation instant, but with a longer expiration time. #818
@mvandeberg

This comment has been minimized.

Show comment
Hide comment
@mvandeberg

mvandeberg Feb 27, 2017

Contributor

This was implemented and merged

Contributor

mvandeberg commented Feb 27, 2017

This was implemented and merged

@On1x

This comment has been minimized.

Show comment
Hide comment
@On1x

On1x Dec 28, 2017

When removing delegated SteemPower, it needs to be held for the VOTE regeneration period (5 business days)... this would still allow someone to vote for the same post twice from two accounts, so the delay needs to be the POST PAYOUT PERIOD. (7 days).

I'm find abuse in that case.
@account1 vote with all energy for posts in a week cashout window
@account1 delegate SP to @account2
@account2 fast vote again for posts in a week cashout window
@account1 undelegate sp from @account2
... wait 7 days and do it again.

Anyone can use it abuse for x2 votes and rewards. Need to fix it with additional window, but i'm not sure where to place it.

On1x commented Dec 28, 2017

When removing delegated SteemPower, it needs to be held for the VOTE regeneration period (5 business days)... this would still allow someone to vote for the same post twice from two accounts, so the delay needs to be the POST PAYOUT PERIOD. (7 days).

I'm find abuse in that case.
@account1 vote with all energy for posts in a week cashout window
@account1 delegate SP to @account2
@account2 fast vote again for posts in a week cashout window
@account1 undelegate sp from @account2
... wait 7 days and do it again.

Anyone can use it abuse for x2 votes and rewards. Need to fix it with additional window, but i'm not sure where to place it.

@iamsmooth

This comment has been minimized.

Show comment
Hide comment
@iamsmooth

iamsmooth Dec 29, 2017

The effective transfer of vote power to fresh SP can be addressed for delegations by merging the vote power from the sending account to the receiving account. So in the above example if @account1 has drained vote power down to 0%, @account2 has vote power 100%, and the amount of SP being delegated is 3x the amount already in @account2 then the resulting vote power on @account2 after delegation would be 25%.

iamsmooth commented Dec 29, 2017

The effective transfer of vote power to fresh SP can be addressed for delegations by merging the vote power from the sending account to the receiving account. So in the above example if @account1 has drained vote power down to 0%, @account2 has vote power 100%, and the amount of SP being delegated is 3x the amount already in @account2 then the resulting vote power on @account2 after delegation would be 25%.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment