Topic: [ANN][GAP] Gapcoin - Prime Gap Search - New Math Algo - CPU / GPU - Zero Premine - page 10. (Read 287628 times)

After reading this post it reaffirms what I have thought for a long time.  It is worth the read and it is a big decision and possibly FATAL for a coin project to follow Bitcoin Core Code.

https://bitcointalksearch.org/topic/m.56515082


Gapcoin is at this juncture. 

I am the only one who has updated the Original Gapcoin Code from the ground.  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. 

I really see no future in making complex moves for small Bitcoin Forks.

If it's science than we should not care to imitate Bitcoin.  As Bitcoin is only about greedy bankers now.  It has nothing to do with overthrowing injustice and Cannabis Prohibition like what Dread Pirate Roberts achieved using Bitcoin. 

I think thats my final position on advancing along Higgins 16.3 than HardFork to 20.  Opinions don't matter though, if enough assholes get together and conspire they will kill anything off.

Mod note: consecutive posts merged (inserted hr when needed for clarity)

---

Linux error comes about again if starting the wallet again.  

Once you use the command ./gapcoin-qt -choosedatadir

It is only a one time pad use if you use 2 wallets.  



You have to use ./gapcoin-qt -choosedatadir and also for 16.3 ./gapcoin-qt -choosedatadir EVERY time to start.


Have a Blockchain before ever using Gapcoin 16.3.  And keep the Blockchain backup in 2 locations.  


Because I ran into the issue of starting the 16.3 Wallet and it pulled Automatically into the .gapcoinVersion9 Directory even though I did not set the directory there.  The 16.3 Wallet will pull it from when you set Version 9 Gapcoin Wallet.

To avoid this and prevent it from re-indexing the blockchain.  Set the command line option -choosedatadir everytime until Wallet transition is complete.


If the mistake is made, delete the blockchain in the Version 9 Gapcoin Directory and copy paste the Backup Blockchain.  The regular 16.3 Wallet Directory does not seem to care about re-indexing so it's not an issue if making a mistake there.


Realistically, I am probably talking to myself as probably not many Linux users here other than BitcoinFX and Higgins!



Gapcoin is stronger than it has ever been.  The Main problem is newbies don't know how to use .conf files and have to rely on the built in wallet nodes which expired in Jonn9 Wallet.  

BitcoinFX will promote it more or less, sooner or later!


FreeBitcoins.com and Freiexchange.com list GAP

Unnamed exchange also, but I honestly can't fathom anyone using their UI.  Freiexchange UI is bad too, but it is the Price linked to CoinPaprika and CoinGecko.

FreeBitcoins.com has by far the best Exchange and UI.  But it is not as popular and does not have the link to the indexers!

---

Higgins there might be a fatal flaw with the Mining!

In a short period of time it keeps generating the same blocks, but generating new tokens.  

It must still be generating a different PrimeGap inside the block hash even though it's mining the same block?

Not sure if I will continue mining because it is pretty bad after letting them run for a couple days.  Lots of Orphans and LOTS of repeat blocks.

I doubt there is a way to trouble shoot a generated template though!




The enemies have it all calculated out to prevent any competitor to Bitcoin.  Using their Templates is a good idea, and I think your a good programmer, but I think the people we are facing are far more calculating than any of us combined.  

If any project is to succeed I think it will have to be raised up from the ground up.  Which is the calculation they know will not happen.  At least not a fork of Bitcoin anyway.  Eth is different, and designed to spam Bitcointalk with Daps to coordinate the assault against Bitcoin Forks.  

This coin seems very dead but it's still getting support? Are there any active pools or exchanges?

Thanks Higgins!!!!!!!!


This will go very well I think now.



The Linux Instructions is even easier to run than the Windows instructions you posted.


     create .gapcoinversion9 folder

     cd gapcoin/src/qt

    ./gapcoin-qt -choosedatadir



That command at runtime will show the original popup Window and will let you choose the directory using the GUI. 

Insert a copy of the Blockchain inside the folder.

Create gapcoin.conf and use the commands along with your addnodes

port=60000
rpcport=60001


Successfully running 16.3 and 9.3 Gapcoin at the same time.


This will make Wallet change over a lot easier!

Okay, thanks.

I often work with multiple versions of a client. On Linux it’s fairly natural to run the client from the command line, specifying a different -datadir to keep versions separate. It's not quite so natural on a GUI-prominent OS like Windows but once you know how to do it, it’s quite easy to run both 0.9 and 0.16 clients at the same time and have them connected to each other.

Firstly you need to arrange for two folders in C:\Users\*****\AppData\Roaming, one for each version - you can create them as Gapcoin-0.9 and Gapcoin or Gapcoin-0.16 and Gapcoin, or even Gapcoin-0.9 and Gapcoin-0.16 depending on your preference.

Then, edit the gapcoin.conf file in each folder and assign a different port and rpcport to each. If you like, you can have one on the standard port/rpcport but they must be different.

I usually use:

and


Then, create a shortcut for each client on the desktop (e.g. one called Gapcoin-0.9 and one called Gapcoin-0.16) and edit the properties of each.

Assuming that you have named your “datadir” folders C:\Users\*****\AppData\Roaming\Gapcoin-0.9 and C:\Users\*****\AppData\Roaming\Gapcoin-0.16, edit the command line arguments in the shortcut Properties “Target” field to add: "-datadir=C:\Users\*****\AppData\Roaming\Gapcoin-0.9" to the shortcut to the 0.9 client and "-datadir=C:\Users\*****\AppData\Roaming\Gapcoin-0.16" to the shortcut to the 0.16 client.


 
Then, you can click-start each shortcut and have both 0.9 and 0.16 clients running together, each using their own folder for the datadir.

You can freely dump and import privkeys in either client, have the same keys in both wallets or send coins via tx from one to the other.

Cheers

Graham

Thanks for the reply, I was referring to running 2 separate instances of the Gapcoin wallet, duplicating the files and blockchain, deleting the 'wallet.dat' and generating a second wallet. I could then run that wallet with a modified code pointing to the copied data directory ie.(C:\Users\*****\Gapcoin Reserve\) transfering any funds over to the reserve which isnt mining.

Mod note: consecutive posts merged

---

I understand Higgins thanks......

The point I was making is DON'T try to Mine with 16.3 Wallet BEFORE using the Version 9 Dumpwallet

I don't know if 16.3 wallet can be run normal and shut down, and then Version 9 wallet being able to be loaded again.




Use Dumpwallet and Higgins instructions BEFORE running 16.3 wallet.





But maybe it's just a Don't Mine with 16.3 wallet until transfer coins is complete.

But I can't go back to check that for sure at the moment.  



If you Trust FreeBitcoins.com they offer a reserve wallet address, but if they were hacked not a guarantee of getting anything. 

Not sure what you are referring to but I will try to answer.

 

You should find a encryption software like Tru-Crypt and Encrypt your Wallet.dat after Gapcoin is shutdown, using a random password generator program like Bitwarden.  Than you put your encrypted wallet.dat file into a New Folder.  Compress the New Folder which should generate a Tar.gz Zip file.  Encrypt the New Folder.Tar.gz using a program like Tru-Crypt. 

Now you can back up your Gapcoin Wallet in the Cloud.  If it's super important reverse the process to make sure it will De-Crypt and everything was encrypted properly.   



I think the important thing now is to Backup and Encrypt a 16.3 Gapcoin wallet.dat.   

Would it be recommended to setup a 'reserve' wallet just in case anything goes wrong and transfer any tokens over accordingly?

Not possible. It's not a case of desirability, it's a case of unpredictable consequences of such a radical change to the wallet architecture.


I don't think I can be much clearer than: dump a text file of the wallet using dumpwallet in the 0.9 client. Import the dumped wallet text file into the 0.16 client by using importwallet.

