Topic: HD wallets and change addresses (Read 226 times)
The wallet part mentioned by you is absolutely correct. I have been going through Github repos of many HD wallets such as Trust, Electrum, Atomic, etc and also created some testnet wallets on them too. I was just confused as to how they manage and sign the txs on the runtime. The codes are too complex and I can understand the overall picture but struggle to code such thing. Your explanations made things clear and I am now hoping to go forward with this info
Suppose I receive 1 btc to m/x'/y'/z'/0/0. Now I send 0.2 btc to someone else. So I will now have 0.8 btc in m/x'/y'/z'/1/0. Then I again recive 1 btc which will go to m/x'/y'/z'/0/1. Now suppose I want to spend all my btc. So do I have to sign txs using the PKs of both m/x'/y'/z'/1/0 and m/x'/y'/z'/0/1?
That is correct.
To see this in action you can always create a new wallet using a wallet software that has these options already and see how they work (or take the harder route and check the source code of such wallet). For example Electrum supports these options and also can be run on TestNet. You can play around there with no cost and see how things work.
- All addresses are exactly equal. The wallet (internally) categorize them for convenience.
Usually user chooses an address amount "receiving addresses" for example at m/x'/y'/z'/0/0 and receives some coins in the corresponding address. Then moves to next address m/x'/y'/z'/0/1 to receive again, and so on.
Thank you for the clarification, I can not understand well how the things are working
- When the user wants to spend they spend the same coins using the same key (m/x'/y'/z'/0/0 and m/x'/y'/z'/0/1) but they send all the leftover to an address created by a new key like m/x'/y'/z'/1/0 then next spend's remainder goes to the address created from key at m/x'/y'/z'/1/1 and so on.
Suppose I receive 1 btc to m/x'/y'/z'/0/0. Now I send 0.2 btc to someone else. So I will now have 0.8 btc in m/x'/y'/z'/1/0. Then I again recive 1 btc which will go to m/x'/y'/z'/0/1. Now suppose I want to spend all my btc. So do I have to sign txs using the PKs of both m/x'/y'/z'/1/0 and m/x'/y'/z'/0/1?
Thank you for the help
So to spend those amounts in change address, do I have to sign the txs using the PK of m/x'/y'/z'/1 or m/x'/y'/z'/0?
Keys being derived deterministically doesn't change the basics of how bitcoin works. If a certain key receives some coins the same key has to be used to spend those coin, doesn't matter how you created that key.If so, are m/x'/y'/z'/0 addresses just for receiving and m/x'/y'/z'/1 addresses just for sending?
Thank you for the help
All addresses are exactly equal. The wallet (internally) categorize them for convenience. Thank you for the help
Usually user chooses an address amount "receiving addresses" for example at m/x'/y'/z'/0/0 and receives some coins in the corresponding address. Then moves to next address m/x'/y'/z'/0/1 to receive again, and so on.
When the user wants to spend they spend the same coins using the same key (m/x'/y'/z'/0/0 and m/x'/y'/z'/0/1) but they send all the leftover to an address created by a new key like m/x'/y'/z'/1/0 then next spend's remainder goes to the address created from key at m/x'/y'/z'/1/1 and so on.
So to spend those amounts in change address, do I have to sign the txs using the PK of m/x'/y'/z'/1 or m/x'/y'/z'/0?
If so, are m/x'/y'/z'/0 addresses just for receiving and m/x'/y'/z'/1 addresses just for sending?
Thank you for the help
If so, are m/x'/y'/z'/0 addresses just for receiving and m/x'/y'/z'/1 addresses just for sending?
Thank you for the help
Change addresses aren't "special" addresses, they are simply a set of key pairs that are generated to be used as a change address. In an HD wallet since all keys are derived with a "path" you can decide to choose an slightly different path for the change addresses to get different (separate) keys. Usually only the last number in the path is changed.
For instance BIP-44 proposes usage of a 4 number system like this:
Knowing the path, the wallet keeps track of change addresses the same way it keeps track of any other address.
As for sending, a decent wallet has to have the option to allow the user to select "coins" (ie. unspent transaction outputs) at the same time be able to perform coin selection based on privacy settings chosen by the user.
ref: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#path-levels
For instance BIP-44 proposes usage of a 4 number system like this:
Code:
m / purpose' / coin_type' / account' / change / address_index
so if your main path is m/x'/y'/z'/0 then your change path is m/x'/y'/z'/1.Knowing the path, the wallet keeps track of change addresses the same way it keeps track of any other address.
As for sending, a decent wallet has to have the option to allow the user to select "coins" (ie. unspent transaction outputs) at the same time be able to perform coin selection based on privacy settings chosen by the user.
ref: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#path-levels
I am reading all theory of how HD wallets generate change addresses after a tx but have never seen how to programmatically work with it. I am currently working to genarate a POC of HD wallet which supports a change address feature. I have ideas how this all work but have no idea how to start programmatically.
I have some questions which I was hoping I can get resolved
I know how to generate a change address, but how will I keep track of what account is using which change address?
If the user wants to send some btcs to someone else, then would it from chnage address or do I have to generate a new address to spent that?
Any help is appreciated. Let me know if I can add some more details if necessary
I have some questions which I was hoping I can get resolved
I know how to generate a change address, but how will I keep track of what account is using which change address?
If the user wants to send some btcs to someone else, then would it from chnage address or do I have to generate a new address to spent that?
Any help is appreciated. Let me know if I can add some more details if necessary
Jump to: