Help us fix a DLease Bug - 200 BUILDTEAM + 200 STEEM Bounty

avatar



As you all probably know by now, DLease is an excellent way for those with a lot of STEEM POWER to grow their investments, and those who want more STEEM POWER for a limited time to find what they need.

Especially now after HF21 with the curation rewards being 50% of the post payout instead of 25%, having a lot of STEEM POWER is beneficial.

With more and more people using DLease, we're also occasionally running into unexpected bugs that we are not always able to fix ourselves.

The latest bug is that DLease doesn't report the correct available STEEM POWER available for delegation when the user is powering down. Currently, it overstates the available SP.

This info is displayed on your dashboard under Idle STEEM POWER.



If you want to help us solve this, there is a 200 BUILDTEAM Token + 200 STEEM bounty for the first good solution to this problem.

Please contact @thecryptodrive (thecryptodrive#8144) on Discord with your fix or your suggestion for a fix!

The current code to calculate idle STEEM POWER is:

let free = this.powerOwned - this.powerDelegated - this.poweringDown;
let effective = free + this.powerReceived;
let available = effective * this.votingPower;
if (available > free) {
     available = free;}
     return ((available * this.steemPerVest ).toFixed(3))

Thank you for your support!


Visit our website for more!
Subsribe to our YouTube Channel
Check out @Minnowbooster
Don't miss out on @Steemvoter
Set @buildteam as your Steem witness proxy

Set it up today and contribute to building a better tomorrow!


( Want an easier way? Use our SteemConnect proxy link! )

Join our Discord Chat

Get support and connect with us and other BuildTeam fans!



Disclaimer: This is a @steemvoter subscription payment post. Thank you to Steemvoter customers for allowing us to use your Steem accounts to upvote this post by virtue of your free subscription to the Steemvoter.com curation automation service. @steemvoter is proudly a @buildteam subsidiary and sister project to @dlease, @tokenbb, @ginabot, @steemsports. @steemsports-es and @minnowbooster.

Beneficiary Declaration: 10% @null burnpost + 10% @steem.dao

Remember to vote for your favourite Steem proposal at steemproposals.com!

dlease bounty dev steem buildteam palnet
0
0
0.000
17 comments
avatar

Downvoting because I think with #NewSteem it is even more clear than ever that using the reward pool to pay for Steemvoter subscriptions is not really appropriate (it was always controversial).

0
0
0.000
Reply
avatar
(Edited)

Being that the case we may have to start shutting down free or unprofitable services such as GINAbot, QuickSteem, TokenBB etc. We have always done our best to be honourable and run our own nodes etc when our competitors didn't, at great cost to us, we have even taken steps to make our posts have a corporate social responsibility aspect as seen in our footer above with 10% to @null and 10% to @steem.dao.

Our strategy outlined in yesterday's post https://steemit.com/burnpost/@buildteam/buildteam-corporate-social-responsibility-strategy-burnpost-challenge-inside.

In that same post we also laid out a challenge to Steemit inc, which is the biggest elephant in the room and the target that will make the most impact if the community can apply pressure for them to include a tax burn with their programmatic selling.

In that post we highlight that all our services bring in a holistic income that help to keep the lights on during times of low Steem price performance, we are literally on the bones of our bum and now we have to contend with stakeholders downvoting without taking into consideration the holistic picture of our business.

I also urge you to read this post regarding user sentiment towards downvoting and my reply therein:
https://steemit.com/steem/@crypto.piotr/open-letter-to-whales-please-be-mindfull-with-your-mass-downvotes-before-it-s-to-late

0
0
0.000
Reply
avatar
(Edited)

help to keep the lights on during times of low Steem price performance, we are literally on the bones of our bum

We all are, but it also makes the challenges of trying to do something systemically good with the reward pool being directed by proof-of-brain and not milked by self-voting and vote selling all the greater. Every bit of payout is precious at this juncture.

I'm not really familiar with some of the other services–some may be close enough to a public service/public good they would be good candidates for SPS or upvoting of posts about them–but steemvoter specifically, I see very much as a service which offers 90% or more of its value to its customers and its customers should be the ones paying for it, not the reward pool. Others may disagree, and they are free to organically upvote your posts. But my guess is that few stakeholders in fact do disagree, or your wouldn't need to rely on the condition-of-service upvotes.

0
0
0.000
Reply
avatar

A business especially is more vulnerable because it has fixed costs in USD for infra, if a user is on the bones of their bum on Steem and not earning what they used to is different to a business which can go into the negative profit due to infra cost obligations. Atm our team is dissillusioned that we are being targetted and it is serving to re-inforce that Steem is not friendly for business, we are not in the business of milking the rewards pool for frivolity, we provide value, employ developers, many well known names on Steem started out with the support of BuildTeam.

I also don't believe downvoting bodes well for user retention, if my first encounter with you was a downvote, instead of encouragement and support. I likely would not still be here on Steem today.

Also, I cannot take stakeholders' objections seriously unless they take action against the greater problem, which is Steemit inc's systematic selling. Targetting smaller users and businesses is the easy way out to not have to tackle the real problem head on.

0
0
0.000
Reply
avatar

With HF20, the part of the Steempower that would be powered down is subtracted from the effective Steempower.

I've added that logic to dsteem after the HF:

https://github.com/jnordberg/dsteem/commit/12643644965f4605359545468d1f0787be92b953

You can either write it yourself for effective vests:

import {Asset} from 'dsteem'
const vests = Asset.from(account.vesting_shares)
const vests_delegated = Asset.from(account.delegated_vesting_shares)
const vests_received = Asset.from(account.received_vesting_shares)
const withdraw_rate = Asset.from(account.vesting_withdraw_rate)
const already_withdrawn = (Number(account.to_withdraw) - Number(account.withdrawn)) / 1000000
const withdraw_vests = Math.min(withdraw_rate.amount, already_withdrawn)
vests = vests.subtract(withdraw_vests)
vests = vests.subtract(vests_delegated)
vests = vests.add(vests_received)
return vests.amount

Or use the already in-built function for that in dsteem:

const client = new dsteem.Client('https://api.steemit.com')
const account = await client.database.getAccounts(['therealwolf'])
const vests = dsteem.getVests(account)

https://github.com/jnordberg/dsteem/blob/master/src/steem/misc.ts#L247

0
0
0.000
Reply
avatar

Why is already_withdrawn = to_withdraw - withdrawn?
That should be the quantity which is not withdrawn yet and which is missing yet.
(That's the number we use at the moment).
If I do a math.min on that with the withdraw_rate the available quantity doubles and we're already displaying too much.

A bit more detail of our calc:

        store.powerOwned = parseInt( result[ 0 ].vesting_shares.split( " " )[ 0 ] );
        store.powerDelegated = parseInt( result[ 0 ].delegated_vesting_shares.split( " " )[ 0 ] );
        store.powerReceived = parseInt( result[ 0 ].received_vesting_shares.split( " " )[ 0 ] );
        store.poweringDown = parseInt( (result[ 0 ].to_withdraw - result[ 0 ].withdrawn) / 1000000 )
        store.votingPower = result[ 0 ].voting_power / 10000;
0
0
0.000
Reply
avatar

Not sure why you're making it so complicated. The code I linked above (dsteem version) is exactly what I'm using and it spits out the same numbers you'll find on steemd.com. The code you shared seems fine, so I can't tell based on that where the problem might lie, besides that Math.min(withdraw_rate.amount, already_withdrawn) is missing.

0
0
0.000
Reply
avatar

It's because we need a different number than the one on steemd, we need to find out how much of the steempower on the account can be used to delegate.

0
0
0.000
Reply
avatar

Have you checked whether it's voting mana related? If you have 90% voting mana, you can only delegate 90% of your base Steempower

0
0
0.000
Reply
avatar

It's even more that just that. If you have received delegated vests, then you can't delegate more than the % you will drop bellow the amount of vests that belong to the received delegation.

I have come up with a function at home... that I am still reviewing, once I find the right sauce, I will post here.

0
0
0.000
Reply
avatar

Thanks so much for enaging with us to help solve the problem.

0
0
0.000
Reply
avatar
(Edited)

I was starting to have an idea last night about what is intended here. I will see if I can get back to it again today. I understand what it's the objective here, but I need to extrapolate more of the maths involved here to understand if it makes sense.

0
0
0.000
Reply
avatar

Ok... this is my entry =)

I Welcome some feedback @therealwolf

Forgive me the standards and code "beauty" as I am not a dev guy and besides some advanced troubleshooting skills, I can only try to learn from many in terms of programming skills. Either way... this is my contribution.

By the way... @steemchiller, you might want to look at this... as delegating with your tool, under some of these situations, will throw some "warnings" that I have "potentially" covered with this code. =)

