Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
«123 »
  • Post
  • Reply
Lockback
Sep 2, 2006

All days are nights to see till I see thee; and nights bright days when dreams do show me thee.


QuarkJets posted:

Normally supercomputers charge by computational time, which captures what you described. But it's very easy to spoof that to be whatever you want, if you exclusively own the hardware.

They pay by CPU hour, which is by computation. You can pretty easily instead attach a computational amount to each piece of work and then pay out based on what you complete. The tricky part won't be tracking what you've done, it'll be ensuring that you actually did it vs just made up something random.

No plan would care if it took you 6 seconds or 6000 and pay you by that, they'd just pay you based on what you churned out.

Adbot
ADBOT LOVES YOU

QuarkJets
Sep 8, 2008

Fuck your duck dynasty

Lockback posted:

They pay by CPU hour, which is by computation. You can pretty easily instead attach a computational amount to each piece of work and then pay out based on what you complete. The tricky part won't be tracking what you've done, it'll be ensuring that you actually did it vs just made up something random.

No plan would care if it took you 6 seconds or 6000 and pay you by that, they'd just pay you based on what you churned out.

"Cpu hour" is computational time, it accounts for the fact that different computations take different lengths of time. "per computation" implies that time per computation is not a factor, which is not done anywhere that I know of

I think that attaching a certain amount of computational time (e.g. CPU hours) to a job submission is fine. But say that I want as many digits of pi as possible and I say that I want 100 cpu hours attached to the task. Even with verification of outputs, some systems will produce a different number of digits in the same amount of computational time. How do you identify bad actors in such a situation? "You can't" may be an acceptable answer, but it would be great to solve the problem anyway

Comfy Fleece Sweater
Apr 2, 2013

FOUNDER AND PRESIDENT OF THE KUATO FAN CLUB 4/2/13-PRESENT

KUATO IS MY HERO! AMA!


QuarkJets posted:

"Cpu hour" is computational time, it accounts for the fact that different computations take different lengths of time. "per computation" implies that time per computation is not a factor, which is not done anywhere that I know of

I think that attaching a certain amount of computational time (e.g. CPU hours) to a job submission is fine. But say that I want as many digits of pi as possible and I say that I want 100 cpu hours attached to the task. Even with verification of outputs, some systems will produce a different number of digits in the same amount of computational time. How do you identify bad actors in such a situation? "You can't" may be an acceptable answer, but it would be great to solve the problem anyway

BLOCKCHAIN!

craig588
Nov 19, 2005



I switched my PC to Folding @ Home and it "pays" a variable amount based on how loaded the PC was. If it gets all the GPU time it credits more than if I'm playing games. The way it verifies is sending the same job to multiple computers, there are apparently enough fast computers volunteering for the duplicate work to still be worth it though.

Edit: To elaborate further I think it determines a work unit should take 2 hours and it slides the points around based on if it's faster or slower.

craig588 fucked around with this message at Sep 21, 2018 around 02:30

DrDork
Dec 29, 2003
commanding officer of the Army of Dorkness

QuarkJets posted:

Even with verification of outputs, some systems will produce a different number of digits in the same amount of computational time. How do you identify bad actors in such a situation? "You can't" may be an acceptable answer, but it would be great to solve the problem anyway

craig588 posted:

The way it verifies is sending the same job to multiple computers, there are apparently enough fast computers volunteering for the duplicate work to still be worth it though.

Yeah, the answer to the "bad actors" issue is to simply farm out the same computation to multiple nodes, and then look for a consensus result. The real question is can you get that consensus using a small enough duplication factor so that the cost of doing the same thing X times doesn't let the monetary cost exceed simply running it on AWS or another HPC farm whose one-run output you implicitly trust. Idle buttcoin farms will work for very low wages, but generally won't work for free or at a loss (unless you pay them in fake crypto coins, I suppose...).

Eyes Only
May 20, 2008

Do not attempt to adjust your set.


Man I hate to contribute to this thread, but cryptonerds did make my machine learning box pay for itself. Plus I guess it's not really crypto if we're talking about legit computation.

DrDork posted:

Yeah, the answer to the "bad actors" issue is to simply farm out the same computation to multiple nodes, and then look for a consensus result. The real question is can you get that consensus using a small enough duplication factor so that the cost of doing the same thing X times doesn't let the monetary cost exceed simply running it on AWS or another HPC farm whose one-run output you implicitly trust. Idle buttcoin farms will work for very low wages, but generally won't work for free or at a loss (unless you pay them in fake crypto coins, I suppose...).

This seems pretty simple to me; the answer is you can beat bad actors easily enough as long as you split the computation into discrete jobs and only pay out an address once it has completed N jobs.

The way I imagine it, before payout the system randomly duplicates some % of the jobs and gives them to other actors to check. If you don't trust the checkers, you can establish trust by checking a fraction of their checks, recursively going up the tree with progressively fewer checks until you get to some "central" authority - presumably the original issuer of the job since their interest is aligned here.

At payout time, you randomly check X% of jobs for that actor. If any fail, the actor forfeits the entire payout. The math works out such that as long as N is greater than 1/X cheating will be entirely unprofitable. If you cheat 100% of the time you'll never get paid. If you cheat more intelligently just some of the time, you may have a chance of getting away with it, but you'll also have to contribute real compute to ensure that chance isn't zero. In the end you will wind up forfeiting more real compute than you gain from cheating, regardless of what fraction of your results are fake.

Naturally you'd want some buffer room in either N or X to account for the checker trust system, but in total you can get the overhead to be pretty low. At a 1% checkrate you only need 100 jobs per payout to secure the system - achievable for most distributed tasks if you're targeting weekly or monthly payouts for a typical actor.

You'd need a reverse-check system to prevent the job issuers themselves from maliciously marking everyone as cheaters at the root level, and one for preventing actors from DDoSing the system by spamming fake results for no benefit. I think this idea can be applied to the former in the same way with little overhead since the issuer isn't checking a large number of results. I presume the latter is already solved in existing blockchain protocols somehow.

Adbot
ADBOT LOVES YOU

Stickman
Feb 1, 2004
"Larger than your hat, but quite a bit smaller than the moon" -DNA

Eyes Only posted:

Man I hate to contribute to this thread, but cryptonerds did make my machine learning box pay for itself. Plus I guess it's not really crypto if we're talking about legit computation.


This seems pretty simple to me; the answer is you can beat bad actors easily enough as long as you split the computation into discrete jobs and only pay out an address once it has completed N jobs.

The way I imagine it, before payout the system randomly duplicates some % of the jobs and gives them to other actors to check. If you don't trust the checkers, you can establish trust by checking a fraction of their checks, recursively going up the tree with progressively fewer checks until you get to some "central" authority - presumably the original issuer of the job since their interest is aligned here.

At payout time, you randomly check X% of jobs for that actor. If any fail, the actor forfeits the entire payout. The math works out such that as long as N is greater than 1/X cheating will be entirely unprofitable. If you cheat 100% of the time you'll never get paid. If you cheat more intelligently just some of the time, you may have a chance of getting away with it, but you'll also have to contribute real compute to ensure that chance isn't zero. In the end you will wind up forfeiting more real compute than you gain from cheating, regardless of what fraction of your results are fake.

Naturally you'd want some buffer room in either N or X to account for the checker trust system, but in total you can get the overhead to be pretty low. At a 1% checkrate you only need 100 jobs per payout to secure the system - achievable for most distributed tasks if you're targeting weekly or monthly payouts for a typical actor.

You'd need a reverse-check system to prevent the job issuers themselves from maliciously marking everyone as cheaters at the root level, and one for preventing actors from DDoSing the system by spamming fake results for no benefit. I think this idea can be applied to the former in the same way with little overhead since the issuer isn't checking a large number of results. I presume the latter is already solved in existing blockchain protocols somehow.

I'm not really convinced that a public blockchain structure would offer any advantages over simply centrally controlling the distribution of jobs and verification work. With that sort of central control, you don't have to worry about malicious job issuers and you can simply kick out bad actors after a certain number of infractions, and ban their GPU identifiers to prevent them from creating a new account. You could even create a "trust" system where verification jobs are performed by the most reliable users who have built up solid reputations. Using a public structure would let you create a system that would theoretically run itself, I suppose, but it seems like it would have a hard time competing with more reliable managed systems that could afford to do less validation.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply
«123 »