Perhaps I've been too accommodating and have inadvertently raised expectations to a level that doesn't match reality in terms of the degree of change from 0.9 to 0.16.

This isn't an incremental upgrade, it's a major change across five years of intensive upstream activity on the cloneparent.

Of course the clients will need to rebuild the index and of course the 0.16 client won't load 0.9 wallets --- it's exactly the same as with Bitcoin - except that with Bitcoin, 0.9 clients are not able to connect to the post-0.10 network.

An alternative approach for Gapcoin would be to hard-fork to the 0.16.3 client. This would avoid the all difficulties of a mixed 0.9/0.16 network, allow the removal of yet more potentially problematic non-core code and a hard fork might make the degree of difference rather more salient to users.

A more radical but just as effective approach would be to hard-fork to the 0.21 client, straight into a segwit-enabled chain. Transitioning to segwit will have to happen sooner or later and staying on the 0.16 client for the next five years just isn't an option. Unlike the 0.21 client, the 0.16 client still retains the versionbits code that allows for a smooth transition to segwit --- but if dealing with the change between 0.9 and 0.16 is proving problematic, perhaps a hard-fork to an 0.21 segwit-enabled chain would be a cleaner and perhaps, for this community, the only viable solution.

Cheers

Graham

Node List for /Satoshi:0.9.2/
https://chainz.cryptoid.info/gap/#!network


Download blockchain to fast synchronization - https://gapcoin.network/downloads/Gapcoin_blockchain.zip

create the gapcoin.conf file in the folder where the blockchain is stored Gapcoin.
 Windows - %APPDATA%\Gapcoin\ - C:\Users\username\AppData\Roaming\Gapcoin\gapcoin.conf
 Linux - $HOME/.gapcoin/ - /home/username/.gapcoin/gapcoin.conf

Hey guys, im having problems setting up the node to start mining GAP, There are no connections in my wallet and also I dont understand how to add nodes, should I create the gapcoin.conf file myself and format it similar to other qt based miners? Any help would be great obviously theres 6 years of blockchain to sync aswell, surely someone has a link to a recent backup that saves me 24hours of tea bagging my PC unnecessarily.

Thanks in advance.

Kind Regards
Kameleonic

Is it possible to remove the HD Wallet from the 16.3 Wallet?  Is it that desirable to have?  


I had to use a blockchain backup to restore the 16.3 wallet after trying to start Version 9 Gapcoin to transfer coins into new wallet.

Didn't wait for it 1 day to re-index the blockchain which is what it wanted to do after mining with 16.3 for 1 day.  Going back to Version 9 even with a Version 9 wallet makes it want to Re-Index the entire blockchain.  


Too much trouble probably.  


Keep a Pre-16.3 Blockchain Backup close by to restore Version 9 wallet.  I have not got around to it, but I am sure it will work, but it does not work with saving the blockchain after 16.3 wallet has mined to go backwards and restart Version 9 wallet.  It will but Re-Indexing is not ok for time.  

With a Pre-16.3 Blockchain backup Version 9 Wallets should just need to Re-Scan which takes only a few hours instead of over a day and it restarts from the start if you shut it down while Re-Indexing.

Hard to explain, but I am not looking back.  

A couple years ago while using a Israeli VPN I had Mossad steal a transaction from me for around 500,000 GAP.  Not sure if they got the private keys or if they are just Burned Coins.  As I was using Tor over the VPN, but it's possible they compromised Tor as well to steal the private keys.  The transaction was sent using Israeli VPN server over Tor.  Hopefully it's just Burned Coins anyway.  

Not a 'bad' as such and absolutely no need to apologise (you are doing a sterling job acting as the mainstay of this community project) - it's just that I'm trying to be acutely aware of the general group perception - whilst the chain consensus is fixed by proven code, the community consensus is highly sensitive to changes in sentiment.

