Integer Factorization as PoW in a Blockchain

[factorn]

Originally Posted by NatureHacker

Hello Factorn,


I have proposed about the exact same idea you have, I wonder if you saw this:


https://www.reddit.com/r/Monero/comments/grms1c/a_holy_grail_pow_for_monero_outlined_gnfs/



I also talked about it here on the forum under the name naturevault. The takeaway is if you read the comments that it is not a good method for a standard PoW. The person with the fastest supercomputer would win every block.



I have also done a lot of theorycrafting on what it would work in. I designed CollectBit, which would work but didn't get anyone interested in helping me code it.


https://web.archive.org/web/20210212011550/http://www.naturevault.org/wiki/pmwiki.php/NatureVault/DigitalCollectibleNetwork



Which basically uses a standard shared database.


But I believe I have found the holy grail application, a 3D blockchain I call an actionlattice. Basically everyone makes their own transaction and mines it by factoring a large number into two semiprimes just like you also came to the conclusion.


https://web.archive.org/web/20220929004452/https://www.naturevault.org/wiki/pmwiki.php/CryptoProjects/Actionlattice



(Just started with that one)



Anyhow there is nothing for me to gain in starting it myself. If coinbase wants to create it I will participate, I'm sure with millions of others. If you do want to pursue something like the actionlattice, I will help as much as I can.

I did take a look. The claim that a 745-bit number can be factored in 2 minutes is so out of touch with reality it is not worth spending much resources analyzing it; to the extent that it is, you are translating the computational power of Monero in units of work into integer factorization units of work....that's a rather crude analysis. Forget the actual factoring, setting up and syncing the Monero network to work together to factor this integer will take longer than that, let alone the actual GFNS 3-part algorithm.

The person with the fastest supercomputer would win every block.

By that logic, the same would be true of Bitcoin. Also, FACT0RN has been live for almost a year....all miners that come in have mined coins. I do get the impression that this particular claim is being made because you have not read the whitepaper....the PoW is not just factoring brilliant numbers.....you have to find them first, in a very particular way that makes it hard to cheat...on average a miner has to factor tens of thousands of numbers of 287-bits in length before finding a briliiant number base 2 of that size; currently, the difficulty level is 287-bits.

Incidentally, FACT0RN was just listed on the exchange Xeggex. So, mining is no longer the only way to get FACT0RN coins.

The deadpool feature to place bounties on integers to be factored will be launched on the first year anniversary on 4/20/2023; at least, that is the goal.

Contrary to some non-constructive criticism here the project is doing well. I am grateful for the constructive criticism that has been provided to me here, it helps a lot and I hope it continues as it makes the project better.

[factorn]

Originally Posted by Batalov

Do not create duplicate accounts. Log in as yourself and post your message about "Arm architectures or M1 architecture"

As you can probably tell...both these accounts were created around the same time over a year ago. I did not pay attention to the zero, sorry about that. The question, I understand, merits a separate thread nonetheless.

[VBCurtis]

It has been at least ten years since any development was done on GGNFS. I know of no effort nor interest in porting to ARM.
CADO compiles on ARM, according to our EdH. CADO is actively developed, ggnfs is not.

[jyb]

Originally Posted by VBCurtis

It has been at least ten years since any development was done on GGNFS. I know of no effort nor interest in porting to ARM.
CADO compiles on ARM, according to our EdH. CADO is actively developed, ggnfs is not.

That said, I have run the x86_64 ggnfs sievers on M1 processors in macOS, using Rosetta2. They were reasonably fast.

[factorn]

Since this will be used for mining any hardware emulation will place mac users on a severe disadvantage. Hardware native execution is strongly desired.

Are the folks who created that software, or maintained it, still around? Is there a substitute for it? Is there a substitute with similar performance? I mean ggnfs itself......CADO is not an answer to this.

[jyb]

Originally Posted by factorn

Since this will be used for mining any hardware emulation will place mac users on a severe disadvantage. Hardware native execution is strongly desired.

[...]

Really? How "severe"? Have you actually tried benchmarking this? Worth noting that Rosetta2 is not an emulator (despite a lot of incorrect reporting). It's a translator. The first time you run x86 code, it will be translated to arm and the latter will be used from that point forward. Will it be as fast as hand-rolled arm assembly? I would venture to say no. But before lamenting the severe disadvantages, you may want to actually verify that severity.

[henryzz]

What nobody has mentioned is that ggnfs probably compiles directly on ARM. At least the siever has a generic code path. Combined with msieve that is what someone sane would use anyway. From a brief look the only thing that I am not sure whether it would compile would be pol5.
That is ignoring that some of the ggnfs codebase probably hasn't been compiled in years. Might be interesting to see what is doable with modern amounts of memory.

[frmky]

They're not actually using ggnfs afaict. They are only using lasieve4 from that repository. And they should move to lasieve5.

I do plan to try making an M1 Arm-native binary of lasieve5 for NFS@Home one day, but it's very low priority since I'm not convinced it will be faster than the translated x86_64 code.

[kruoli]

With the latest CADO-NFS, on my Raspberry, I've got:
100% tests passed, 0 tests failed out of 508
So it's a valid way to go.

[factorn]

Originally Posted by frmky

They're not actually using ggnfs afaict. They are only using lasieve4 from that repository. And they should move to lasieve5.

I do plan to try making an M1 Arm-native binary of lasieve5 for NFS@Home one day, but it's very low priority since I'm not convinced it will be faster than the translated x86_64 code.

For those of us who are not as familiar, could you please elaborate on the difference between lasieve4 and lasieve5 ? Thank you.

[frmky]

See https://www.mersenneforum.org/showthread.php?t=17963.