VDF (Verifiable Delay Function) and PRP

[Prime95]

Originally Posted by kriesel

Or 43. GB at 100Mdigit (power 10); ~128. GB at 1Gbit. Each working instance. Vs. 10.8 at 100Mdigit, power 8, 32. GB at 1Gbit power 8.

We can always drop down to power 7 or 6. The certifier must do more work (.8% or 1.6% of a PRP test) instead of .4%. It certainly beats the current 100%.

[preda]

Originally Posted by kruoli

I'd be glad if we could have the opportunity to volunteer on using higher proof exponents (of course with a reasonable limit) as soon as it gets standard for those who have tons of HDD space to spare to reduce server CPU time or at least a prover's CPU time.

Yes, that will likely be an option -- allowing the user to request a proof size higher than 8. In GpuOwl's case this will be limited to 9, because I think the benefit beyond 9 is tiny and not worth the cost on the prover even when HDD space is not an issue. So there are two possibilities, 8 the default and 9 for "I have plenty of disk space".

[retina]

Originally Posted by preda

In GpuOwl's case this will be limited to 9, because I think the benefit beyond 9 is tiny and not worth the cost on the prover even when HDD space is not an issue.

That seems arbitrary.

Just let the user choose whatever they want. It's their cycles/bits, let them do whatever they want with them.

[kruoli]

Here is my proof file generated by the latest version in the windows binary thread. The d373 file is the one from the old version.
http://mc.oliver-kruse.de/GIMPS/gpuOwl/proofs

The program used about half a gigabyte of RAM while building the proof. The process took aroud half an hour.

[preda]

Originally Posted by retina

That seems arbitrary.

Just let the user choose whatever they want. It's their cycles/bits, let them do whatever they want with them.

But there is no good reason to do some things, though the fact is not always obvious. The restrictions are there guide the choice to what makes sense. Let me explain: above 9, the prover has increased cost but there is no significant benefit (on the verification side) for that cost. Below 7, the prover has no significant benefit, but there is a v. large additional cost on the verifier. The user may not always understand or be aware of these trade-offs when choosing integer values, that's why there are bounds.

But probably I'll extend the proof power range to 6-9.

[preda]

And 215856353 is verified composite! hooray! (the verification took under 8minutes)

Originally Posted by kruoli

Here is my proof file generated by the latest version in the windows binary thread. The d373 file is the one from the old version.
http://mc.oliver-kruse.de/GIMPS/gpuOwl/proofs

The program used about half a gigabyte of RAM while building the proof. The process took aroud half an hour.

2020-07-17 06:22:28 XFX proof verification: doing 210798 iterations
2020-07-17 06:23:28 XFX 20000 / 210798, 2967 us/it
2020-07-17 06:24:08 XFX 40000 / 210798, 2003 us/it
2020-07-17 06:24:44 XFX 60000 / 210798, 1810 us/it
2020-07-17 06:25:21 XFX 80000 / 210798, 1809 us/it
2020-07-17 06:25:57 XFX 100000 / 210798, 1810 us/it
2020-07-17 06:26:33 XFX 120000 / 210798, 1810 us/it
2020-07-17 06:27:09 XFX 140000 / 210798, 1810 us/it
2020-07-17 06:27:45 XFX 160000 / 210798, 1810 us/it
2020-07-17 06:28:22 XFX 180000 / 210798, 1811 us/it
2020-07-17 06:28:58 XFX 200000 / 210798, 1811 us/it
2020-07-17 06:29:18 XFX proof: 215856353 proved composite
2020-07-17 06:29:18 XFX proof '/home/preda/Downloads/215856353-10.proof' verified

[retina]

Originally Posted by preda

But probably I'll extend the proof power range to 6-9.

Still arbitrary.

"No significant benefit" ... that you can see now. People might want to use it for testing RAM, or HDD space, or something. We can't know what uses people will make of it.

[preda]

Originally Posted by retina

Still arbitrary.

"No significant benefit" ... that you can see now. People might want to use it for testing RAM, or HDD space, or something. We can't know what uses people will make of it.

Yes, but
1. the user can still do what he wants, it's just a tiny bit more difficult to make "unusual" (i.e. probably silly) things, but still possible (because open-source, simple to change/remove the check)
2. consider the flip-side of absolute freedom:
a) the user runs with -proof 1, because he doesn't understand what that means -- the server and the verifier is seriously unhappy. Lost opportunity for a useful proof.
b) the user runs with -proof 20 because.. no idea; he wants to be helpful? The SSD dies, HDD fills up, system slows to a crawl, anyway all work lost because disk full, etc. User unhappy because "broken software" and now broken HW too, leaves project in anger.

[Prime95]

Originally Posted by preda

Yes, but

Prime95 dealt with this by making the common, everyday, protect-the-user options available from dialog boxes. The uncommon, power user, use-at-your-own-risk options are buried in undoc.txt.

That has worked fairly well, though sometimes people think they are power users when they are not...

@retina: One could consider editing the gpuowl source as the power user's way to get around "arbitrary" limitations.

Prime95 defaults proof power to, I think, anywhere from 6 to the-maximum-that-makes-sense-for-that-exponent. The user actually tells prime95 how much temp disk space each PRP test is allowed to use and prime95 chooses the power accordingly -- default is 5GB. Since, this has not been released yet, I reserve the right to change my mind :)

[Prime95]

Originally Posted by preda

And 215856353 is verified composite! hooray! (the verification took under 8minutes)

Cool! Still the proof file must be saved for later uploading to the server. Verification is not "official" until it goes through official channels. Besides, it will serve as a good early test case.

[kruoli]

Originally Posted by Prime95

Still the proof file must be saved for later uploading to the server.

I'll leave my file on my server and keep a local copy of it. Additionally, I'll keep my ca. 25 GB of temporary files. If those could be helpful for testing, too, I could make them availible, too.