If you’ll (all) bear with me, I will take you on a leisurely trip which I believe is necessary if you want to understand the full significance of the destination - which is: “Gapcoin 0.16.3 is milled from a Minkiz Foundry template, so that’s the version that can and should be released as the one endorsed by the community.” There’s some groundwork I need to lay in order for me to feel comfortable that people actually understand what that means ....

I'll freely confess to not viewing myself as a C++ developer - at least not according to my standards. I'm a cognitive psychologist by discipline and a cognitive scientist by profession, over my 30-year career in tech, I have acquired some familarity with the tools of computational modelling - in my time, I've coded in COBOL, Z80 assembler, BASIC, Pascal, LISP, POP11, Prolog, Smalltalk, Python and lately C++, not to mention acquiring familarity with the markup languages such as HTML, XSL, XSL, RDF, etc. More importantly, along the way, I've acquired some limited degree of skill in software engineering generally which gives me quite a good grounding for curating altcoin codebases in the (permanent) absence of the original developer.

The basic codebase of the current Gapcoin 0.16 client is derived from a piece of personal (and private) work that I've been pursuing over the last five years. Back in 2014, there was slew of trivial altcoin clones of Bitcoin, differing little from the cloneparent other than in the choice of hash algorithm and I created a piece of online “art” (Minkiz’s Foundry) which (I felt) made some wry commentary on the trend. It’s still up there, unchanged from 2014.

The (allegedly wry) commentary lies in the tongue-in-cheek ebullient description of the (total of 24) hashing algorithms, here’s a pageshot of the first half-dozen, the entirety are still available to view.






Perhaps understandably, the contents of the page linked to from the “Try/Buy” button confused some people, although it might look like a shitcoin generator, it’s non-functioning.




Minkiz Foundry is an extension of the idea behind my original investigation - can altcoin clones be successfully characterised by their differences from the Bitcoin cloneparent? This was (for me, at least) a natural outgrowth of the altcoin classification work I had done in DOACC (Description of A CryptoCurrency), a semantic web project¹

The DOACC ontology provides a means of describing the metadata of an altcoin.

Between 2014 and 2017 I spent quite some time collecting and collating the metadata of around 3500 altcoins of the time, here's an example (rendered in N3):


