Mod note: consecutive posts merged. hr inserted between posts where needed for clarity
new wallet give me error with my old wallet.dat
Indeed, the 0.16.3 client will not load wallet.dat files created with the 0.9 client because the 0.16.3 client wallets are in HD (Hierarchical Deterministic) key format.
The recommended route is either:
1. Hand-import all your privkeys to the 0.16.3 client by using `importprivkey <label> <rescan>` - 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 <privkey>.
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"
}
, 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 uUbNNUMyLLXFU6hFdSn6jGA6JoLp9tYPThe 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
