Skip to content

Conversation

@JoeGruffins
Copy link
Member

@JoeGruffins JoeGruffins commented Oct 2, 2025

Adding several apis used with ledger to sign transactions.

@JoeGruffins JoeGruffins force-pushed the addcreateaddr branch 5 times, most recently from d0787a4 to 8be7971 Compare October 7, 2025 06:21
@JoeGruffins
Copy link
Member Author

I plan on adding tests if everything looks alright so far.

dcr/addresses.go Outdated
if isHardened {
n += hdkeychain.HardenedKeyStart
}
extKey, err = extKey.ChildBIP32Std(uint32(n))
Copy link
Member

Choose a reason for hiding this comment

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

this is likely the correct method for ledger compatibility but i believe you will hit compatibility issues with dcrwallet. later in the pr i saw it was looking up known addresses in the wallet, but these would be derived differently than how ledger would be deriving them

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh no. Sounds catastrophic.

Copy link
Member Author

@JoeGruffins JoeGruffins Oct 8, 2025

Choose a reason for hiding this comment

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

Looking closely we are currently only verifying addresses that we get back from the verbose tx decode, and the reason for that is to discern which output is change. This address is never sent to ledger. So, I will change this to the decred way (Child) and leave notes everywhere.

On a related note, is there another way to discern if an output is a change output rather than the address branch or is it fine to keep using that? We check if internal (1) and assume that is change currently.

Ledger wants to know that change path when signing.

Copy link
Member Author

Choose a reason for hiding this comment

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

Add the ability to choose which derivation technique to use.

Copy link
Member

Choose a reason for hiding this comment

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

1/internal is correct for identifying which address is change

is ledger compatible with decred's bip0032 variation?

i suspect the only way to properly fix this and make the two work properly together would be to have an option on dcrwallet to use the standard bip0032 derivation instead of our own silly thing.

Copy link
Member Author

Choose a reason for hiding this comment

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

Currently this method is not used to derive hardened/private keys which have the decred tweak. I don't think there is a problem unless one were to try to restore the trezor wallet using the bip32 tool and dcrwallet.

@JoeGruffins
Copy link
Member Author

Solve a few of the review concerns like the extended key child method https://github.com/decred/libwallet/compare/8be7971885f60602e31b5b6a61ceb6a2774476bb..c762d727b5fc3847e98839886f0e2f2ee71aa4f7

@JoeGruffins
Copy link
Member Author

@JoeGruffins
Copy link
Member Author

Maybe will get more tests in while solving #29 but not in this pr I guess.

@JoeGruffins JoeGruffins merged commit f4d456d into decred:master Oct 15, 2025
2 checks passed
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