<blockquote>
<p>If I derive multiple child/grandchild key pairs from the original master public key, I understand each of these is its own specific address. However, if grandchild key pair 1 contains 1 BTC, and grandchild key pair 2 contains 2 BTC, could I send the 3 BTC total as a single transaction? If so, would this appear on-chain to leave from the child key pair address from which both are derived?</p>
</blockquote>
<p>To answer this, it would be useful to see how a transaction appears on-chain. E.g. <a href="https://www.blockchain.com/explorer/transactions/btc/772a5a048e133c7e0e1ea055976f3e0fbbdd645bc28cc40cbfed65dd6848ad03" rel="nofollow noreferrer">see here</a></p>
<p>In this random example, you can see that the transaction in question has 2 inputs. Each of these inputs comes from a different bitcoin address which may or may not come from the same &quot;wallet&quot; (as a wallet can have more than 1 address - in fact, it is very common, and most individuals will generate a new address to receive every transaction). To fit your example, these could both come from the same HD wallet, with each address representing one of the grandchild key pairs. This demonstrates that 1 transaction can be &quot;sent&quot; from more than 1 address.</p>
<p>Equal to this, you will also see 3 outputs. However, you will see the 3 outputs correspond to only 2 different bitcoin addresses. This is due to the UTXO bitcoin protocol, which you can read about in more detail separately. For our purposes, this shows that an input, or output, does not necessarily correspond to new address. 2 of the outputs go to the intended recipient, a single address likely generated to specifically receive this transaction, while another portion goes to the second address. This is likely (although not certainly) a &quot;change address&quot; and belongs to the original sender (who controls both of the input addresses i.e. has their private keys). Once again, this is due to the UTXO protocol, and you can read why this can occur separately.</p>
<p>To conclude, I think you have confused HD wallets as simply a wallet having more than 1 address (whereas the HD is more about how the private keys are derived/made). In your example, the transaction can leave from more than 1 address (and hence have more than one input), as will appear on-chain. This is nothing to do with HD wallets specifically, as many wallets can have more than 1 address, but it is about how transactions work/appear on-chain.</p>

CC BY-SA 4.0
2024-04-21T13:45:16.590Z
2024-04-21T14:05:50.403Z
2024-04-21T14:05:50.403Z
Epicure
<blockquote>
<p>However, if grandchild key pair 1 contains 1 BTC, and grandchild key pair 2 contains 2 BTC, could I send the 3 BTC total as a single transaction?</p>
</blockquote>
<p>Yes, but not in the way you describe it.</p>
<p>Bitcoin, at the protocol level, does not &quot;belong&quot; to a key. That is, there is no balance per address or per key as a concept.</p>
<p>Instead, think of them as coins. Every time you get paid, you receive a separate new &quot;coin&quot;. Each coin has a little program (the locking script) that determines who is allowed to spend it. In practice, your coins are ones with a locking script that requires a signature with a key you have.</p>
<p>The protocol permits creating transactions that spend multiple coins at once. It does not matter whether those coins all have the same address, or different addresses derived from the same master key, or even if they have completely unrelated addresses entirely. They're just multiple coins, and each coin individually requires a signature.</p>
<p>in fact, nothing prevents multiple people from constructing a single transaction that spends multiple coins owned by different people in the same transaction. This is called a CoinJoin transaction.</p>
<blockquote>
<p>If so, would this appear on-chain to leave from the child key pair address from which both are derived?</p>
</blockquote>
<p>All HD wallets do is change the way an individual wallet derive their keys. Other nodes or parties on the network do not know or care the keys are constructed in a related way. As long as they do not know the master public key, your keys are indistinguishable from random keys. The only thing visible on chain is that the transaction spent coins that were previously sent to distinct addresses, but this is the case for almost all transactions on the network.</p>
<blockquote>
<p>If the master private key was in cold storage, but one of the child private keys was not, could the wallet be defined as a cold wallet?</p>
</blockquote>
<p>This is not possible with non-hardened keys. Given a child private key and the master public key, you can compute the master private key, and from that, all other child private keys.</p>
<p>Thus, you scenario is equivalent to the non-cold system having access to all private keys, and the whole setup is very much not cold.</p>
<p>With hardened keys, knowing the child private key does not reveal the master private key, but you lose the advantage of being able to compute child public keys without access to the master private key.</p>
<p>in either case, I would not call this a cold setup. I would reserve that term for setups where no coins are ever on an online system.</p>

CC BY-SA 4.0
2024-04-21T11:49:03.353Z
2024-04-21T11:49:03.353Z
Pieter Wuille
<p>EDIT - I have refined the question in the post to be more succinct.</p>
<ol>
<li><p>If I derive multiple child/grandchild key pairs from the original master public key, I understand each of these is its own specific address. However, if grandchild key pair 1 contains 1 BTC, and grandchild key pair 2 contains 2 BTC, could I send the 3 BTC total as a single transaction? If so, would this appear on-chain to leave from the child key pair address from which both are derived?</p>
</li>
<li><p>If the master private key was in cold storage, but one of the child private keys was not, could the wallet be defined as a cold wallet?</p>
</li>
</ol>
<p>Thanks</p>

