Looking for new feature requests

News updates about the Prohashing pool
Forum rules
The News forum is only for updates about the Prohashing pool.

Replies to posts in this forum should be related to the news being announced. If you need support on another issue, please post in the forum related to that topic or seek one of the official support options listed in the top right corner of the forums page or on prohashing.com/about.

For the full list of PROHASHING forums rules, please visit https://prohashing.com/help/prohashing- ... rms-forums.
User avatar
dragonbyte_llc
Posts: 26
Joined: Wed Mar 21, 2018 7:20 am

Re: Looking for new feature requests

Post by dragonbyte_llc » Thu Jan 24, 2019 4:46 pm

Still looking to use ASICs on Prohashing for the regular CN algo. When I was manually figuring it out with GPU rigs, quite often, the regular CN algo was better profit than Monero, so still looking for that one. That oughtta be a quick add, no?

As for the Baikal auto switching, it would be great if it could be figured out. Don't have any of these machines, but it would certainly increase their value, if they could be combined to find the most profitable coin on each algo they hash, kinda like treating these differing CN algo versions like it was only one.

Cheers!

DB
User avatar
Steve Sokolowski
Posts: 4585
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Re: Looking for new feature requests

Post by Steve Sokolowski » Thu Jan 24, 2019 4:53 pm

jde wrote:How about rest api where we can get live profitability?
While we're definitely open to considering a lot of new features, this one isn't on the list right now. But there's something even better - you can use WAMP to obtain live profitability data as indicated in the documentation.

WAMP is superior to REST because it provides data immediately after it is available, instead of requiring a delay for polling. For people who are trying to only turn on their miners during profitable periods, it isn't really possible to use a REST system for that. The profitability obtained from REST can't be polled frequently enough to switch to the pool before the profits are gone.
maloi
Posts: 2
Joined: Fri Aug 03, 2018 3:10 am

Re: Looking for new feature requests

Post by maloi » Fri Jan 25, 2019 6:21 am

почему я досих пор не получил NewYorkcoin
ibell63
Posts: 6
Joined: Tue Jan 15, 2019 3:22 pm

Re: Looking for new feature requests

Post by ibell63 » Fri Jan 25, 2019 8:59 am

I request a different method for payout proportions:

It appears that the current method for payout proportions is forward looking, meaning that when you set it, you are awarded payouts in that proportion, it has nothing to do with what you have already earned and what that's worth.

I suggest an optional "portfolio" payout proportion where the system tracks all of the assets you've earned and pays out the asset that your portfolio is currently underweight (assuming you haven't sold anything). Yes, I understand that the platform doesn't like to hold assets, so it could keep track of what has already been paid out in addition to what is owed.

Here's a simple example:
Your payout proportions are set to 50% BTC and 50% ETH. You've been paid (and/or are owed) 0.033 BTC and 1 ETH. For the moment, let's pretend that these assets are worth the same amount ($115 USD).

Let's say that tomorrow, the ETH price falls and now your ETH is worth $100, and the BTC is still worth about $115.

Tomorrow, the system sees this price change and pays out 100% ETH until you have $115 worth of ETH again.
Here's why I want this:

It provides a benefit similar to an auto-balancing portfolio, but without trading. It does not increase your tax liability, but would be expected to increase your earnings in the long-run, since the system is always "buying" (ie. trading mining revenue for) whatever is cheapest at the time.
Ian Bell
User avatar
Steve Sokolowski
Posts: 4585
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Re: Looking for new feature requests

Post by Steve Sokolowski » Fri Jan 25, 2019 10:04 am

ibell63 wrote:I request a different method for payout proportions:

It appears that the current method for payout proportions is forward looking, meaning that when you set it, you are awarded payouts in that proportion, it has nothing to do with what you have already earned and what that's worth.

I suggest an optional "portfolio" payout proportion where the system tracks all of the assets you've earned and pays out the asset that your portfolio is currently underweight (assuming you haven't sold anything). Yes, I understand that the platform doesn't like to hold assets, so it could keep track of what has already been paid out in addition to what is owed.

Here's a simple example:
Your payout proportions are set to 50% BTC and 50% ETH. You've been paid (and/or are owed) 0.033 BTC and 1 ETH. For the moment, let's pretend that these assets are worth the same amount ($115 USD).

Let's say that tomorrow, the ETH price falls and now your ETH is worth $100, and the BTC is still worth about $115.

Tomorrow, the system sees this price change and pays out 100% ETH until you have $115 worth of ETH again.
Here's why I want this:

It provides a benefit similar to an auto-balancing portfolio, but without trading. It does not increase your tax liability, but would be expected to increase your earnings in the long-run, since the system is always "buying" (ie. trading mining revenue for) whatever is cheapest at the time.
This is perhaps the most imaginative idea I've heard. I would never have even thought about this. Could others comment on this? I think this is a great idea, but we will need a few posts from people who would commit to using this feature.

I need to think through how CPU-intensive this feature would be to determine feasibility. Computing the earnings for a share is the most difficult thing the system does, and this would require adding another step in the calculations. If there is enough interest, we'd be willing to invest in parallelizing the share insertion even more than it already is to support it.
ibell63
Posts: 6
Joined: Tue Jan 15, 2019 3:22 pm

Re: Looking for new feature requests

Post by ibell63 » Fri Jan 25, 2019 10:54 am

If I understand correctly, the necessary information to do this is already collected:

The system already knows the lifetime payout for a given coin, I guess if you want to have a "reset" feature, you could store a new variable (portfolioResetAmount) that is initialized at 0, then gets set to the lifetime payout amount whenever the "reset" button is pressed. Maybe there could be a setting that runs the "reset" periodically if the user wants the payouts to behave more like they do now. Personally, I would not use this feature, since I want the longest history possible and to buy the asset that is most underweight all-time.
(eg. Daily, Weekly, Monthly, Quarterly, or Annually)

Then calculate "portfolioPayout"

portfolioPayout = (lifetimePayout - portfolioResetAmount)

Then just take all of the portfolio payout amounts of the coins that are in the payout proportions, multiply them by 1 minus the decimal version of the payout proportions, and then multiply that by the price in USD, then payout 100% in whatever asset yields the lowest value.

Edit2: I made a mistake in the way I originally did the above calculation. You need to take 1 minus the decimal payout proportion, because this formula is set up in such a way that lower numbers are favored. The output has no real meaning, but the lowest number is whatever asset your portfolio is most underweight on, if I understand this correctly. Here it is written without using words:

payoutTarget = portfolioPayout * (1-[payoutProportionAsDecimal]) * assetPriceInUSD

Payout 100% in whatever asset has the lowest payoutTarget.

Edit:

I should mention there is one possible caveat to implementing this; slippage. Since it could cause many payouts in the same coin at the same time, the larger volume of orders could cause price slippage on that market. Being that the total volume per day is generally under $20,000 USD, this shouldn't be a huge deal, but it's worth mentioning. Further, the slippage effect should be self-limiting, since the price going back up would cause the payouts to switch to another coin.

On the flip side of this would be lower fees, usually placing larger volume orders on an exchange results in lower fees, and it would make it easier for the pool to hit minimums than it likely is now. Another good thing about implementing this would be it could have an arbitrage-like effect since the orders could be filled through an exchange that has a lower price for that coin than others; I remember reading that Prohashing uses multiple exchanges, which would also limit slippage.

Of course I'm making a bunch of assumptions about how the pool trades with exchanges here, and it could be handled differently than I'm thinking, so I might be incorrect about this. Further, the payout proportions might be handled in a completely different way and there are many ways this "portfolio payout" system could be implemented.
Last edited by ibell63 on Fri Jan 25, 2019 4:58 pm, edited 7 times in total.
Ian Bell
dra2120
Posts: 21
Joined: Thu Aug 16, 2018 9:47 am

Re: Looking for new feature requests

Post by dra2120 » Fri Jan 25, 2019 11:50 am

The portfolio idea is really interesting. If the system was automatically getting us "the best deal" on our payout coins, I'd be interested in that.
dra2120
Posts: 21
Joined: Thu Aug 16, 2018 9:47 am

Re: Looking for new feature requests

Post by dra2120 » Fri Jan 25, 2019 12:27 pm

Another idea, that is probably more unique to me, but I'll throw it out there anyway. I would like to be able to have "custodial accounts", and what I mean is, I'd like to be able to take one of my miners and "designate" it for my 3 year old. I figure if I point one machine to mine for him, then by the time he hits college he should be able to pay for it all in mined crypto, but I don't want to set up another whole user account for him. So maybe the ability to send profits to a separate payout address by using the existing password argument to group miners?
ultiman2
Posts: 11
Joined: Wed Oct 31, 2018 9:43 am

Re: Looking for new feature requests

Post by ultiman2 » Fri Jan 25, 2019 3:26 pm

i like the portfolio idea too. for me right now im spliting reward between eth and bitcoin and not selling it for now so something that can balance can be good.
jkndt
Posts: 16
Joined: Sat Nov 17, 2018 6:50 am

Re: Looking for new feature requests

Post by jkndt » Fri Jan 25, 2019 5:29 pm

I run several different types of miner, some of which are for friends or family & at the moment I am using two accounts. This can be a little awkward, because I either have to log out of one account and then into the other or use different browsers on the same device to be able to monitor both accounts at the same time. Maybe a page that lets you view the basics of different accounts that you have the credentials for, with the ability for the user to chose what is displayed?

On the same subject, please can we have a page that gives us a choice of all available items that can be displayed? I look at different items in dashboard and details and charts, but it doesn't flow very well to keep switching between them, especially on mobile.

When I first started using prohashing I wanted to be able to pay earnings to myself, and those I run miners for, all in LTC but to different wallets, I never managed to get that to happen. I would like to be able to save several different payout addresses per coin and give each an easy to use label, then be able to select payout percentage to any labelled address or combination of. As an enhancement to that, be able to set payout settings at a group level, with any unset percentage then defaulting to the account level payout settings.

More historical data for earnings in worker group details with the ability to export the data. It's not in group history charts either.

For earnings in worker group details to show the actual currency and amount (at that time) they paid out in as well as USD. Also to which labelled payout address if that gets implemented.

Be able to put individual miners in to multiple groups, whether by multiple o= args or using a comma separated list.

A filter for account activity, to display either Earned, Payout or both would be good.

More options for notifications. Number of miners, for instance. Also at a group level, not just total. Would also like to be able to change the frequency of emails and have an option for the maximum number of emails sent by any one individual event.

Sorry for how long this has gotten. I started off with just two suggestions, but then got carried away!
Post Reply