Yagna Requestor - Add Global task price settings

[Atlas16A]

Simply put this would work in a similar way as how providers set their prices in the cli. A requestor would input these settings to: Have them override prices set within task scripts Have them override prices set within task scripts that go over the requestors settings Have them act as defaults if a task script does not provide price limits.

This would help requestors set their own price limits without having to edit task script files. It would also help developers who want to share their task scripts as they wont have to add it as a run variable for users.

[figurestudios]

Is this just for the budget value used in yajsapi and yapapi? Market strategies are super advanced and can't just be a bunch of values -- sometimes you will need to rent a particular type of machine for the task you are working on, and sometimes you just need any machine. While I don't see why this can't just be an environment variable in the requestor script, I do see how it could be made to steal funds if it isn't in place if requestors trust anyone with any requestor scripts.

[Atlas16A]

Is this just for the budget value used in yajsapi and yapapi? Market strategies are super advanced and can't just be a bunch of values -- sometimes you will need to rent a particular type of machine for the task you are working on, and sometimes you just need any machine. While I don't see why this can't just be an environment variable in the requestor script, I do see how it could be made to steal funds if it isn't in place if requestors trust anyone with any requestor scripts.

Yea, right now its an environment variable in the task scripts, but let's frame the idea in a context that helps requestors.

Say for instance Im a malicious dev, right now in theory I could spend up a provider with a high cpu hour cost, under normal market i wouldn't get tasks, however if I make a script that's let's say renders blender scenes, and I make it target that provider and then promote me script to less technical people I can quickly steal funds from users and they wouldn't be able to easily figure out why it costs so much.

With global cost values the user can set their own budget directly without editing scripts and it can protect them from this type of attack. Similarly there are other types of attacks that can be used to drain funds by manipulative behaviors like this.

We need to assume that the people using golem are most likely not going to be the same people developing scripts for golem and as such protecting them while not limiting devs is a big deal.

[figurestudios]

Actually I didn't think over that stealing funds part -- if they can trick you to use a completely different market strategy, why wouldn't they be able to sneak in a way to change the budget? Or otherwise send funds from your wallet? If they can get you to run scripts on your PC, they can easily get what they want, regardless of the budget or not. It's not hard to run a command from a script.

[Atlas16A]

Actually I didn't think over that stealing funds part -- if they can trick you to use a completely different market strategy, why wouldn't they be able to sneak in a way to change the budget? Or otherwise send funds from your wallet? If they can get you to run scripts on your PC, they can easily get what they want, regardless of the budget or not. It's not hard to run a command from a script.

I've asked on the discord before and apparently task scripts can not directly interact with yagna outside the yapapi and yajsapi api's. Hence why my example doesn't directly manipulate yagna, only useds the currently available market functions to be malicious, but the fact that you can be malicious with just the current api capabilities is a bad thing for requestors.

[wkargul]

Hi @Atlas16A and @figurestudios,

Thank you both for your commitment, we appreciate your activity here! @Atlas16A can you please clarify if there is still some issue with your case? What kind of solution do you propose? Did you try to get through API's documentation?

[stranger80]

Hi @Atlas16A,

As @wkargul noted, your voice here is appreciated. As far as I can see, you may have an idea for a feature (probably onyagna daemon level).

We have a process to summarize and evaluate feature proposals (Golem Amendment Proposal - GAP, specified here: GAP Process) - would you consider putting your idea in a GAP proposal, which requires to consider various aspect of a proposed feature? That way we can get a better understanding of your concept, and put it through a discussion.

Please let us know if you would like to follow that route, and if any assistance from our side is required.

[Atlas16A]

Yea sure, @stranger80 ill get to work on it probably tomorrow before night shift starts.

[wkargul]

It should be closed as we have not had feedback for such a long time