The description is cross-referential - the PoW scheme for Devcoin is D0441786b-85a1-45a6-a50d-1a9b80ec7b94 which resolves to:
(I use RDF for its sheer representational power, it's appropriate for this task).


And, with the vast majority of altcoins having a Github source to peruse programmatically, I was able to build tables showing the various features of altcoins - here it shows the cloneparent, its version, the (supposed to be unique to the coin²) “magic bytes” and the feature set:





However, behind the scenes, for my private amusement/edification and inaccessible to the public, the actual joke is that Minkiz Foundry does actually work, it successfully mills full-functioning altcoin clones i.e. includes the creation of the genesis block and the in-wallet miner is capable of generating mainnet blocks.

I've been tracking the Bitcoin cloneparent upgrades and Minkiz Foundry is now milling clones of Bitcoin 0.20. Over time, I've refined the set of choices of hash algorithm, replacing some outdated or less-interesting variants with implementations of more powerful or more interesting modern hash algos --- a handful of NIST first-round candidates that remain secure but never made it the NIST 2nd round and so never had an ASIC implementation (“In the final round of the competition, there were three complete ASIC implementations of the 256-bit versions of all five finalists”), MD6 (withdrawn by Ron Rivest from the NIST SHA-3 competition but later proven robust against differential cryptanalysis), Rainforest, City (Google’s own) and some algos approved by other-nation NIST equivalents such as the Chinese SM3 and the Russian GOST-Streebog ... (I hope you’ll forgive me for including the full pageshot, I just happened to have one on imgur):





By way of illustration, here's a screenshot of a recent milling of Boat, a couple of nodes mining on a local mainnet:



I’d like to stress the importance of how close many algo-variant altcoins are to the Bitcoin cloneparent. My approach is to replace all the user-facing coin-specific “Bitcoin” strings (and their case variations) with a Jinja2 template expression: {{coinname}}, {{coinlcname}}, etc. I do the same for all of the other coin-specific variations (e.g. {{mainnetport}}) - it's a process that takes a couple of hours. The end result is a Minkiz Foundry template that is amenable to template-engine replacement (courtesy of Python and the Jinja2 templating engine) of all the relevant variations with coin-specific values maintained in a Python dictionary of just a couple of hundred items (of which a good half are merely testnet/regtest values).

Where altcoins vary more substantially from the cloneparent than just in hash algo (e.g. Namecoin, Peercoin, Datacoin, any altcoin with masternodes), my approach is to create a branch variant and apply the same template approach to the variant. For example, the 0.16.3 version of Datacoin is milled from a Minkiz Foundry branch-variant template.


(It's quite a high-power approach. A few months ago one of the Datacoin folks asked me how difficult it would be to add PoS to Datacoin. In just a few hours I was able to blend the Peercoin branch variant with the Datacoin branch variant and produce a version of Peercoin augmented with Datacoin’s per-transaction data storage and fee structure.)

To be honest, maintaining the branch-variants isn’t all that taxing, thanks to the excellent software engineering tools now available. I use meld to assist me with maintaining the branch variants as well as identifying the necessary variations. Here’s an example of just how limited the difference is in block structure for a Primecoin-clone such as Datacoin that needs to extend the block structure in order to carry PoW-relevant data about the specific prime chain and its length at that point in the chain:




Gapcoin is a similar branch variant. It’s the same as Bitcoin except that it uses a prime gap search PoW algo instead of a hash algo - it’s quite similar to Primecoin in that the block structure is extended to carry key information about the primes in order to facilitate the PoW calculation and ultimate rendering as a hash:



So, finally, you have the semantics to ground your understanding of what I mean when I write “Gapcoin 0.16.3 is milled from a Minkiz Foundry template”. It's not a trivial statement, there’s a lot of solid work to underpin it.

As regards the reliability of the Gapcoin 0.16.3 client ... the version in my own Github repos has inherited a bit too much from the Minkiz Foundry template. It’s alright for me to muck about in private, trialling code that I believe enhances the appeal to users because I'm not intending to use it in anger. So it’s not really all that surprising that I’ll miss a trick now and again. The reason I made the comment about being caught off-guard was simply to communicate that this wasn’t a random bug but the result of a specific, identifiable - and addressable cause which is highly unlikely to be repeated.

Ideally, I’d prefer that all of the tests in the Gapcoin unit test suite passed. Unfortunately, quite a lot of the Bitcoin test suite is specific to Bitcoin and amongst the coindevs of my acquaintance, getting the tests to pass is a known PITA. Many’s the time I’ve eagerly examined the test suite of a altcoin newly-launched by a strong dev/team only to discover that the tests I was interested in knowing how to get working had simply been removed.

Let’s face it, the closer the Gapcoin codebase is to a contemporary Bitcoin cloneparent, the more confident we can be in its reliability and robustness. The qualifying term “contemporary” is rather important here - just check the Bitcoin CVE list from CVE-2015-3641 onwards - you will note that they all apply to the 0.9 client. (And in case you were wondering, the Gapcoin 0.16.3 client is the patched version and is not vulnerable to the recently-identified invdos attack.)

Usually, problems only originate when devs make changes to the code without overwhelmingly good reasons. I recently identified this commit to the Verge codebase as the likely cause of the recent long range hack in which more than six months worth of transactions and balances vanished from the Verge blockchain. This conjecture was confirmed by zawy12. (The “coindevs of my acquaintance” that I mentioned earlier are subscribers to the invite-only “CryptoDevs” Discord server of which I’m privileged to be an invited member - there are many highly-skilled and knowledgable subscribers, including zawy12 and some very well-known altcoin devs).

Please bear in mind here that I'm addressing what I perceive to be a community consensus, my perceptions may well not match the reality but unfortunately, there’s no way to find that out.

As regards the 0.16.3 client, I think that for the moment, the best course of action is for me to provide, in the Gapcoin-project repos, a “vanilla” Gapcoin 0.16.3 client, stripped of (nearly all) the extravagant additions of the client in my own Github repos. I write “nearly all” because I imagine the consensus would prefer to retain the in-wallet miner (removed from the Bitcoin codebase back in 0.13 and restored by me for Minkiz Foundry purposes) but not the GUI mining page (use setgenerate or the external, more readily configured, GapMiner), nor the chart of hash/difficulty on the overview page,  nor the GUI block explorer (use getblock), nor the list of prime gaps (use listprimerecords), nor the multisig GUI (use addmultisigaddress), nor the make/showkeypair RPC/API calls, nor the other RPC/API calls that I haven’t mentioned such as dumptriples, renderblockhash and nicely - and the embellishment of "About Gapcoin".

Please don’t mistake this for a fit of pique, it’s just being realistic about the (rather remote) chance of BitcoinFX managing to persuade someone else to work on the codebase. No-one will want to maintain all the frippery that I have added but a barebones clone with essential coin-specific changes would be a different matter.

And that position is quite readily attainable by milling a basic Minkiz Foundry 0,16.3 variant-branch template. It doesn’t mean that I will delete my Gapcoin repos, far from it, it just increases the likelihood of other people contributing to the mainstream Gaocoin codebase

I'm likely to make available a couple of versions of the enhanced Gapcoin client, a “GT” version with the GUI additions and a "de luxe" version with all the features I addded. As people begin to develop a more extensive model of the Gacoin 0.16.3 codebase, they may well come to appreciate the reliability of the basic codebase and understand that the additions are non-intrusive to the basic functioning of the client.

And, now that I've exposed the back-end workings of the Minkiz Foundry, the existence of a Gapcoin 0.20 client should be less of a surprise ... to give you a hint, here's a screenshot of the Ferrari 0.20 mining page that you might find a little familar:



It may be that not all the additions will get migrated to the 0.20+ codebase (I'll be working on the Minkiz Foundry 0.21 template sometime in the not-too-distant future). In particular 0.20 has seen an extensive rewrite of the network processing code and I ran into some as-yet-unresolved issues when porting over the DANDELION code and I've been informed by one of my coindev colleagues that with 0.20 the wallet code has been strongly modularised (i.e. more self-contained) and correspondingly is a lot more challenging to integrate with the miner. However, on balance, it’s far more important to retain upgrade compatibility with the strongly-developed upstream code (i.e. Bitcoin) and gain the benefit of improved reliablility, transaction security (anticipating stuff like Schnorr signature aggregation, etc) and all the other benefits accruing from the strength of the Bitcoin developers.

Ultimately, while I will freely confess that I'm not a C++ developer according to my standards, it doesn't mean that I harbour any deep misconceptions about the strength and depth of my technical skillset. From the above you may have formed (the intended) impression that I am highly accomplished and operate at a very high standard. At this level, one doesn’t find people needing to cope with feelings of inferiority by over-extolling their own skills, rather the reverse. People who work at really high-levels of accomplishment are readily characterised by what might appear to the uninitiated as excessive modesty and over-respect for other professionals. It's a bit of a tell-tale as it’s a useful kind of idiot filter; in general, anyone who doesn’t understand the origin of the modesty and reciprocate the respect is, in effect, signalling their relative inferiority on the technical scale of things.

If you’ve followed this leisurely journey all the way to here, then I salute you --- and I thank you, I have been able to communicate a lot of information about the Gapcoin codebase in a way that would be impossible without your understanding of the background and how the Gapcoin 0.16.3 client came to be.

Cheers

Graham


¹ pursuing cognitive science as a profession quickly gets one into “classical” AI, an area I worked in during the late 80s/early 90s in R&D as an HPLabs engineer (back when HP Labs was one of the FAANGs of the time) hence my interest in the semantic web, which is where many classical AI folks are now to be found (notably, e.g. Pat Hayes).


² A change to the message-identifying “magic bytes” from their Bitcoin-specific values is something of a signifier of an altcoin cloned by a capable and experienced developer. Many script-kiddie altcoin devs were ignorant of the implications of failing to follow this strong recommendation.

True.
I'm on testnet since 07/11/2020, day of pre-release of Alpha available.
C'mon, "pre-release" and "Alpha", seem's crystal clear to me.
Absolutely no indication was given to switch to the mainnet. It's the opposite.
I'll wait.

I also see that a lot of work is done in the shadows. After 6 or 7 years, no need to rush this part there.
So I'll just add Good luck and Good work guys !

Here's an example of a miner that would appear to be mining blocks to a single address ... not me! ... 

- https://chainz.cryptoid.info/gap/address.dws?GUNtDqH8QxesjU9p3TsE7LPkRjtGUykWrp.htm

As mentioned, it's not really a great idea in terms of anonymity or privacy, but I guess it adds some convenience to the mining process.

...

"We Got The Gun by Clint Mansell from Darren Aronofsky's Original Soundtrack"
- https://youtu.be/AFn-Wr3qDTY *Explicit Lyrics*

I debated with myself whether to mention generatetoaddress in my response. Although I haven't checked, because I haven't interfered with any of that particular code, I have no reason to doubt its flawless functioning. The trouble is that in-wallet mining of BTC on mainnet was (correctly) considered futile by the Bitcoin devs as far back as 0.13, nearly five years ago - at which point the code for the internal miner was removed from Bitcoin.

One of the key implications of this is that the remaining generator code in the Bitcoin codebase is intended solely for use with testnet/regtest.

The practical consequences are that generatetoaddress isn't suitable for use as a general-purpose, run-until-stopped miner. The call takes three arguments: the target number of blocks to generate, the address to which they should be credited and, importantly, the maximum number of tries to attempt before returning - generatetoaddress nblocks "address" ( maxtries ) - and then it stops and you need to call it again. It's not that it can't be driven from a bash/Powershell script, it's just that this additional technical demand imposes a higher barrier to entry.

However, the Bitcoin code that implements the address-handling for the generatetoaddress function is obviously a candidate for copying and pasting. If it's perceived as highly-desirable to integrate this functionality into the in-wallet miner, one approach would be to store a mining address in the gapcoin.conf file and pick up the value from that.

Be advised though, having all the mined blocks going to one address compromises anonymity but if there's a compelling use case, I would be prepared to consider putting in the time and effort to get it to work.

Cheers

Graham

Whilst I fully appreciate the predicament, we should all await Stable Release of Gapcoin Core v0.16.3 - across all platforms (hopefully) ...

See: Software release life cycle - Release Candidate (RC)
- https://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate

I personally need some more time to test and review everything.

Gapcoin Core v0.16.3 ...

cd gapcoin-core/src && ./gapcoin-cli help

Excerpt;

See:
- https://developer.bitcoin.org/reference/rpc/generatetoaddress.html

As I understand it, that's the way it's always been with the built-in miner, each block reward is credited to a newly-generated address (these days, actually a scriphash). Rewards credited to specifically-set addresses are feature of pool mining or solo mining with an external miner.

Cheers

Graham

I think the 16.3 Wallet is good for trying to adopt.  I think you should promote it now BitcoinFX.  It's solid mining ect........


The importing addresses will only be harder for new people if they start using the old wallets when they should be using the New one and never have to worry about the import issues.

I wish there was a better way for the wallet import. 

But I think it's best to get it out of the way and deal with the issues as they come up.  Promoting the old wallets will just be negative to the overall goal of getting new people to use Gapcoin.