Skip to content

Hash each address preimage once and reuse the address-hash map - #784

Open
151henry151 wants to merge 1 commit into
goatpig:0.97_rc2from
151henry151:hash160-fetch-speed
Open

Hash each address preimage once and reuse the address-hash map#784
151henry151 wants to merge 1 commit into
goatpig:0.97_rc2from
151henry151:hash160-fetch-speed

Conversation

@151henry151

Copy link
Copy Markdown

Hash160 for used addresses was computed during walletToCapnp and again when building the BDV address map. AddressEntry::getHash also hashed each preimage twice.

Reuse the account address-hash map when building the used-address map, and hash each preimage once.

Tested with:
./gtest/WalletTests --gtest_filter=WalletsTest.UsedAddressMapReusesHashMap:WalletsTest.WalletDisplayNames — passed

Drop dual Hash160/SHA256 in AddressEntry::getHash and seed used
AddressEntry objects from the warmed account hash map.
@goatpig

goatpig commented Aug 24, 2026

Copy link
Copy Markdown
Owner

Hey, sorry about the delay. Having a horrible 2 weeks at work, I'll get to breathe a bit this weekend. I'll have time to review then. Thanks for your patience.

@151henry151

151henry151 commented Aug 24, 2026

Copy link
Copy Markdown
Author

Hey, sorry about the delay...

All good, I'm a plumber full time, I get it. :)

@goatpig

goatpig commented Sep 3, 2026

Copy link
Copy Markdown
Owner

Your changeset removes the double computation when generating hashes. This is actually a feature. Paying to a mangled hash (or an address constructed from such hash) would black hole the coins. The additional cost is negligible.

Your solution also pulls the hash from an AddressEntry object to then re-inject it into another AddressEntry object, introducing a method to the class to populate it with blind data.

In this state, I cannot accept the PR. A better, middle ground solution would be to carry the whole AddressEntry object generated by AssetAccount::updateAddressHashMap in AssetAccountData instead of just the hashes. This would breach the semantic separation between AddressAccount and AssetAccount, but it is much cleaner in term of asset data handling.

Finally, a "perfect" solution, which would avoid the breach and mixing of duties, is to retire the address hash map from AssetAccountData and carry address entries sorted by "<account, assetid, address type>" in AddressAccount instead.

getAddressHashMap / BDV registration.
***/

const_cast<AddressAccount*>(this)->updateAddressHashMap();

@goatpig goatpig Sep 3, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

AddressAccount isn't virtual, you can call updateAddressHashMap directly

It is fine to make getUserAddressMap non const.

return type_;
}

void AddressEntry::setCachedPrefixedHash(BinaryData prefixed)

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

Don't add methods that allow injecting blind data into assets and/or addresses.

@151henry151

Copy link
Copy Markdown
Author

Thanks for the review; this weekend I'm traveling to play music at a family event, and then I'll have a busy week when I get back home -- but the following week, I'll have time to properly address the feedback.

@goatpig

goatpig commented Sep 5, 2026

Copy link
Copy Markdown
Owner

Sounds good. I still have to get RC2 to build on Windows so you should have time. Thanks for the effort, much apperciated!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants