Yitang Zhang's famous work is about the existence of infinite pairs of primes separated by at most 70000000. It never says that "the gap between two primes would never exceed 70,000,000" because for numbers large enough that gap is expected to exceed any bound. Moreover, Yitang Zhang's work is not a claim: it's a proof, so don't expect it to be refuted any time soon.

Yitang Zhang's work was improved from 70000000 to 600. This means that there exists a number k, such that k<600, and such that there are infinite pairs of numbers p and p+k where both p and p+k are prime. This is the closest we are to proving the twin prime conjecture, which would be similar but for k=2.

In the meantime, Riecoin hasn't run out of primes, so it's looking good

I read your comment in the GAP thread and I was adding the "edit2" part to my post here while you posted here too
we agree GAP would be easier to mine with a GPU

The concept is interesting... it's not better at finding primes than RIC or XPM because it doesn't look for primes, it looks for prime gaps which are relatively large ranges of numbers without any prime number inside. Kind of complementary to what we do. Their primes are at the start and at the end of the gaps.

This part of their "paper" is not accurate:


This was true for the first version of pools and miners, but we've been using the "first + any 3" rule for pool shares for a long time now. This doesn't have this problem as looking for 4-tuples in places were 4-tuples can occur but 6-tuples cannot (to use their language) is actually slower than actually looking for 6-tuples (because we not look for strict 4-tuplets but ask for "first + any 3" of the numbers to be prime, if you strictly look for 4-tuples you lose a lot of combinations).


Also, they don't provide an analysis of the complexity of mining vs the complexity of verification.
The complexity of the verification of a proof of work in RIC is O(log(p)^3) while that of GAP looks like O(log(p)^5), meaning their verification is slower. This may be a problem when the size of the primes grows (in GAP it may need to grow as difficulty increases at a much faster rate than in RIC since the largest gap is expected to be O(log(p)^2) ).

edit: verification seems O(log(p)^5) instead of O(log(p)^4) as I originally wrote. They will eventually have problems with verification performance. This will affect pools too. Too bad... hope I'm wrong, I liked the concept.

edit2: as I read user Supercomputing wrote, GAP looks more gpu-friendly than XPM or RIC. Just pointing out this fact, this may be good or not, idk.

cheers!
Gatra

hi! thanks for your reply.
I did read the FAQ, and I did understand xbridge is the protocol. The question is if there should be one message of that protocol for each possible special service.

The concept is interesting, however I wonder how could I be sure that the node providing the service will not steal my money by not providing the service at all. Can the blocknet chain give me security about that? If so, how could it be possible without tracking every service on every chain? if it has to track everything then it's not like the internet of blockchains, it's more like a giant monster that reimplements all other blockchains.
if it can't provide trustless security then I'd rather exchange my apex to xst and then do the xst transfer without going through the blocknet and paying the blocknet fee. I mean an app could do that, there would be no need for a blocknet chain.

I read much marketing meaningless babble (like "the internet of blockchains"), but not much subtance or technical details...

could you please explain for one use case, from the beginning to the end, how would this work?
e.g. let's say I want to send money using SMS, a feature from XST, while I hold some other thing, let's say APEX. Coins would be automagically exchanged? how? what currency does the service provider receive? can the receiver of the SMS receive other currency than XST? how?

the xbridge api would have a method for each possible service? so it would have to be updated every time a new service is added... otherwise... how would it work?

Is the coding of the exchange and the xbridge api finished? When would this be deployed? right after the ITO?

thanks!

BUT.... this is not inefficient to parallize and doesn't require much RAM per thread: all threads could work on the same sieve...
The sieve of Eratosthenes is highly parallelizable: just use one different prime per thread. After that, testing the remaining candidates is also a highly parallelizable task.

After all, the PoW has to be a parallelizable thing by nature, since all miners try to solve a block in parallel. So it's hard to make an algo that's more efficiently mined by a CPU than a GPU.

thanks! I did study a bit of quantum computing but the paper on entanglement in the primes is too much for me... I'll ask for help from a Physicist, and then a Physician (for the headache )

