I downloaded the wallet, but unable to mine with it.
The wallet is closing, Ryzen 1600
Wallet not full synchronized yet.
What you peoples using to mine.
I have be able to mine with the GPU and the pool.
Can't mine if wallet not synced. You omitted to say what OS and GPU card you're using. eXtremal's xpmminer works with dtc.graymines.net https://bitcointalk.org/index.php?topic=831708.msg57002698#msg57002698Cheers Graham |
|
|
|
Upgrade of Gapcoin Core client from 0.9 to 0.16 completed.FWIW: Are we approaching a re-announcement ?
Dunno. Not completely happy with the getwork implementation. Turns out that the demands of the standalone GapMiner cause the client to run out of rpcworkqueue capacity, doubling it to 64 seems to work but I don't know whether that's practical for pool mining. I fixed the issue that caused the client to create excessive demand on the RPC work queue and I have now completed the process of upgrading the Gapcoin client from 0.9 to 0.16. There are two releases, one for a “minimalist” version and one for an “extended” version (with extended GUI and RPC-API functionality): https://github.com/gapcoin-project/gapcoin-core/releasesCross-compiled binaries are available, along with the scripts (one for each version) used to generate the binaries (Ubuntu-0.18 VM/host recommended) and a zipped bootstrap.dat file (be prepared to wait a day-and-a-half to a couple of days to sync from 0 if using -loadblock=bootstrap.dat). Due to changes in the structure of the wallet code, the 0.16.3 client cannot load a wallet.dat saved by an 0.9 client. You can't simply copy the wallet file over, you have to use the dumpwallet command in the command-line/console in the 0.9 client to create a text dump of the wallet. Then, in the 0.16.3 client, use the importwallet command in the command-line/console to import the dumped wallet. Step-by-step procedure: 0.9 clientdumpwallet "/tmp/dumped-gapcoin-wallet.txt"
importwallet "/tmp/dumped-gapcoin-wallet.txt" true
(and wait for a few hours while the client scans the entire blockchain's tx history, rebuilding your UTXO set). Yes. This is my personal development area, following the convention for contributions: “The codebase is maintained using the "contributor workflow" where everyone without exception contributes patch proposals using "pull requests".” Kinda. Just the same as everyone else operating in a decentralized space, I’m obliged to take my cue from the community and its collective response to technical contributions. As far as the 0.9 client is concerned, I won’t be spending any further time/effort in that direction, either in terms of development or support. The presence of 0.9 clients in the Gapcoin network does act to constrain some of the functionality of the 0.16.3 client. A couple of examples: 1. Users will note that in the provided example.gapcoin.conf, the configuration peerbloomfilters is set to 0, effectively disabling the bloom filter optimisation used in network connections. The reason that this service has been disabled in the config for the 0.16 clients is that 0.9 clients are unable to handle bloom filiter messages and register an error in the log. 2. There is no means of preventing 0.16 clients from creating transactions using segwit addresses which, although not actually causing an error in the 0.9 client, causes it to treat such transactions as “nonstandard” and basically, misrepresent them. Here's an example from testnet, txid 94cfec5d7da0853f2ba04a3a23957171027a2875a5f43b8cc9bf3cf19d4a5affAs reported by the 0.16 client: "vout": [
{
"value": 100.00000000,
"n": 0,
"scriptPubKey": {
"asm": "0 8b27793e0c60c3941cbb411d33d7976f2e2451f5",
"hex": "00148b27793e0c60c3941cbb411d33d7976f2e2451f5",
"reqSigs": 1,
"type": "witness_v0_keyhash",
"addresses": [
"gpt1q3vnhj0svvrpeg89mgywn84uhduhzg504t95ulk"
]
}
}
As reported by the 0.9 client: "vout" : [
{
"value" : 100.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "0 8b27793e0c60c3941cbb411d33d7976f2e2451f5",
"hex" : "00148b27793e0c60c3941cbb411d33d7976f2e2451f5",
"type" : "nonstandard"
}
},
At some future time, when a significant majority portion of the Gapcoin network is hosted by 0.16 clients, we can increment the version number and set appropriate values in chainparams.ccp to enable the community to signal its acceptance of a phased transition to a full segwit-enabled network. At that point we can discuss the issue of incrementing the minimum version number in order to exclude relatively-incapable 0.9 clients from the network. 4. The v0.16.3 source / binary releases would generally now be advisable over running v0.9.2-3 for anyone starting afresh with Gapcoin / Core / Solo / Pool Mining ?
The 0.16.3 client is the only one that I'm prepared to provide any support for in terms of responding to reported issues and/or providing limited help. Cheers Graham
|
|
|
|
They have a placeholder for us so maybe they will be a little easier on us when they see that there is activity here.
The community is overwhelmingly comprised of pseudonymous individuals but CMC won’t respond without an email address - I can't resolve that contradiction without giving them my email address, which I'm not prepared to do. Cheers Graham |
|
|
|
Need to fill in a rquest form.
Need to assess whether it's worth the effort. Stumbling blocks in terms of assumptions of centralized organisation that are inappropriate to a decentralized cryptocurrency: (SECTION B) Guidelines for 'Tracked Listings'
Note that these are just guidelines and meeting them does not guarantee a listing.
(1) Cryptoassets
For a cryptoasset to be considered for a tracked listing, it should meet the following guidelines:
...
Must be traded publicly, and actively traded on at least one (1) exchange (with material volume) that has tracked listing status on CoinMarketCap.
Provide a representative from the project with whom we can establish open lines of communication for any clarifications.
(SECTION C) Evaluation Framework
Beyond the guidelines, we perform our evaluation holistically and pay close attention to a multitude of factors (both quantitative and qualitative). Getting listed is therefore not simply a matter of ticking off a checklist or hitting predefined thresholds, as we benchmark submissions against others in the cohort. These factors include but are not limited to:
Community Interest & Engagement
A project’s usefulness is largely a function of adoption and its ability to foster meaningful interactions with its community and user base.
Team
The personnel, investors, and advisors are integral to the success of any given project, especially if there are transferable skills/experience/networks that can be leveraged. The conduct of the team (e.g. transparency and professionalism) will also factor into our assessment.
Circulating Supply is verified by our team through communication with the project’s team. We ask for details including but not limited to the initial distribution, private allocations, locked addresses, team-controlled addresses, and addresses containing portions of the supply allocated for future use.
We define Total Supply as the total amount of coins in existence right now, minus any coins that have been verifiably burned.
Cheers Graham |
|
|
|
FWIW: Are we approaching a re-announcement ?
Dunno. Not completely happy with the getwork implementation. Turns out that the demands of the standalone GapMiner cause the client to run out of rpcworkqueue capacity, doubling it to 64 seems to work but I don't know whether that's practical for pool mining. In the old client, the mining key is bound on RPC startup but in the new client, its ability to run without a wallet at all made a nonsense of that RPC startup assignment and it's long been removed. So in the 0.16.3 Gapcoin client, the getwork code has to get a miningkey each time it's called, which isn't satisfactory so I want to find somewhere earlier in the process to shoehorn in the binding of the mining key if I can. The other solution would be to rewrite the GapMiner code to use the contemporary (and supported) getblocktemplate RPC call instead of the obsolete (and removed from the upstream cloneparent) getwork RPC call. I have re-implemented the getwork call but it's not a particularly good fit for the way that the 0.16.3 codebase is designed and the extra demand on rpcworkqueue is a consequence of that. For the last couple of days, I've been confirming that a dumpbootstrap RPC call that I've added actually creates a bootstrap.dat that the client can sync from (it does, albeit the client takes a day and a night to sync from a bootstrap). Cheers, Graham |
|
|
|
The list is probably just growing since trnicely.net is no longer maintained. Who did this !? ..Probably no one. No-one who cares to check the results. The list is profoundly out of date and incorrectly credits Gapcoin with the following records, since surpassed by others:
5144, 5158, 5164, 5254, 5278, 5284, 5314, 5334, 5342, 5370, 5380, 5404, 5410,
5420, 5428, 5486, 5502, 5512, 5532, 5556, 5570, 5584, 5616, 5648, 5658, 5682,
5706, 5762, 5808, 5814, 5826, 5880, 5934, 5944, 5990, 6008, 6018, 6028, 6044,
6050, 6076, 6098, 6134, 6144, 6160, 6178, 6190, 6196, 6224, 6226, 6240, 6264,
6278, 6280, 6286, 6310, 6312, 6326, 6330, 6342, 6346, 6348, 6370, 6372, 6378,
6392, 6398, 6400, 6408, 6416, 6418, 6424, 6426, 6428, 6438, 6440, 6450, 6458,
6468, 6472, 6474, 6502, 6510, 6522, 6538, 6552, 6560, 6564, 6582, 6600, 6604,
6608, 6640, 6658, 6666, 6674, 6690, 6712, 6756, 6804, 6856, 6878, 6904, 6908,
6934, 6940, 7006, 7104, 7124, 7158, 7194, 7200, 7276, 7372, 7380, 7390, 7406,
7486, 7538, 7566, 7640, 7648, 7884, 7894, 7918, 7928, 7940, 8066, 8366, 9694,
9860, 10048, 10124, 10696, 13126, 13172, 13196, 13244, 13372, 13376, 13416,
13578, 13612, 13630, 13684, 13686, 13724, 13772, 13918, 13922, 14114, 14124,
14192, 14280, 14294, 14344, 14354, 14454, 14478, 14492, 14498, 14540, 14546,
14602, 14626, 14664, 14672, 14710, 14766, 14802, 14904, 14934, 14976, 15046,
15092, 15124, 15246, 15252, 15270, 15290, 15308, 15374, 15618, 15700, 15852,
20498, 20586, 20742, 21032, 21166, 21202, 21252, 21586, 21654, 21800, 21898,
21990, 22022, 22050, 22140, 22206, 22260, 22848, 22856, 22878, 23042, 23490,
23526, 23824, 24462, 25410, 25470
To ascertain the current status for yourself, import the current prime gaps list SQL insert file into SQLiteBrowser with “File->Import->Database from SQL file”  and in the “Execute SQL” tab (shown above), enter the following SQL query: SELECT * FROM gaps WHERE discoverer == 'Gapcoin' ORDER BY gapsize; and then, to see this year's changes: SELECT * FROM gaps WHERE discoverer == 'Gapcoin' AND year > 2020 ORDER BY merit DESC; Cheers Graham |
|
|
|
It's obvious from the charts
I managed to get all-time graphs for difficulty  and hashrate  Cheers Graham |
|
|
|
It would be good to have confirmed prime gaps.
I haven't encountered any disputes about the accepted standards of inclusion. The original creator and maintainer of the prime gap list, the late Dr T.R.Nicely, published the source code of the cglp program that he created and used to verify the inclusion of a first known occurrence prime gap to the prime gap list: “I have made available for download the zipfile cglp4.zip, featuring a DOS/Wintel executable which will check gap listings for validity, using probabilistic primality tests of extremely high reliability. Included are sample input and output files, source code (GNU C with GMP), and support routines. I strongly recommend the use of this code to check your listings prior to submission.” After Dr. Nicely's death, I worked with the intellectual inheritors of his legacy, the Mersenne Forum's Prime Gap Search group to preserve the cglp source code and the curation of the prime gap list so that the probity of the list was maintained and I used a Linux compilation of cglp to check any subsequently-submitted Gapcoin records. Subsequent to that, Seth Troisi of the PGS group has created an online checker (implemented in Go, I infer from the URL) which “we” (and by that, I mean me) and the PGS are now using to curate the prime gap list. Gapcoin has a very limited range to work with and other groups have improved their algos. The pow is limiting what range and how it's done., Frey did a good work to create this coin but it needs some improvements.
I'm not sure how much leeway there is for improvement of the Proof-of-Work function without compromising the cryptocurrency aspects of Gapcoin. j0nn9 was hoping that other people might have some ideas on how to improve the miner, if you have some specific improvements in mind, please share them. Mersenne group finds new nice gaps in a day and we do the same in a month. I changed to search in p88 for a record and so far I just have found one 25+ merit gap. To find a 30+ gap is hard.
That's primarily because the Gapcoin community has shrunk - difficulty approximates merit and difficulty is a dependent variable of hash rate - within limits, the lower the hash rate, the lower the difficulty, the lower the merit of gaps accepted as valid Proof-of-Work solutions. It's obvious from the charts; interest, hash rate and difficulty spiked a couple of months after launch ( diff at 25) and then steadily declined during the first half of 2015 until around six months after the launch when it stabilized at a much¹ lower level ( diff=20/21) - about the same time of the developer's last substantive post to the thread. It's worth not losing sight of the fact that the world record merit held by Gapcoin is for a block mined with a modest shift of 32. For all the extensive range of prime digit lengths covered by prime gap searchers, it transpires that intensive examination of a narrow range of prime digit lengths has revealed a prime gap of world record merit. ¹ " much" because Gapcoin difficulty increases/decreases logarithmically. Cheers Graham |
|
|
|
Boom ! My biggest, and the biggest Gapcoin's Gap.  (length, not merit) 28168,C??,31.767181,Gapcoin,04-05-2021,386,1228769885602... The previous one was a gap of 27666 @shift 896. Agreed, well done Wizz. That Craig Loizides is making things more difficult - https://www.mersenneforum.org/showpost.php?p=576044&postcount=239Craig also improved the record for 15122, so there are now only two gaps under 25,000 with merit < 25.
For those that aren't neck-deep in it, a 386-digit prime means Wizz used a shift of 1024 to get that seriously-improved merit. The existing-soon-to-be-previous holder of that record was Dana Jacobsen and the gap was between primes of 502 digits in length - which is why Wizz' merit is higher, it's the same gap size but it's larger in relation to the digit length of the surrounding primes. INSERT INTO gaps VALUES(28168,0,'C','?','C','Jacobsen',2014,24.3700,502,'637*1201#/18390 - 23308');One slight thing that nags at me is that we're always submitting 'P' (probable primes) and it would be nice to upgrade them to 'C' (confirmed primes). I have asked about this and I'll probably get a response in due course. I used Dana Jacobsen's eccp-dj to do the checking, as well as PRIMO (just to find out what prime certificates look like). As for the Mersenne Forum's Prime Gap Search group, they seem to be heading into a different space entirely: “I've got two 3M+ gaps in the offing.” - those have to be some seriously large surrounding primes. Cheers Graham |
|
|
|
Thanks gjhiggins, that's awesome! I tried it out and it seems to have worked. I guess "sec" are the private keys (in WIF format probably), right? (So the list printed by this program should definitively not be shared here  ). We could simply fork this version into the slimcoin-project repo and change the datadir and addresstype parameters. However, one question remains: Is it safe to use also for the option? This one seems to write on the wallet file, so it should be used carefully (only with a backup of the wallet). ?? That option isn't supported in the committed version that I used: Usage: pywallet.py [options]
Options:
--version show program's version number and exit
-h, --help show this help message and exit
--dumpwallet dump wallet in json format
--importprivkey=KEY import private key from vanitygen
--datadir=DATADIR wallet directory (defaults to bitcoin default)
--testnet use testnet subdirectory and address type
--password=PASSWORD password for the encrypted wallet
The importprivkey succeeded for me. I was focused on the original task, dumping privkeys from the wallet.db file, didn't explore further. Cheers Graham |
|
|
|
you should be able to get a JSON dump of the wallet keys with:
python2 pywallet.py --datadir=`pwd`/datadir --dumpwallet
Wow! So we basically can use it right away? Worked for me. Cheers Graham |
|
|
|
There's another one which is older and described as the "original". If the update to modern code delays, this could be a better option: https://github.com/joric/pywalletWe'd need a python dev here, right? Not really. Use this version from the repos. Save the page as pywallet.py, change addrtype = 0 to addrtype = 63, create a subdirectory datadir, copy your wallet.dat into it and you should be able to get a JSON dump of the wallet keys with: python2 pywallet.py --datadir=`pwd`/datadir --dumpwallet(note, Python 2 required). Cheers Graham |
|
|
|
client v6 stucks on win&lin with my old wallet.dat, with size of this over 4mb  Yes, it's an old client and is beginning to struggle when indexing the blockchain and is unresponsive while that is happening. Try leaving it for a day, see if it manages to settle down. dumping and importing all privkeys in fresh wallet show that i have only 6k burning coins instead of 20k really
Yes, I've experienced temporary misreporting of the burned coins data, I've had to restart the client a couple of times to get accurate reporting in the GUI. Try the console command getburndata, see if that shows the correct burned coins data. Cheers Graham |
|
|
|
It transpires that j0nn9 left us “an exercise for the reader” in the GapMiner rev5.1 code, just here: https://github.com/gapcoin/GapMiner/blob/2f66e908e52dab503de77835f31ac1603b1c23fc/src/HybridSieve.cpp#L398sieve_t min_len = log_str(mpz_get_d(mpz_start)) * d_difficulty; should read sieve_t min_len = log(mpz_get_d(mpz_start)) * d_difficulty; The difference was causing GPU builds of the GapMiner rev 5.1 to segfault (on both AMD and nVidia). I fixed that (along with some other compilation-blockers) and re-worked the Makefile so that it can be used to create either CPU or GPU miners (AMD and nVidia) without having to be edited to do so. I've cloned gapcoin-project's GapMiner repos here https://github.com/gjhiggins/GapMiner, check out the README for details of how to compile gapminer and gpugapminer on Linux. When I'm satisfied that it works for people, I'll raise a PR on the gapcoin-project GapMiner repos and update that. Thanks to benxy031 for providing that nVidia-compatible fermat.cl code, I've included it in the gpu subdirectory as fermatnv.cl and adjusted the miner code to load whichever OpenCL source file is compatible with the detected platform. Cheers Graham |
|
|
|
If nobody are developing it and nobody are paying for the explorer then it will be gone.
It's got some life in it yet. Wizz has generously funded the chainz block explorer until 2022-07-09. I'll continue making technical contributions where I consider it necessary to maintain the codebase. Freiexchange has been seeing some recent interest. Cheers Graham |
|
|
|
|
Show Posts
