Migrating from the flat keyspace of the 0.9 client to the structured keyspace of the 0.16.3 client can be a bit challenging.

Gapcoin 0.16.3 inherits pretty much all its functionality as a cryptocurrency from its Bitcoin 0.16.3 cloneparent. The only major change between the two codebases is the use of j0nn9's prime gap implementation as a PoW hashing algorithm instead of Bitcoin's SHA256D, otherwise the functionality is more or less identical. This means that the Bitcoin 0.16.3 documentation is a useful source of information on the functioning of the Gapcoin client. By extension, this includes the Bitcoin wiki (although do bear in mind that the wiki is about the latest version of Bitcoin which is now 0.21) so there is useful documentation on, e.g. the HD wallet.

The first difference that you are likely to encounter is that importing a single privkey results in three new addresses appearing in the "Receiving addresses" popup. These three addresses are just different formats of the same basic underlying ECC pubkey/privkey pair - "legacy", "segwit" and "bech32".

Currently the client is configured to use legacy addresses by default - i.e. the ones returned by clicking on “Receive->Request Payment”.

However, the default can be changed in the gapcoin.conf file or on the command line:  -addresstype "What type of addresses to use ("legacy", "p2sh-segwit", or "bech32"

I have added a couple of RPC API calls to help people get a better understanding of Gapcoin's new keyspace: makekeypair and showkeypair <privkey>.

Example output from makekeypair:
"privkey" is the one you're already used to (it's a reduced-format version of the of the ECC private key) whereas "public key" and "private key" will be new to you, they are the actual ECC public and private keys.

Aside: By default, makekeypair creates “compressed“ keys. Very early versions of the Bitcoin client were coded to use the points on both positive and negative x and y axes of the elliptic curve, i.e. two pairs of rather large numbers, the pairs being identical except that one was negative.  As Bitcoin evolved, it was realised that only one of the two pairs was necessary, along with a single bit indicating whether the pair was the positive or negative one - this reduced format was termed “compressed” and is now the norm.

Except that the test fixture for the test suite key still checks the validity of the uncompressed keys in the test fixture.

Although it's irrelevant in normal use, for the purposes of testing, it suited me to add an option to the makekeypair, if you pass it a second argument ("false"), it generates uncompressed keys:

The space-saving properties of compressed keys should be obvious.

So now you know.

Okay, on to showkeypair. There's less to say about this, it's a convenience function to allow you to identify which address is which, when given a privkey:


Aside, for eyewatering completeness, this is the result when using an uncompressed privkey:


Further to Gapcoin’s newly-ac Although it doesn't support mnemonic passphrases directly, the Gapcoin HD wallet is indirectly supported to as a BIP39 wallet