It would be really fantastic to see the upper bound limits removed someday, perhaps.
We simply need moar primespersec (network has power) i.e. more folks mining and/or better miners / ASICs etc.,
We simply need moar primespersec (network has power) i.e. more folks mining and/or better miners / ASICs etc.,
I don't believe that the upper bound on shift value is a blocking issue. Back in Dec 2017, YomKi articulated why:
There are a few different methods being used for current gap finding efforts:
- Exhaustive search. This is looking for true record gaps, which means it started at 2 and went up from there. It's intensely computationally expensive. Tomás Oliveira e Silva ran a distributed project from 2005 to 2012 that got to 4e18 using years of work on hundreds of cores. Interestingly, the computational result was used in Helfgott's 2013 proof of the Odd Goldbach Conjecture. Recently the PGS team at mersenneforum have used a different method to extend this and after about 9 months have brought this to 10e18. The number of records per computational effort is very small, however these are true Minimal Gaps -- once found the record is permanent, as no earlier gaps of that size exist.
- Gapcoin. For relatively small P1 values (84-347 digits), choose a random small range, sieve out small multiples, then run Fermat tests to find gaps. While each step is efficient and fast, it's rather inefficient at finding record gaps. It's basically rapidly throwing darts while blindfolded and being spun around -- the only way to get more darts in the target is to throw faster.
- Primorial methods. Gaps are far more common at multiples of primorials without some small divisors, e.g. numbers of the form N * p# / k with k a small square free number. So if one looks at increasing values of N * 191#/30, for instance, using efficient methods for finding the previous and next primes around that point, one can find record gaps many times times faster than the gapcoin method. That is the method used by most other searchers and is what holds all but 3 of the highest merits (those three being from the exhaustive search). There are some minor variations -- Hans Rosenthal in 2017 did searches with a fixed large N and instead varied k. Using the dart analogy from before, this is throwing darts while aiming at the target. The darts are thrown a lot slower, but since they're all thrown in the direction of the target rather than randomly around the room, more of them result in high results.
I find it worth bearing in mind that the Gapcoin code is performing not one but two functions - the discovery of prime gaps with record merit is a designed side-effect of using prime gap search as as a proof-of-work mechanism for a cryptocurrency and that dual functioning requirement necessarily restricts the range of P1 values that can be selected. As I noted, the higher the shift, the larger the primes being sieved and so the lower the hash rate. More efficient primorial-based methods for finding gaps are an ill fit with the requirement to act as a proof-of-work mechanism. The Prime Gap Search group of the mersenne forum has an open source primorial-based gap search implementation but, given its functional focus is on searching gaps, it's not a good solution for a proof-of-work implementation.
The fact that the Gapcoin prime gap record search implementation isn't as efficient as a dedicated approach is an inevitable trade-off arising from its use as a proof-of-work mechanism. Baisically, it's a balance and emphasising one aspect of this dual-functioning comes at the expense of the other.
Also, PM'd to BitcoinFX ...
Quote
I hope to finish this upgrade of Gapcoin to 0.16.3 in time to coincide with your announcement schedule:
Although most of the work is done and it syncs with both mainnet and testnet, it's unreleased because I have yet to get all the tests passing and it's unmentioned publicly because of its capacity to create bech32 txs which 0.9 clients can't handle and which might result in blockchain seizure. Also, I haven't ported the miner - which uses the old and no-longer-supported getwork RPC call - nor have I had time even to test my back-ported implementation of getwork (a potential but unlikely-to-succeed fallback attempt).
Although most of the work is done and it syncs with both mainnet and testnet, it's unreleased because I have yet to get all the tests passing and it's unmentioned publicly because of its capacity to create bech32 txs which 0.9 clients can't handle and which might result in blockchain seizure. Also, I haven't ported the miner - which uses the old and no-longer-supported getwork RPC call - nor have I had time even to test my back-ported implementation of getwork (a potential but unlikely-to-succeed fallback attempt).
You see, 0.16.3 is a bit old as a target for an upgrade, 0.20 would be better, 0.19.1 a minimum. I'm working on it.
Cheers
Graham
