Use internal HD chain for change outputs (hd split) #9294

jonasschnelli · 2016-12-06T10:08:19Z

Main changes

This pull request will result in using m/0'/1'/k' for internal keys (change outputs) while keeping m/0'/0'/k' for external keys (getnewaddress).

There is still a single keypool. All keypool elements (CKeyPool) have now a flag (fInternal).
~~The keypool will be filled with 80% external keys (round ceil).~~
The keypool will be filled with 100% external keys + 20% (round ceil) internal keys.
getwalletinfo additionally reports keypoolsize_hd_internal (amount of internal key in the

Compatibility:

This hd split change will only affect new wallets. Current 0.13 HD wallets will continue to only use the external chain.
Using a 0.14 wallet in <0.14 is not possible (hd chain split requires 0.14)
Using a 0.13 wallet in 0.14 will result in continue using only the external chain (only m/0'/0'/k').

This change also fixes the keypool +1 offset.

laanwj · 2016-12-06T10:44:28Z

Interesting assertion error in CWallet::CreateRawTransaction

stderr:
bitcoind: ../../src/wallet/wallet.cpp:2395: bool CWallet::CreateTransaction(const std::vector<CRecipient>&, CWalletTx&, CReserveKey&, CAmount&, int&, std::string&, const CCoinControl*, bool): Assertion `ret' failed.
  File "/home/travis/build/bitcoin/bitcoin/qa/rpc-tests/test_framework/test_framework.py", line 145, in main
    self.run_test()
  File "/home/travis/build/bitcoin/bitcoin/build/../qa/rpc-tests/fundrawtransaction.py", line 498, in run_test
    fundedTx = self.nodes[1].fundrawtransaction(rawTx)
  File "/home/travis/build/bitcoin/bitcoin/qa/rpc-tests/test_framework/coverage.py", line 49, in __call__
    return_val = self.auth_service_proxy_instance.__call__(*args, **kwargs)
  File "/home/travis/build/bitcoin/bitcoin/qa/rpc-tests/test_framework/authproxy.py", line 150, in __call__
    response = self._request('POST', self.__url.path, postdata.encode('utf-8'))
  File "/home/travis/build/bitcoin/bitcoin/qa/rpc-tests/test_framework/authproxy.py", line 130, in _request
    self.__conn.request(method, path, postdata, headers)
  File "/usr/lib/python3.4/http/client.py", line 1125, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python3.4/http/client.py", line 1163, in _send_request
    self.endheaders(body)
  File "/usr/lib/python3.4/http/client.py", line 1121, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python3.4/http/client.py", line 951, in _send_output
    self.send(msg)
  File "/usr/lib/python3.4/http/client.py", line 886, in send
    self.connect()
  File "/usr/lib/python3.4/http/client.py", line 863, in connect
    self.timeout, self.source_address)
  File "/usr/lib/python3.4/socket.py", line 512, in create_connection
    raise err
  File "/usr/lib/python3.4/socket.py", line 503, in create_connection
    sock.connect(sa)

jonasschnelli · 2016-12-06T12:53:04Z

Travis is failing because it did what it is supposed to: finding bugs.
Once #9295 is merged, travis should succeed.

paveljanik · 2016-12-08T13:39:10Z

qa/rpc-tests/keypool.py

Still three?

paveljanik · 2016-12-08T13:40:19Z

qa/rpc-tests/keypool.py

also, this is 100%, not 80% of 6. 100% vs 20%, not 80% vs 20%.

gmaxwell · 2016-12-10T19:20:42Z

Once #9295 is merged, travis should succeed.

Shall we find out?

jonasschnelli · 2016-12-11T10:16:11Z

Rebased.

jonasschnelli · 2016-12-12T08:37:55Z

Travis succeeds now.

luke-jr

I don't see code for upgrading existing HD wallets.

Does this implement a BIP that should be mentioned?

luke-jr · 2016-12-22T19:19:44Z

src/wallet/wallet.cpp

Prefer to explicitly add (internal ? 1 : 0)

luke-jr · 2016-12-22T20:09:31Z

src/wallet/wallet.cpp

Seems like it would be better to just access the specific counter once with a post-increment, and use variables here.

luke-jr · 2016-12-22T20:13:15Z

src/wallet/wallet.cpp

IMO this is unintuitive ~~and can lead to loss~~. If users set a keypool size of 100, they expect to be able to safely generate 100 addresses between backups. I usually round down to 90 in advice to give some breathing room, but 80% here will break even that.

Therefore, the full keypool size should be ensured on both chains.

Edit: Forgot this was HD. Less critical in that case.

Yes. This is a discussion point and I'd like to get others feedback (maybe @gmaxwell and @sipa).
The question is, if you want a keypool of 100 external + 50 (TBD) internals = total 150 keys, if you set the keypool to 100.

IMO user given values should be respected. If the user chooses keypool=100, the keypool should contain 100 keys. But as said, no strong opinion on that.

luke-jr · 2016-12-22T20:16:23Z

src/wallet/wallet.cpp

IMO it would be better to use an enum for internal vs external rather than a bool.

IMO it would be better to use an enum for internal vs external rather than a bool.

Why? Either its internal or external. Once we have more configurable HD key derivation (ext-pubkey-derivation, hd-multisig) we could switch to a enum or a more flexible design.

To avoid implicit casting when/if the type changes for this parameter. Also makes it clearer at the call-locations what the parameter is specifying.

jonasschnelli · 2017-01-06T13:49:02Z

Overhauled after recommendation from @sipa and @luke-jr.

The amount of external pre-generated keys now back at 100% from -keypool=(default 100).
The amount of internal pre-generated keys is +20% from -keypool=(default 100).
Pre-generate two internal keys at minimum

... this now results in always have 120% keys pre-generated (20% internal key)

jonasschnelli · 2017-01-09T07:46:47Z

Updated with a small nit-fix (#9294 (comment)) and a fix for wallet-dump.py RPC test. Travis should succeed now.

instagibbs

You might also want to have a test that ensures the ceil behavior is correct for the 100vs20 split as I think the tests only check evenly divisible or the min value of 2.

instagibbs · 2017-01-09T14:45:18Z

src/wallet/wallet.cpp

It's called externalChainChildKey but it could be either.

instagibbs · 2017-01-09T14:46:51Z

src/wallet/wallet.cpp

update comment

instagibbs · 2017-01-09T14:50:51Z

src/wallet/wallet.cpp

/HD/HD split/?

instagibbs · 2017-01-09T14:54:57Z

src/wallet/wallet.cpp

I find it a bit confusing that this value goes from 0(non-existant) to -keypool then to -keypool*.2. Perhaps have it start at 0 on previous commit, then set it to non-0 here (unless there is reasoning).

I find it a bit confusing that this value goes from 0(non-existant) to -keypool then to -keypool*.2. Perhaps have it start at 0 on previous commit, then set it to non-0 here (unless there is reasoning).

Fixed. I decided to squash the two commit into a single one because the current PR is a non-splittable change.

Can we just set the target for both internal and external to nTargetSize? It seems super non-user-friendly that the setting which used to mean "can create this many keys/transactions" now means "can create this many keys, or 1/5th as many transactions". I dont think we care all that much about the performance hit, do we?

Some weeks back we discusses that and we came up with something that we should create less internal keys. But I'm fine with 100%/100%. Any objections?

I'd be fine with reducing the internal keypool significantly once we have rescan logic that can regenerate keys, but until then I think we absolutely need to have it be 100%.

instagibbs · 2017-01-09T14:56:43Z

src/wallet/wallet.cpp

Seems like a separate optimization?

Right. This is no longer required because we always derive at minimum 2 internal keys. And ReserveKeyFromKeyPool will topup the keypool.
Will remove that part.

instagibbs · 2017-01-09T15:05:38Z

src/wallet/rpcwallet.cpp

Might make sense to explicitly count both types and use those counts if we foresee a future with more possible types rather than implicitly count total - external. You'd know better than me how likely that is.

I think it make sense to keep this as it is: keypoolsize should be alined with the -keypool conf. That's why keypoolsize in getwalletinfo responses only the external key-count in the keypool (-keypool conf arg also defines the external key count).

Sorry, I agree with what you're saying I just wasn't clear enough. I suppose it's along the lines of @luke-jr 's comment about enum, keeping flexible for the future. Not a blocker, just a suggestion. That can be deferred.

Right. This is generally a good idea. IMO the next possible HD extensions (far away) are maybe xpub watch-only-wallets, flexible keypath, hd-multisig.
I can't imagine any change the would require a third (or more then two) type(s) during key derivation as well as in the keypool.

"keypoolsizes": {"internal": N, "external": N} sounds like a good idea here.

I though about that, but this would break the API while the current PRs change does not.

instagibbs · 2017-01-09T15:13:48Z

qa/rpc-tests/keypool.py

also, this is 100%, not 80% of 6. 100% vs 20%, not 80% vs 20%.

jonasschnelli · 2017-01-10T15:51:47Z

Fixed @instagibbs points. Squashed into a single commit.

instagibbs · 2017-01-10T16:04:18Z

utACK 4065d5fd44b9ce68a688c82353822a1cf49efe53

jtimon · 2017-01-10T18:16:31Z

I'm not sure how this would work together with #8723 but at a first glance at the code, it seems to simplify things: concept ACK. Can you explain more about its interaction with #8723 and maybe suggest one of them to focus review on first?

jonasschnelli · 2017-01-12T19:46:46Z

Rebased.

luke-jr · 2017-01-12T20:19:41Z

src/wallet/walletdb.h

This should set nInternalChainCounter for old versions - maybe use std::numeric_limits<uint32_t>::max() (and make it private, with all accessors throwing if it's not a sufficient version)?

Also, braces, please.

Where do you see the need to set the nInternalChainCounter for old versions here? Old Versions will always have the nInternalChainCounter set the 0 over SetNull() during the constructor call.

A new chain (which then will enable VERSION_HD_CHAIN_SPLIT) can only be created when a new HD master key will be set which again will enable FEATURE_HD_SPLIT.

It should be setup to prevent accidental usage. If any code were to attempt to use it without a wallet that supports it, we want to throw an error/exception, not silently generate keys we may not be able to recover.

luke-jr · 2017-01-12T20:21:02Z

src/wallet/wallet.cpp

To avoid implicit casting when/if the type changes for this parameter. Also makes it clearer at the call-locations what the parameter is specifying.

luke-jr · 2017-01-12T20:22:25Z

src/wallet/wallet.cpp

Is there a reason to do this check here, rather than inside DeriveNewChildKey?

A design question, but IMO DeriveNewChildKey should execute the derivation and not care about wallet versions and supported features.

Maybe move it to private: then?

Yea, really should be private, I think.

luke-jr · 2017-01-12T20:24:34Z

src/wallet/wallet.cpp

Seems like this could be significantly simplified with:

uint32_t &nChainCounter = (internal ? hdChain.nInternalChainCounter : hdChain.nExternalChainCounter);

Since almost everything here is different depending on internal/external, I think it'd be clearer to just make it if (internal) and separate the behaviors

luke-jr · 2017-01-12T20:26:25Z

src/wallet/wallet.cpp

I think this won't work if the user specifies a HD-but-not-split wallet version for -walletupgrade?

I think we should no longer allow non split HD versions.

This also forcibly upgrades the user's wallet (if from pre-split HD version) if they encrypt their wallet, which I think is unaccptable.

Note that if you change this need to set the newHdChain's version to the appropriate value prior to SetHDChain.

We could... one question is: if the users encrypt his 0.13 wallet (HD enabled but no chain split) in 0.14. Do we want to keep the non-hd split or do we want to enforce an upgrade to HD_Split. The later seems preferable from the users perspective (Is there a reason to not split the HD chains if we can?).

I believe it is policy to not upgrade a user's wallet unless they have specifically requested we do so, so, no, I dont think we should use HD_Split at that point.

luke-jr · 2017-01-12T20:56:54Z

src/wallet/wallet.h

Do we want internal to have a default? Should it be false? IIRC currently new keys default to change unless added to the address book, so this default seems to contradict the status quo.

I have set the default to false to keep the exiting behaviour.

My point is that the existing behaviour is closer to true than false.

luke-jr · 2017-01-12T20:58:26Z

src/wallet/walletdb.h

Missing logic to initialise this version.

VERSION_HD_BASE is only there to identify versions that do not support HD SPLIT (first HD version introduced in 0.13).

luke-jr · 2017-01-12T21:02:36Z

src/wallet/rpcwallet.cpp

keypoolsize should probably be the lower of the two and deprecated. There is no reason to assume prior use didn't look at it for info on change keys.

luke-jr · 2017-01-12T21:03:47Z

src/wallet/rpcwallet.cpp

"keypoolsizes": {"internal": N, "external": N} sounds like a good idea here.

luke-jr · 2017-01-12T21:04:32Z

src/wallet/rpcwallet.cpp

Shouldn't this use CanSupportFeature(FEATURE_HD_SPLIT)?

I think always reporting keypoolsize_hd_internal (with 0 in non HD-SPLIT case) can make parsing simpler.

Then always report it? Right now it's conditional on something more or less irrelevant.

But I'm not sure it makes sense to ever report 0 when there are indeed keys that will be used for internal outputs...

jonasschnelli · 2017-01-13T07:38:52Z

Added a commit that addresses some of @luke-jr points.
Maybe we can try to not bike-shed this with to many design and code-style nits (braces, etc.) otherwise we will very likely delay this for 0.15.

TheBlueMatt · 2017-01-14T03:18:43Z

src/wallet/rpcwallet.cpp

I think the 10% number is wrong? current code is 20, I believe? (and I think it should be changed to 100).

TheBlueMatt · 2017-01-14T03:20:58Z

src/wallet/rpcwallet.cpp

I think we really need to update this - keypoololdest is used to know when your backup has been invalidated. I know technically now that we have HD wallets arent invalidated, but until we have rebuilding-from-chain implemented I think we really need to make sure keypoololdest is still useable as "if your backup is older than this date, backup again".

This means keypoololdest needs to be max(oldest internal keypool, oldest external keypool) isntead.

Agree. But probably in a separate PR.

Not doing this would break some uses of walletbackup, I think, so I wouldnt be too happy with this slipping into a different release.

Maybe add a TODO comment (though this does seem to me like a desirable change to include in this PR).

Maybe add a TODO comment (though this does seem to me like a desirable change to include in this PR).

This is fixed in the current version.

…in-split wallets

…(oldest-internal-key, oldest-external-key)

…to getrawchangeaddress())

…ery first point

…t keys

jonasschnelli · 2017-03-24T10:05:23Z

Addressed @TheBlueMatt's nits (except #9294 (comment) which I'm not sure if this is a concern or not)

NicolasDorier · 2017-03-27T06:00:57Z

re utACK 1df08d1

jonasschnelli · 2017-03-27T07:53:29Z

Added a commit to address the backward compatibility issue during wallet encryption mentioned by @TheBlueMatt (#9294 (comment)).
@TheBlueMatt: can you give it a re-test?

TheBlueMatt · 2017-03-27T21:10:49Z

src/wallet/rpcwallet.cpp


    UniValue obj(UniValue::VOBJ);
+
+    size_t kpExternalSize = pwalletMain->KeypoolCountExternalKeys();


Oops, should be pwallet, not pwalletMain now :).

TheBlueMatt · 2017-03-27T21:19:29Z

src/wallet/walletdb.h

        READWRITE(this->nVersion);
        READWRITE(nExternalChainCounter);
+        if (this->nVersion >= VERSION_HD_CHAIN_SPLIT)
+            READWRITE(nInternalChainCounter);


In addition to the fix for backward compat where you set the version, can we make this more robust and flip the order? Generally adding new fields for (de-)serialization we should be adding them to the end.

TheBlueMatt · 2017-03-27T21:28:08Z

src/wallet/wallet.cpp

-            if (!SetHDMasterKey(masterPubKey))
+            // preserve the old chains version to not break backward compatibility
+            CHDChain oldChain = GetHDChain();
+            if (!SetHDMasterKey(masterPubKey, &oldChain))


Why not SetHDMasterKey(int nHDChainVersion)? Then you can just do CanSupportFeature(FEATURE_HD_SPLIT) ? CHDChain::VERSION_HD_CHAIN_SPLIT : CHDChain::VERSION_HD_BASE.

I though hiding the internals at this point would be preferable. IMO CWallet::encryptWallet should not have direct knowhow of the CHDChain version handling. I'd prefer passing in the old chain and let it be handled through SetHDMasterKey. Also, in future maybe other attributes need to be preserved.
Not sure although.

It kinda feels like mixing models, then. Wallet checks for FEATURE_HD_SPLIT everywhere before it updates the nInternalCounts, ie it seems to think its responsible for doing the checks, only to have CHDChain hide some stuff like version, but then you have to copy the version? Either we move logic into CHDChain (as @luke-jr suggested previously, have CHDChain know what version means and assert if you try to use the internal counter with a version that doesnt support it, which I assume some folks would object to), or all the logic should be in CWallet.

TheBlueMatt · 2017-03-27T21:43:53Z

src/wallet/wallet.cpp

+        for(const int64_t& id : setKeyPool)
+        {
+            if (!walletdb.ReadPool(id, keypool)) {
+                throw std::runtime_error(std::string(__func__) + ": read failed");


nit: the old version does an assert(keypool.vchPubKey.IsValid()); which is nice to have...not necessary to add, but would be cool.

For the keypool oldest it's further down L3026 (at https://github.com/bitcoin/bitcoin/pull/9294/files#diff-b2bb174788c7409b671c46ccc86034bdL3026)

Ser./Deser. nInternalChainCounter as last element

jonasschnelli · 2017-03-28T07:20:43Z

Fixed two points reported by @TheBlueMatt:

Move Ser./Deser. of nInternalChainCounter to be the last element
Fix a rebase issue where pwalletMain was used instead of pWallet.

laanwj · 2017-03-29T10:46:58Z

utACK 4115af7
I think this has enough ACKs. Let's merge this and fix the rest, which seems to be less critical, later.

4115af7 Fix rebase issue where pwalletMain was used instead of pwallet Ser./Deser. nInternalChainCounter as last element (Jonas Schnelli) 9382f04 Do not break backward compatibility during wallet encryption (Jonas Schnelli) 1df08d1 Add assertion for CanSupportFeature(FEATURE_HD_SPLIT) (Jonas Schnelli) cd468d0 Define CWallet::DeriveNewChildKey() as private (Jonas Schnelli) ed79e4f Optimize GetOldestKeyPoolTime(), return as soon as we have both oldest keys (Jonas Schnelli) 771a304 Make sure we set the wallets min version to FEATURE_HD_SPLIT at the very first point (Jonas Schnelli) 1b3b5c6 Slightly modify fundrawtransaction.py test (change getnewaddress() into getrawchangeaddress()) (Jonas Schnelli) 003e197 Remove FEATURE_HD_SPLIT bump TODO (Jonas Schnelli) d9638e5 Overhaul the internal/external key derive switch (Jonas Schnelli) 1090502 Fix superfluous cast and code style nits in RPC wallet-hd.py test (Jonas Schnelli) 58e1483 CKeyPool avoid "catch (...)" in SerializationOp (Jonas Schnelli) e138876 Only show keypoolsize_hd_internal if HD split is enabled (Jonas Schnelli) add38d9 GetOldestKeyPoolTime: if HD & HD Chain Split is enabled, response max(oldest-internal-key, oldest-external-key) (Jonas Schnelli) dd526c2 Don't switch to HD-chain-split during wallet encryption of non HD-chain-split wallets (Jonas Schnelli) 79df9df Switch to 100% for the HD internal keypool size (Jonas Schnelli) bcafca1 Make sure we always generate one keypool key at minimum (Jonas Schnelli) d0a627a Fix issue where CDataStream->nVersion was taken a CKeyPool record version (Jonas Schnelli) 9af8f00 Make sure we hand out keypool keys if HD_SPLIT is not enabled (Jonas Schnelli) 469a47b Make sure ReserveKeyFromKeyPool only hands out internal keys if HD_SPLIT is supported (Jonas Schnelli) 05a9b49 Fix wrong keypool internal size in RPC getwalletinfo help (Jonas Schnelli) 01de822 Removed redundant IsLocked() check in NewKeyPool() (Jonas Schnelli) d59531d Immediately return setKeyPool's size if HD or HD_SPLIT is disabled or not supported (Jonas Schnelli) 02592f4 [Wallet] split the keypool in an internal and external part (Jonas Schnelli) Tree-SHA512: 80d355d5e844b48c3163b56c788ab8b5b5285db0ceeb19858a3ef517d5a702afeca21dbae526d7b8fb4101c2a745af1d92bf557c40cf516780f17992bf678c1a

jonasschnelli added the Wallet label Dec 6, 2016

jonasschnelli added this to the 0.14.0 milestone Dec 6, 2016

jonasschnelli mentioned this pull request Dec 7, 2016

[Wallet] use CHDPubKey, don't store child priv keys in db, derive on the fly #9298

Closed

paveljanik reviewed Dec 8, 2016

View reviewed changes

qa/rpc-tests/keypool.py Outdated

Copy link

Contributor

paveljanik Dec 8, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still three?

paveljanik reviewed Dec 8, 2016

View reviewed changes

jonasschnelli force-pushed the 2016/12/hd_split branch from 324c7f5 to 1928302 Compare December 11, 2016 10:15

jonasschnelli force-pushed the 2016/12/hd_split branch from 1928302 to 0971c35 Compare December 12, 2016 08:12

luke-jr suggested changes Dec 22, 2016

View reviewed changes

jonasschnelli force-pushed the 2016/12/hd_split branch 2 times, most recently from 409535d to 3817bbe Compare January 6, 2017 13:45

jonasschnelli force-pushed the 2016/12/hd_split branch from 3817bbe to 034ee19 Compare January 9, 2017 07:42

jonasschnelli force-pushed the 2016/12/hd_split branch from 034ee19 to 76c883c Compare January 9, 2017 08:53

instagibbs reviewed Jan 9, 2017

View reviewed changes

jonasschnelli force-pushed the 2016/12/hd_split branch from 76c883c to 4065d5f Compare January 10, 2017 15:49

jonasschnelli force-pushed the 2016/12/hd_split branch from 4065d5f to 0a7b70a Compare January 12, 2017 19:45

luke-jr suggested changes Jan 12, 2017

View reviewed changes

TheBlueMatt reviewed Jan 14, 2017

View reviewed changes

jonasschnelli added 9 commits March 24, 2017 10:28

Switch to 100% for the HD internal keypool size

79df9df

Don't switch to HD-chain-split during wallet encryption of non HD-cha…

dd526c2

…in-split wallets

GetOldestKeyPoolTime: if HD & HD Chain Split is enabled, response max…

add38d9

…(oldest-internal-key, oldest-external-key)

Only show keypoolsize_hd_internal if HD split is enabled

e138876

CKeyPool avoid "catch (...)" in SerializationOp

58e1483

Fix superfluous cast and code style nits in RPC wallet-hd.py test

1090502

Overhaul the internal/external key derive switch

d9638e5

Remove FEATURE_HD_SPLIT bump TODO

003e197

Slightly modify fundrawtransaction.py test (change getnewaddress() in…

1b3b5c6

…to getrawchangeaddress())

jonasschnelli force-pushed the 2016/12/hd_split branch from 78f2cb9 to 1b3b5c6 Compare March 24, 2017 09:29

jonasschnelli added 4 commits March 24, 2017 10:53

Make sure we set the wallets min version to FEATURE_HD_SPLIT at the v…

771a304

…ery first point

Optimize GetOldestKeyPoolTime(), return as soon as we have both oldes…

ed79e4f

…t keys

Define CWallet::DeriveNewChildKey() as private

cd468d0

Add assertion for CanSupportFeature(FEATURE_HD_SPLIT)

1df08d1

Do not break backward compatibility during wallet encryption

9382f04

TheBlueMatt reviewed Mar 27, 2017

View reviewed changes

Fix rebase issue where pwalletMain was used instead of pwallet

4115af7

Ser./Deser. nInternalChainCounter as last element

laanwj merged commit 4115af7 into bitcoin:master Mar 29, 2017

TheBlueMatt mentioned this pull request Mar 29, 2017

Avoid reading the old hd master key during wallet encryption #10115

Merged

NicolasDorier mentioned this pull request Apr 11, 2017

[Wallet] Worst case performance improvement on KeyPool filtering #10184

Closed

ryanofsky mentioned this pull request Jul 14, 2017

[WIP] [wallet] keypool restore #10830

Closed

3 tasks

ryanofsky mentioned this pull request Jan 9, 2018

bumpfee behavior with custom change address #11233

Closed

andronoob mentioned this pull request May 20, 2020

How are change addresses handled by BIP32 tab? iancoleman/bip39#376

Closed

bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021


		UniValue obj(UniValue::VOBJ);

		size_t kpExternalSize = pwalletMain->KeypoolCountExternalKeys();

Use internal HD chain for change outputs (hd split) #9294

Use internal HD chain for change outputs (hd split) #9294

Uh oh!

Conversation

jonasschnelli commented Dec 6, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Main changes

Compatibility:

Uh oh!

laanwj commented Dec 6, 2016

Uh oh!

jonasschnelli commented Dec 6, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gmaxwell commented Dec 10, 2016

Uh oh!

jonasschnelli commented Dec 11, 2016

Uh oh!

jonasschnelli commented Dec 12, 2016

Uh oh!

luke-jr left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

luke-jr Dec 22, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonasschnelli commented Jan 6, 2017

Uh oh!

jonasschnelli commented Jan 9, 2017

Uh oh!

instagibbs left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

jonasschnelli commented Dec 6, 2016 •

edited

Loading

luke-jr Dec 22, 2016 •

edited

Loading