Keypath data is a much more reliable way of detecting change outputs.
There are a number of cases where the legacy detection fails, leading to odd results, such as a wallet rescan that results in missed results in listtransactions with self-sends.
Keypath data is a much more reliable way of detecting change outputs.
There are a number of cases where the legacy detection fails, leading to odd results, such as a wallet rescan that results in missed results in listtransactions with self-sends.
I will add listtransaction test soon.
pushed a test that covered a corner case this fixes
I realize the test itself carries a comment describing yet another corner case I've stumbled on that doesn't have any super easy fix. For the purposes of the testing what we care about I just set keypool=2 for a single node near the end of the test, but I could also just have the entire test with this setting, as it changes nothing about the overarching tests in place.
1350 | + CKeyID key_id = GetKeyForDestination(*this, dest); 1351 | + if (!key_id.IsNull()) { 1352 | + auto it = mapKeyMetadata.find(key_id); 1353 | + if (it != mapKeyMetadata.end()) { 1354 | + // Check for path 1355 | + if (it->second.hdKeypath.find("m/0'/1'/") != std::string::npos) {
Not for this PR, but we should probably factor out the static key path strings... maybe add a IsChangeKeypath().
Yes, I think we should be more systematic about our keypath string handling; would make it easier for people like me with various wallet forks and for Core as we move forward with additional derivation features.
utACK 843e07cd5ffb4c9f8d73ef0e2aeed03303122a5b Seems to not create any performance impacts.
I'm afraid this is not sufficient. It's possible to import change keys/addresses using importmulti (see the "internal" field); these aren't identified by having a change-like keypath. Furthermore, this approach will become even less reliable if it's possible to upgrade from pre-hd or pre-hdsplit wallets, as the old keys should remain being treated as change.
You could use being present in a change-like key path as a shortcut still and fall back to the other mechanism otherwise, but I doubt that's very useful.
@sipa actually that suggestion is just fine for my needs, even if you aren't too excited about it.
oh hmm, I see why now. I'll just carry it downstream for now.