Mod note: consecutive posts merged
Your Time here is based on shilling shitty hacked auto generated templates
Your postings have become offensive again, I'm placing you on "Ignore" because I'm not obliged to submit to your abuse.
You claim "It really would not be much more work for someone to fork my repository" but are apparently incapable of doing the work yourself, rendering the claim baseless.
You claim that "there might be a fatal flaw with the Mining" yet fail to respond to my request for details or even an indication which miner you are using.
I want my backups from the start to work on the Blockchain in 1000 years, not be obsolete in 3 years!
By making such impractical demands, you are revealing your lack of understanding. Try it with a Bitcoin wallet, see how you get on.
I don't know what misunderstandings you harbour about the role of templates in the functioning of Gapcoin that lead you to make bizarre and confused statements such as "Templates are to generate ideas, not to force merge ideas" but the ONLY purpose of that post was to drive home the point that the Gapcoin 0.16 codebase is almost exactly the same as the Bitcoin codebase except that i) Gapcoin uses prime gap search as a PoW function whereas Bitcoin uses SHA256 hashing, ii) Bitcoin has a fixed block reward of 50 BTC per block whereas Gapcoin's block reward varies according to a function designed by j0nn9 and iii) Gapcoin necessarily uses a difficulty modifier based on prime gap search designed by j0nn9 whereas Bitcoin uses a difficulty modifier based on changing hash target. Other than that, the codebases are identical.
I'll reiterate one last time. The 0.16 codebase retains
the versionbits code that enables
soft forks to happen. That code is
currently disabled in the Gapcoin 0.16 client.
The roadmap is:
1. After a majority of users have upgraded to the 0.16.3 client ...
2. At some widely-advertised point, the versionbits code is enabled to create a specific window of time
3. Users then download and use the new versionbits-enabled client, signalling their willingness to accept the change
4. When the window of time expires, assuming the majority of users are using the versionbits-enabled client, the change becomes permanent.
5. At some widely-advertised point, the block and transaction versions are bumped, excluding the old 0.9 clients from the network
6. A majority of users update to this new client.
7. At some widely-advertised point, an 0.20 client is released, no hard fork required as the necessary change in the network has already taken place.
Or ... y'all can just stick with the 0.9 client, I'm relaxed either way, given UsernameNumber7's confident claim: "It really would not be much more work for someone to fork my repository and build it up to Compile on Ubuntu and MX Linux. And have someone generate a new Windows .exe zip file based on the updated code." - all you need to do is i) hope that he knows what he's talking about and ii) find someone to do the work and iii) not care about OS X users, oh and iv) find an acceptable means of generating and distributing Linux static binary apps because the Linux binaries will have to have been linked against old versions of OpenSSL and Boost which won't be available on any contemporary Linux distro. But I'm sure that if you ask him, he'll have a plan for that.
Cheers
Graham
We really need to find someone able to rewrite the miner.
According to j0nn9, there's just one candidate,
"madmax" aka
eXtremal-ik7 - (I’m not entirely sure j0nn9's conflation of two identities is correct but whatever...) the latter identity is still working in the area of primes-as-PoW, active in pursuing
a Primecoin 0.16 wallet (Sunny King has pretty much abandoned Primecoin development) and operating the
http://coinsforall.io prime-mining pool.
Some history ...
i’ve managed to build a experimental gpu miner... The miner is a hybrid version of eXtremal’s fermat test and GapMiner’s sieve.
In the event, j0nn9 created an OpenCL version which he couldn't test on nVidia because he didn't have an nVidia card. It transpired that the OpenCL code wouldn't successfully execute on nVidia cards:
[2014-11-07 07:05:28] Server supports longpoll
[2014-11-07 07:05:28] Got new target: 13.0000000 @ 22.4320864
[2014-11-07 07:05:33] Found platform[0] name = NVIDIA CUDA
[2014-11-07 07:05:33] Found 3 device(s)
[2014-11-07 07:05:33] Compiling ...
[2014-11-07 07:05:33] Source: 205100 bytes
[2014-11-07 07:05:36] pps: -2147483648 / -2147483648 10g/h -2147483648 / -2147483648 15g/h -2147483648 / -2147483648
[2014-11-07 07:05:42] Compiled kernel binary size = 969615 bytes
[2014-11-07 07:05:42] Loaded kernel binary size = 969615 bytes
[2014-11-07 07:05:42] Using GPU 0 [GeForce GTX 750 Ti]: which has 5 CUs
[2014-11-07 07:05:42] clWaitForEvents error -9999!
[2014-11-07 07:05:42] OpenCL error: -5 at ./src/GPUFermat.cpp:406
[2014-11-07 07:05:42] OpenCL error: -5 at ./src/GPUFermat.cpp:397
[2014-11-07 07:05:42] OpenCL error: -5 at ./src/GPUFermat.cpp:397
And it still won't. I recently compiled the GapMiner code (adding some print statements) and checked its execution on my old XPS with GeForce GTX 1050 and CUDA 11.0 only to see the exact same error messages:
[2021-03-06 10:08:40] Found platform[0] name = NVIDIA CUDA
[2021-03-06 10:08:40] Found 1 device(s)
[2021-03-06 10:08:40] Loaded kernel binary size = 973509 bytes
[2021-03-06 10:08:40] Using GPU 0 [GeForce GTX 1050]: which has 5 CUs
[2021-03-06 10:08:40] Got new target: 22.2657854 @ 22.2657854
running 16384 fermat tests on the gpu
[2021-03-06 10:08:40] clWaitForEvents error -9999!
[2021-03-06 10:08:40] OpenCL error: -5 at ./src/GPUFermat.cpp:440
running 16384 fermat tests on the gpu
[2021-03-06 10:08:40] OpenCL error: -5 at ./src/GPUFermat.cpp:431
[2021-03-06 10:08:40] OpenCL error: -5 at ./src/GPUFermat.cpp:431
[2021-03-06 10:08:40] OpenCL error: -5 at ./src/GPUFermat.cpp:431
[2021-03-06 10:08:40] clWaitForEvents error -9999!
[2021-03-06 10:08:40] OpenCL error: -5 at ./src/GPUFermat.cpp:440
However, I can't proceed any further atm, there seems to be an unrelated general nVidia issue with my new XPS with GeForce GTX 1060 and CUDA 11.2:
[2021-03-06 10:08:04] OpenCL error: -1001 at ./src/GPUFermat.cpp:135
[2021-03-06 10:08:04] OpenCL error: -34 at ./src/GPUFermat.cpp:425
[2021-03-06 10:08:04] OpenCL error: -34 at ./src/GPUFermat.cpp:425
[2021-03-06 10:08:04] OpenCL error: -34 at ./src/GPUFermat.cpp:425
[2021-03-06 10:08:04] Got new target: 22.2657854 @ 22.2657854
running 16384 fermat tests on the gpu
[2021-03-06 10:08:04] OpenCL error: -36 at ./src/GPUFermat.cpp:431
[2021-03-06 10:08:04] OpenCL error: -36 at ./src/GPUFermat.cpp:431
[2021-03-06 10:08:04] OpenCL error: -36 at ./src/GPUFermat.cpp:431
./runminergpu: line 18: 456200 Segmentation fault (core dumped)
Anyway, here's something to consider ...
eXtremal-ik7 is also the source of the current XPM miner - and Datacoin shares that PoW code, so the XPM miner works with Datacoin.
On the offchance, I downloaded
the linux binary xpmclient-cuda-10.5-beta2-linux for eXtremal-ik7's
xpmclient from the coinsforall.io pool, pointed it at Datacoin and
it worked! (on my old XPS, that is - it blows up on the new XPS, indicative of a machine issue rather than an issue with the code).
So, we know that a CUDA-based implementation of prime mining works even if the OpenCL doesn't. j0nn9 created an OpenCL version of three GPU-specific source code files,
benchmarks.cl,
fermat.cl and
procs.cl. What we'd want (to avoid nVidia's apparently broken support for OpenCL) is three CUDA files to replace the OpenCL ones - like those available in
eXtremal-ik7's xpmclient repos:
benchmarks.cu,
fermat.cu and
procs.cu. At first glance, it looks like that might be a good route forward.
But that's just a starting point. The GapMiner implementation is
ancient and relies upon a long-removed RPC API call
getwork (which I had to reimplement for the Gapcoin 0.16.3 client) replaced entirely by the
getblocktemplate RPC API call. The difference is that with
getwork, it is the client which creates the blocks to be mined, with
getblocktemplate, the task of creating the blocks now rests with the miner, the client merely transmits the acceptable parameters. This change was part of the move to versionbits (soft-forks) which allows miners to signal their change preferences using the versionbits bit-signalling - not something that's possible when the client just dumps a monolithic block to be fed to the PoW calculation.
So it's
long past the due date for a re-write of the GapMiner interface with the client. eXtremal-ik7's xpmminer is a good starting point for an adaptation to Gapcoin, it contains the block-assembly code that's needed to create blocks from the data returned by a
getblocktemplate call and is a complete standalone miner implementation.
Take a look at the
build.sh script (note that although not specified,
the CLRX code is available from Github)
If I didn't have this CUDA/OpenCL issue on my current XPS, it's where
I'd be starting if I were interested in creating a new CPU/GPU-capable GapMiner.
If one day there is no longer a functional miner, there will be no more problem with the wallet.
Nor anything else.
And there you have neatly encapsulated my objective in restoring the in-wallet miner, as long as that remains operational, the chain can continue.
Cheers
Graham