# -------------------------------------------------------------------------
store.powerOwned = parseInt( result[ 0 ].vesting_shares.split( " " )[ 0 ] );
store.powerDelegated = parseInt( result[ 0 ].delegated_vesting_shares.split( " " )[ 0 ] );
store.powerReceived = parseInt( result[ 0 ].received_vesting_shares.split( " " )[ 0 ] );
store.poweringDown = parseInt( (result[ 0 ].to_withdraw - result[ 0 ].withdrawn) / 1000000 )
store.votingPower = result[ 0 ].voting_power / 10000;

let free = this.powerOwned - this.powerDelegated - this.poweringDown;
let effective = free + this.powerReceived;
let available = 0;

# locked = PowerReceivedLockedVestsRatio (1 - 0.00)
# This is the absolut ratio of vests that can't be delegated (aka, percentage of VP locked)
###########################################################################
let locked = 0;
if (this.powerReceived > 0) {
    locked = (this.powerReceived / effective);}
if (this.votingPower <= locked) {
    available = 0;
    return ((available * this.steemPerVest ).toFixed(3));
    }
    available = effective * (this.votingPower - locked);
    return ((available * this.steemPerVest ).toFixed(3))
# -------------------------------------------------------------------------
0
0
0.000
Reply
avatar

I confirm that @forykw has solved this bounty and will be receiving the rewards on our distribution day on the 30th.

0
0
0.000
Reply
avatar

And I have learned a lot during the process. So thanks for that!

0
0
0.000
Reply