CC BY-SA 4.0
2024-04-19T22:03:53.707Z
Does this answer your question? [How to create off-chain transaction, the one that exchanges uses](https://bitcoin.stackexchange.com/questions/120874/how-to-create-off-chain-transaction-the-one-that-exchanges-uses)
RedGrittyBrick
<bip32-hd-wallets><coldstorage>
How does a HD wallet work in practice?
Latent365
# How does a HD wallet work in practice?

(Asked by: username_0 on 2024-04-19)

EDIT - I have refined the question in the post to be more succinct.

1. If I derive multiple child/grandchild key pairs from the original master public key, I understand each of these is its own specific address. However, if grandchild key pair 1 contains 1 BTC, and grandchild key pair 2 contains 2 BTC, could I send the 3 BTC total as a single transaction? If so, would this appear on-chain to leave from the child key pair address from which both are derived?
2. If the master private key was in cold storage, but one of the child private keys was not, could the wallet be defined as a cold wallet?

Thanks

**Tags:** bip32-hd-wallets, coldstorage

> **Comments:**
> **username_1**: Does this answer your question? [How to create off-chain transaction, the one that exchanges uses](https://bitcoin.stackexchange.com/questions/120874/how-to-create-off-chain-transaction-the-one-that-exchanges-uses)  

---

## 2 answers

### Answer by username_2 on 2024-04-21. Score: 0

> If I derive multiple child/grandchild key pairs from the original master public key, I understand each of these is its own specific address. However, if grandchild key pair 1 contains 1 BTC, and grandchild key pair 2 contains 2 BTC, could I send the 3 BTC total as a single transaction? If so, would this appear on-chain to leave from the child key pair address from which both are derived?

To answer this, it would be useful to see how a transaction appears on-chain. E.g. [see here](https://www.blockchain.com/explorer/transactions/btc/772a5a048e133c7e0e1ea055976f3e0fbbdd645bc28cc40cbfed65dd6848ad03)

In this random example, you can see that the transaction in question has 2 inputs. Each of these inputs comes from a different bitcoin address which may or may not come from the same "wallet" (as a wallet can have more than 1 address - in fact, it is very common, and most individuals will generate a new address to receive every transaction). To fit your example, these could both come from the same HD wallet, with each address representing one of the grandchild key pairs. This demonstrates that 1 transaction can be "sent" from more than 1 address.

Equal to this, you will also see 3 outputs. However, you will see the 3 outputs correspond to only 2 different bitcoin addresses. This is due to the UTXO bitcoin protocol, which you can read about in more detail separately. For our purposes, this shows that an input, or output, does not necessarily correspond to new address. 2 of the outputs go to the intended recipient, a single address likely generated to specifically receive this transaction, while another portion goes to the second address. This is likely (although not certainly) a "change address" and belongs to the original sender (who controls both of the input addresses i.e. has their private keys). Once again, this is due to the UTXO protocol, and you can read why this can occur separately.

To conclude, I think you have confused HD wallets as simply a wallet having more than 1 address (whereas the HD is more about how the private keys are derived/made). In your example, the transaction can leave from more than 1 address (and hence have more than one input), as will appear on-chain. This is nothing to do with HD wallets specifically, as many wallets can have more than 1 address, but it is about how transactions work/appear on-chain.


---

### Answer by username_3 on 2024-04-21. Score: 0

> However, if grandchild key pair 1 contains 1 BTC, and grandchild key pair 2 contains 2 BTC, could I send the 3 BTC total as a single transaction?

Yes, but not in the way you describe it.

Bitcoin, at the protocol level, does not "belong" to a key. That is, there is no balance per address or per key as a concept.

Instead, think of them as coins. Every time you get paid, you receive a separate new "coin". Each coin has a little program (the locking script) that determines who is allowed to spend it. In practice, your coins are ones with a locking script that requires a signature with a key you have.

The protocol permits creating transactions that spend multiple coins at once. It does not matter whether those coins all have the same address, or different addresses derived from the same master key, or even if they have completely unrelated addresses entirely. They're just multiple coins, and each coin individually requires a signature.

in fact, nothing prevents multiple people from constructing a single transaction that spends multiple coins owned by different people in the same transaction. This is called a CoinJoin transaction.

> If so, would this appear on-chain to leave from the child key pair address from which both are derived?

All HD wallets do is change the way an individual wallet derive their keys. Other nodes or parties on the network do not know or care the keys are constructed in a related way. As long as they do not know the master public key, your keys are indistinguishable from random keys. The only thing visible on chain is that the transaction spent coins that were previously sent to distinct addresses, but this is the case for almost all transactions on the network.

> If the master private key was in cold storage, but one of the child private keys was not, could the wallet be defined as a cold wallet?

This is not possible with non-hardened keys. Given a child private key and the master public key, you can compute the master private key, and from that, all other child private keys.

Thus, you scenario is equivalent to the non-cold system having access to all private keys, and the whole setup is very much not cold.

With hardened keys, knowing the child private key does not reveal the master private key, but you lose the advantage of being able to compute child public keys without access to the master private key.

in either case, I would not call this a cold setup. I would reserve that term for setups where no coins are ever on an online system.


---

