Reserving 54441_249 (15e).

C231_133_73 is queued on 14e but is listed as a 32-bit job even though it was tested and uploaded as a 31-bit job. No big deal if the ‘bits’ field can’t be changed once the job is sieving, just pointing it so we don’t chase an additional unnecessary 200M+ relations. The .poly file on NFS@Home data page confirms it is a 31-bit job.

If it is indeed now a 32-bit job by the gatekeeper’s judgment then I retract my comment.

Either way I’m willing to reserve this number.

Thanks for catching that one!

The 'bits' field can be changed at any time, all it affects is the recommendation for maximum Q given by the admin page.

8081^67-1 (15e) factored
 

186.1M unique relations to build a matrix at 16.8M using TD=120.
[CODE]p71 factor: 13018465391791877739534473346053605419326814239734112223261860630234563
p188 factor: 60005491813845874845922138955322440313760259802388555416644486485401844829638861704147029280521023186384482791513684974252895215136658127172706273551190471659942821733672921209552246986769[/CODE]
[url]https://pastebin.com/eTbixnL2[/url]

Phi_13(Phi_5(Phi_13(17)/212057)/41*31*1708293108577921) factored

[code]
prp40 factor: 8328516800907981747615892893604213469249
prp128 factor: 29023524528146565011072844291082294417807204916208789404156435394760467534360384038556657772859476546887720723164295017003532931
[/code]

[QUOTE=swellman;472686]Phi_13(Phi_5(Phi_13(17)/212057)/41*31*1708293108577921) factored

[code]
prp40 factor: 8328516800907981747615892893604213469249
prp128 factor: 29023524528146565011072844291082294417807204916208789404156435394760467534360384038556657772859476546887720723164295017003532931
[/code][/QUOTE]

A p40 - yikes!!!
I was told this was in the batch that had 10,000 @ 43e6. The previous factor is a p38. I wonder if they stopped after finding that one. I didn't run anymore curves because 10K @ 43e6 was enough (supposedly) for an SNFS-227.

[QUOTE=RichD;472690]A p40 - yikes!!!
I was told this was in the batch that had 10,000 @ 43e6. The previous factor is a p38. I wonder if they stopped after finding that one. I didn't run anymore curves because 10K @ 43e6 was enough (supposedly) for an SNFS-227.[/QUOTE]

Hmm yes; ecm-toy reckons essentially zero probability for even a remaining p45 after 10k @ 43e6.

I'm sorry to nag, but would people mind doing the pastebin upload as well as attaching compressed logs? Or is there a problem with pastebin access being blocked by some network provider?

[QUOTE=fivemack;472711]I'm sorry to nag, but would people mind doing the pastebin upload as well as attaching compressed logs? Or is there a problem with pastebin access being blocked by some network provider?[/QUOTE]

When the push to use pastebin started I did try to post my results there. Got mulitple viruses across several of my machines all with decent AV protection. Took a weekend to get them all scrubbed. Sorry, but I won’t go there again.

Is there an safe alternative?

[QUOTE=RichD;472690]A p40 - yikes!!!
I was told this was in the batch that had 10,000 @ 43e6. The previous factor is a p38. I wonder if they stopped after finding that one. I didn't run anymore curves because 10K @ 43e6 was enough (supposedly) for an SNFS-227.[/QUOTE]

No worries. It was such a fast SNFS effort that applying “proper” levels of ECM would probably taken > 1/3 * time_SNFS. Not a big deal.

6867^67-1 (15e) factored
 

(really 6863^67-1)
200M unique relations to build a 12.0M matrix using TD=132 (136 failed).
[CODE]p111 factor: 846694305477709720259619292669734792482240938014752030025440527027725521799338428108899756401706088088679430523
p143 factor: 19154048072130794265107793995641965997475939746992910048793095165056125031180414728267212301314669373079195222008688528022110014812486853012291[/CODE]
[url]https://pastebin.com/wDEYZiqH[/url]