` - providing a label will better help you manage your keys in an HD-enabled wallet and if you have several privkeys to import, use “false” for rescan and afterwards restart the client with the -rescan option on the command line. For ultimate clarity, here is the output for `help importprivkey`:
./src/gapcoin-cli -datadir=`pwd`/datadir help importprivkey
importprivkey "privkey" ( "label" ) ( rescan )
Adds a private key (as returned by dumpprivkey) to your wallet. Requires a new wallet backup.
Arguments:
1. "privkey" (string, required) The private key (see dumpprivkey)
2. "label" (string, optional, default="") An optional label
3. rescan (boolean, optional, default=true) Rescan the wallet for transactions
Note: This call can take minutes to complete if rescan is true, during that time, other rpc calls
may report that the imported key exists but related transactions are still missing, leading to
temporarily incorrect/bogus balances and unspent outputs until rescan completes.
Examples:
Dump a private key
> gapcoin-cli dumpprivkey "myaddress"
Import the private key with rescan
> gapcoin-cli importprivkey "mykey"
Import using a label and without rescan
> gapcoin-cli importprivkey "mykey" "testing" false
Import using default blank label and without rescan
> gapcoin-cli importprivkey "mykey" "" false
As a JSON-RPC call
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "importprivkey", "params": ["mykey", "testing", false] }' -H 'content-type: text/plain;' http://127.0.0.1:31397/
2. Use dumpwallet and importwallet because the 0.16.3 client can import wallets dumped by the 0.9 client.
Start the 0.9 client and in the debug console, run dumpwallet "/some/path/mydumpedwallet.txt" (You can and should provide an OS-specific pathname). Stop the 0.9 client, start the 0.16.3 client and in the debug console run importwallet "/some/path/mydumpedwallet.txt". Basically it's just a bulk import of privkeys with an automatic rescan.
Cheers
Graham
providing a label will better help you manage your keys in an HD-enabled wallet
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 .
Example output from makekeypair:
./src/gapcoin-cli makekeypair
{
"compressed": true,
"addresses": {
"legacy": "GcwphVTaks2XGGB8RUk7auWdgmG8CV14TF",
"segwit": "34GsDWQGPQJHgv366Cvsd5PDQecj6P5cMK",
"bech32": "gp1q6xype4d7cvltvu92r3ujv7j229kh0my6t6cxpy"
},
"privkey": "FP547eMzeXLZvppGjkxTNkAx1wf9z9vZgWLSS2AkWYkia2dfkkU9",
"public key": "034e63f9af0ad2cf6e70f3785ecdc15cdb830c0fd252f366be43bee5eea6be6001",
"private key": "36796105fbdb2e68528bb09a21a95b25a89b96f59aa073de08db0aaa7b2c1d7f"
}
"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:
./src/gapcoin-cli makekeypair false
{
"compressed": false,
"addresses": {
"legacy": "Gc6WYBnYDeVpbHySQx6E5h1hjcn3Cj8J9a"
},
"privkey": "4H5pZbnhj9BFmj6pg7ExNg2NhWUHwek9c7LVCPyfDf6BscvZ8n6",
"public key": "0401493fe086dac8f5c22c08fec7f71c915b9591709cd4fe1ab84e17e1e414b51e90d3464edc4b03c19d488c96e8b3845e8ccdd83233c4053aad6f8b2cb3c02a5d",
"private key": "c933dcfa2aeabae973f1c0eccce0012fb938ea2d00f6ed4e1894c736df4c014a"
}
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:
./src/gapcoin-cli showkeypair FP547eMzeXLZvppGjkxTNkAx1wf9z9vZgWLSS2AkWYkia2dfkkU9
{
"addresses": {
"legacy": "GcwphVTaks2XGGB8RUk7auWdgmG8CV14TF",
"segwit": "34GsDWQGPQJHgv366Cvsd5PDQecj6P5cMK",
"bech32": "gp1q6xype4d7cvltvu92r3ujv7j229kh0my6t6cxpy"
},
"privkey": "FP547eMzeXLZvppGjkxTNkAx1wf9z9vZgWLSS2AkWYkia2dfkkU9",
"public key": "034e63f9af0ad2cf6e70f3785ecdc15cdb830c0fd252f366be43bee5eea6be6001",
"private key": "36796105fbdb2e68528bb09a21a95b25a89b96f59aa073de08db0aaa7b2c1d7f"
}
Aside, for eyewatering completeness, this is the result when using an uncompressed privkey:
./src/gapcoin-cli showkeypair 4H5pZbnhj9BFmj6pg7ExNg2NhWUHwek9c7LVCPyfDf6BscvZ8n6
{
"addresses": {
"legacy": "Gc6WYBnYDeVpbHySQx6E5h1hjcn3Cj8J9a"
},
"privkey": "4H5pZbnhj9BFmj6pg7ExNg2NhWUHwek9c7LVCPyfDf6BscvZ8n6",
"public key": "0401493fe086dac8f5c22c08fec7f71c915b9591709cd4fe1ab84e17e1e414b51e90d3464edc4b03c19d488c96e8b3845e8ccdd83233c4053aad6f8b2cb3c02a5d",
"private key": "c933dcfa2aeabae973f1c0eccce0012fb938ea2d00f6ed4e1894c736df4c014a"
}
HTH
Cheers
Graham
Further to Gapcoin’s newly-acquired structured key space ...
Although the 0.16.3 client doesn't support mnemonic passphrases directly, mnemonic passphrases for the Gapcoin HD wallet are indirectly supported via Ian Coleman’s standalone BIP-39 key management HTML/Javascript application. I have cloned his repos and added the relevant Gapcoin extended key values. Using the application is quite straightforward, just clone the repos and open src/index.html in your browser.
There are two ways of using the application: i) with mnemonics in which you need to import any subequently-generated privkeys into the wallet and ii) without mnemonics in which you paste your wallet's extended privkey into the application and use it to manage/understand the structured space of keys.
First off, select "Gapcoin" in the drop-down “Coin” menu. Ignore the "Invalid root key warning", it just wants you to click the “Generate” button, so do that next in order to generate a mnemonic and a root key. If you're going to use this means of managing keys, remember to commit the mnemonic to memory or disk or whatever.
Otherwise, if you're not interested in using a mnemonic but merely want to understand the extended key space, navigate to a wallet.txt file dumped by the 0.16.3 client, open it and copy the extended private master key (starting with "gpxv") and paste it into the “BIP32 Root Key” form field, accepting the warning.
Example extended private key to use:
# extended private masterkey: gpxv2JGkH1LYqUHcfU6LRjkgVx97cdrSarWyaraNQDkatPErTKfvajmGLZ46HqYUAurH3v5ioD8v9BnZpC8qRqRRuFVkcMzs78tQdbgrAPHigSZ
The corresponding extended public key is gpxp1b6ZHwV3SZpyNoYgtH2HrSsAct6w6FetogsekTuEWKJCxN5YjzKeY3YAns97h2CVogTfv6YGh7W uUbNNUMyLLXFU6hFdSn6jGA6JoLp9tYP
The HD wallet is extensively documented on the Bitcoin wiki on the BIP_0032 page but basically, with hierarchical deterministic wallets, the key space is conceived of as a keypath of the form
m/44/15/0/0, pretty much like a filepath, with the following meanings:
m / purpose' / coin_type' / account' / chain / address_index
Deconstructing the path m/44'/15'/0'/0 deconstruction
44 — BIP 44 Purpose
15 — Gapcoin’s coin type
0 — Account 0
0 — Chain 0
Gapcoin’s coin type is "15", repurposing the long-vanished Clearinghouse assignment. I applied for registration but the gatekeepers declined the request, so, in the finest tradition of altcoin devs, I simply ignored the centralised “authority” and used the number anyway.
Fwiw, Harsha Goli's medium blog post “HD Wallets Explained: From High Level to Nuts and Bolts” covers the topic very well.
With Gapcoin, the "gpxv" and "gpxp" are extended key "vanity addresses" (Bitcoin uses "xprv" and "xpub" respectively). I generated the complete set for mainnet and testnet.
BIP39 Extended keys
{
'public': '033C0DF8',
'private': '033C0E22',
}
Mainnet and Regtest
{
'p2pkhpub': '033C0DF8', 'p2pkhprv': '033C0E22', // x
'p2shpub': '033C0DF8', 'p2shprv': '033C0E22', // x
'p2sh_p2wpkhpub': '033C0F8D', 'p2sh_p2wpkhprv': '033C0FB7', // y
'p2sh_p2wshpub': '033BE7FF', 'p2sh_p2wshprv': '033BE829', // Y
'p2wpkhpub': '033C1123', 'p2wpkhprv': '033C114C', // z
'p2wshpub': '033BE994', 'p2wshprv': '033BE9BE' // Z
}
Testnet
{
'p2pkhpub': '033C07A4', 'p2pkhprv': '033C07CE', // t
'p2shpub': '033C07A4', 'p2shprv': '033C07CE', // t
'p2sh_p2wpkhpub': '033C0939', 'p2sh_p2wpkhprv': '033C0963', // u
'p2sh_p2wshpub': '033BE1AB', 'p2sh_p2wshprv': '033BE1D5', // U
'p2wpkhpub': '033C0ACE', 'p2wpkhprv': '033C0AF8', // v
'p2wshpub': '033BE340', 'p2wshprv': '033BE36A' // V
}
It all looks impenetrable but the scheme is reasonably simple:
Mainnet:
Legacy:
x = P2PKH or P2SH
Segwit:
y = P2WPKH in P2SH
Y = Multi-signature P2WSH in P2SH
Bech32:
z = P2WPKH
Z = Multi-signature P2WSH
Testnet:
Legacy:
t = P2PKH/P2SH
Segwit:
u = P2WPKH in P2SH
U = Multi-signature P2WSH in P2SH
Bech32:
v = P2WPKH
V = Multi-signature P2WSH
In summary - you have "legacy", the simplest form of pay to Pubkey hash or Script Hash. Then you have a combo of single-sig vs multisig for pubkey hash vs script hash witnessed transactions.
The Gapcoin-specfic scheme is gc[x|y|Y|z|Z][p|v], that is to say "gc" followed by one of "x", "y", "Y", "z" or "Z" (denoting the role) and "p" or "v" (denoting "public" or "private")
Now you're good to get going managing your Gapcoin structured key space according to the BIP32, BIP44, BIP49, BIP84 and BIP141 protocols.
Cheers
Graham
