PRP-VDF and the impact on DC's

[Runtime Error]

Now that VDF-proof PRPs are on the horizon, how will that affect the LL-DC effort? Since LL-DC can result in the need for triple checks, that means that abandoning LL-DC in favor of VDF-PRPs might be optimal. Is that the future?

[Note: This was spun off from the Strategic DC thread.]

[Uncwilly]

Originally Posted by Runtime Error

Now that VDF-proof PRPs are on the horizon, how will that affect the LL-DC effort? Since LL-DC can result in the need for triple checks, that means that abandoning LL-DC in favor of VDF-PRPs might be optimal. Is that the future?

As soon as it is out of beta, doing PRP with VDF should be the first choice (if you can handle the temp storage and upload)
Doing the verification runs if you can handle the download, but not the storage) would be next.
DC LL's next (to clean up the tail end)
DC PRP's when the tail end hits that section.

Our special LL DC's and TC's will still have a place for a while.

[Runtime Error]

Originally Posted by Uncwilly

As soon as it is out of beta, doing PRP with VDF should be the first choice (if you can handle the temp storage and upload)
Doing the verification runs if you can handle the download, but not the storage) would be next.
DC LL's next (to clean up the tail end)
DC PRP's when the tail end hits that section.

Our special LL DC's and TC's will still have a place for a while.

Gotcha. And please forgive me because I know this is not a discussion thread, but just to confirm:

Suppose I want to double check a candidate that one person already found composite with LL. There is about a 2% chance that my LL residue won't match (is that estimate correct?). Since VDF is less than 1% of the effort, it is "cheaper" to ignore the previous LL result and just run PRP+VDF. Preferably, all unconfirmed LL results would be redone as PRP+VDF, as long as the double checker has the disk space and upload capacity. Does that sound right?

A downside to this is not discovering consistently bad machines or bad-faith actors.

[Prime95]

Originally Posted by Runtime Error

A downside to this is not discovering consistently bad machines or bad-faith actors.

Another downside is we won't have work to give to machines that don't upgrade.

I'm seriously considering forcing all machines that do not upgrade (after a reasonable time period) to version 30 to do LL-DC work.

[Fan Ming]

Originally Posted by Prime95

Another downside is we won't have work to give to machines that don't upgrade.

I'm seriously considering forcing all machines that do not upgrade (after a reasonable time period) to version 30 to do LL-DC work.

It would be good to using small-size patches to upgrade automatically (if the machine didn't respond manually for a period time, that can be seen as the user agree to update by default), and stop assigning LL first test work from server(though still preserve LL test function in mprime software). With proper explanation of how strong the security of GEC (or VDF PRP-proof), and how low possibility that a number passed the PRP test is not prime (for example: if you found a mersenne number that passed the PRP test but not prime, then that means you found a thing that is much more awesome than a mersenne prime), I think PRP test is acceptable to most users.

[Uncwilly]

Originally Posted by Fan Ming

It would be good to using small-size patches to upgrade automatically (if the machine didn't respond manually for a period time, that can be seen as the user agree to update by default)

NO. No forced patches. It is my machine, I choose to d/l the software I want. This has been discussed elsewhere.

[LaurV]

I will still continue to do LL and LL/DC for a while. I have a bee under my bonnet about being (and staying) in the hundred percentile

Which is getting easier, with no competition, hehe, as all big guns switched already, or are on the way to switch, to PRP

[Prime95]

Guess we'll have to merge the PRP and LL into one Top Producers page.
Maybe offer double the CPU credit for a PRP test with a proof since it is worth twice as much to the project.

[Fan Ming]

Originally Posted by Uncwilly

NO. No forced patches. It is my machine, I choose to d/l the software I want. This has been discussed elsewhere.

[The thread is unlocked so I reposted here. Just delete the original post posted in another thread.]

That's never forced patches, but the alternative update. It's common sense that the machine was determined by the user, so I wrote that "if the machine didn't respond manually for a period time, that can be seen as the user agree to update by default", which means that the user can manually response "not to update".
Also, stop assigning LL first time test assignment doesn't mean stop accepting LL first time test results. If a user indeed want to submit first time LL results(most likely manual), that's of cource can be accepted.

[Fan Ming]

Originally Posted by Prime95

Guess we'll have to merge the PRP and LL into one Top Producers page.
Maybe offer double the CPU credit for a PRP test with a proof since it is worth twice as much to the project.

I agree with that. And some measures need to be considered to deal with LL first test, like the idea I mentioned.

[retina]

Originally Posted by Fan Ming

"if the machine didn't respond manually for a period time, that can be seen as the user agree to update by default", which means that the user can manually response "not to update".

User gets to choose to update or not. You don't get to tell them to update. Regardless of how you want to word it in some eloquent fashion, it is just another way of saying "forced update".