Hi! I found that the qt client sometimes get stuck (in RICs defense, bitcoin's wallet does the same once in a while), but after closing and restarting it then it continues. If it's totally stuck you can run with -debug and send me the log file (you may want to look at it and remove any sensitive info).

btw, let's test the superblocks: how many blocks do you see on testnet?

Security guards processing loan applications would suck at both jobs.
sha256 PoW is a waste when compared to what other types of PoW could achieve while still having great security.

Because power can be used for something else while still having network security.

I think the reason for it's decline was the lack of open source pool software for a long time.

Riecoin not only has open source pool software, but it also solves XPM's problem that pooled mining is not as efficient as solo mining.

don't worry, I read some people had problems compiling my fork so I'll review that and try to generate all the binaries.


This is the final implementation that I have for the superblocks:
Difficulty adjustments were performed every 288 blocks which should take 12 hs, so once every 14 adjustments (ie once a week) we will have a special interval. In these special intervals the difficulty will be adjusted a little bit down for all blocks except one which will be the superblock. The expected behavior is that 287 blocks will be shorter (136 seconds instead of 150), lending 14 seconds each to the superblock which will in total accumulate almost 70 minutes. This is the most elegant solution I could find since every interval will still have 288 blocks and be targeted to last 12hs.
So, if in a few days you get blocks with a reward of 45,33333333 instead of 50, then it is expected behavior. Don't complain: your block had less reward because it was easier to find, it's still fair. And if you get a block with 1389,33333333 RIC, then congratulations: you solved the superblock.

This is implemented, under testing, and working fine so far. Now what remains is to decide the block number for the hard fork (around 135000?), generating all the binaries and issuing alerts for everyone to upgrade.

Regards!
Gatra

hi!
Looking at the original miner, it looks like it accepts gaps of up to 12 between primes, and tuplets are not required to have minimal diameter.
So, we know that 6-tuples of minimal diameter have only one admissible form:
p+0 4 6 10 12 16
however since they are not enforcing the diameter to be minimal (16 in this case), then the following could be a valid block even though it's diameter is 24:
p+0 4 6 10 12 24
or lots of other combinations, with diameter up to 12*6 = 72

So, a sieve that allows only admissible 6-tuples of diameter 16 may not be the most efficient way to mine this... or it may be, idk, I just wanted to leave the question beause but I can't help thinking that the sieve may be filtering too much.

btw, have you abandoned RIC? me miss you

hi! I couldn't find the sources for the wallet. Is it me or they're not in the website?
https://github.com/VidereLicet only has sources for the miner.

The idea is that superblocks would be 70 minutes long, and it would be like 28 standard blocks fused together.
So their difficulty would be 28 times as hard as the difficulty at the moment, and their reward would be 28 times higher, ie 1400.
This way there is no incentive to mine only during superblocks, since the expected reward is always the same. With this implementation there are no timestamp issues or anything special during or around superblocks. We don't need a special difficulty adjustment or tracking of 2 different difficulties.


There is no consensus of current time on the network, so using time frames could lead to security problems.


I agree that this may work as a "one trick pony", but going for the other tricks (records for 7-tuples up to 15-tuples) requires more effort and implies an update to the pool software and all the miners. Superblocks are a simpler change that I'd like to try first, they would give us time to work on the other stuff.

Once per week would help show the power of RIC. A greater display of power could have greater impact, I'd like to stress out how much processing power is used in BTC and how RIC can divert it for more interesting things while still securing the network.

these have nice visualizations:
http://www.bigblueboo.com/prime/ you can find 6-tuples at 97, 19417, 43777
http://www.sievesofchaos.com/

A prime number wheel with 210 numbers on each concentric circle would show all sextuplets aligned starting from 97. This could be nice.

I'm getting errors compiling the miner... which version of boost do you use?

yes, that was the idea, one small interruption per week felt like a small price for the records

mmm.... I don't want to spread the computing power in 2 parallel threads... it would make breaking the records slower while at the same time make the blockchain less secure... I'd rather have all the "hashrate" focused on one task that serves both goals.