<p>HD wallets are not special when it comes to transactions. Transactions don't care whether the keys involved were derived deterministically or generated randomly.</p>

<p>Think of a wallet split into two parts: the first part (which we will call the key handler) handles the private/public keypairs and creating digital signatures. The second part (which we will call the transaction handler) handles transaction receiving and transaction creation. Suppose the first part has some functions <code>getnewpubkey</code> (returns a new address) and <code>signdatawithpubkey</code> (receives a public key and some piece of data to sign, returns a digital signature).</p>

<p>So there are two different types of key handlers - ones which randomly generate keys and ones which generate them deterministically (aka HD wallets). These two can be used interchangeable with the transaction handler; the transaction handler does the exact same thing and it doesn't care about how the keys are generated. All it needs is to get keys when it needs them, and for the key handler to sign transactions when the transaction handler asks it to.</p>

<hr>

<p>In your scenario, regardless of whether a HD wallet was used, the transaction handler knows of two transactions that it can spend from. These two transactions were sent to the addresses that correspond to two keys that the transaction handler asked the key handler to provide (i.e. it called <code>getnewpubkey</code> twice).</p>

<p>Now when you want to send, the transaction handler constructs a transaction that has your two received transactions as the inputs. Once it creates the transaction, it sends it to the key handler to sign (so it will call <code>signwithpubkey</code> twice and pass in the same transaction on both calls but one pubkey for the first call and the other pubkey for the second call). Then it takes those signatures and the unsigned transaction, combines them, and produces a final transaction which is then broadcast to the network.</p>

<p>Notice how the transaction handler which actually receives and creates the transaction does not know nor does it care about how the keys were derived. You could have used a key handler that randomly generates keys or one which deterministically generates them; it makes no difference.</p>

<hr>

<blockquote>
  <p>what should be done by the user. Thus, would appreciate it if anyone can explain the above by highlighting some steps in bitcoin-core for example.</p>
</blockquote>

<p>The user does not need to do anything. The user clicks the buttons to get a new address when he wants a new address and clicks the buttons to send Bitcoin when he wants to send. Everything (choosing which transactions to use as inputs, creating the transaction, signing the transaction, etc.) is handled by the software. What the user does with transactions does not change whether the keys were randomly or deterministically generated.</p>

CC BY-SA 3.0
2018-04-06T06:31:45.673Z
very thorough. thank you so much! as a follow-up question (and hopefully the last question before i dig deeper): if we derive a whole bunch of non-hardened `pubkey`s from `xpub`, and give out to other people as a way of receiving funds. When I need to spend out of these addresses, we need to derive the corresponding `privkey`s for them and sign the transactions, which we did not do in the first place, right? by "we", I assume this can be done by the wallet software.
Will Gu
CC BY-SA 3.0
2018-04-06T06:38:13.427Z
It depends on the wallet software. Some software will derive the private keys too and store them. Some software, and ones which support watch only mode with `xpub`s will store the derivation paths. In this type of separated setup, when you create a transaction, the software will give you an unsigned transaction often with some extra data that is not actually part of the transaction itself but is used by the software that does have the `xprv` so that that signer software can sign the transaction and give you something to broadcast to the network.
Ava Chow
CC BY-SA 3.0
2018-04-06T06:51:07.530Z
thanks again. do you have some detailed reading materials or resources in terms of the steps of setting up the `separated paradigm` you described using software API? I understand it replies on the software. I'm mostly interested in open source ones like bitcoin-core, electrum,  armory, etc. So anything based on any of these would be super helpful. I'll do some research too, and will ask another question on SE if i can't find. :)
Will Gu
CC BY-SA 3.0
2018-04-06T06:53:13.730Z
by the way, I'm learning to set up some payment system, and I feel that what you described is exactly what i need. so that's why i'd like to learn code-wise what kind of API functions i can utilize.
Will Gu
CC BY-SA 3.0
2018-04-06T06:23:31.903Z
2018-04-06T06:23:31.903Z
Ava Chow
<p>I found these two questions very helpful in understanding HD wallets</p>

<p>1) <a href="https://bitcoin.stackexchange.com/questions/54660/how-do-hierarchical-deterministic-wallets-work-transaction-wise">How do hierarchical deterministic wallets work transaction-wise?</a></p>

<p>2) <a href="https://bitcoin.stackexchange.com/questions/73376/a-few-questions-about-how-hd-wallet-works">a few questions about how HD wallet works</a></p>

<p>However, I'm still not clear how sending payments would work in the case of HD wallet. Assume the following scenario:</p>

<ul>
<li>derived public key #15 received 1 BTC in one transaction</li>
<li>derived public key #20 received 2 BTC in one transaction</li>
</ul>

<p>Now that I want to send 2.5 BTC to some address, what is the procedure of doing that? Do I need to do two separate transactions?</p>

<p>Also I found it overall confusing in terms of what are taken care of by the wallet (bitcoin-core, etc) and what should be done by the user. Thus, would appreciate it if anyone can explain the above by highlighting some steps in bitcoin-core for example.</p>

<bitcoin-core><bitcoind><bip32-hd-wallets><sending>
Sending payments from an HD wallet
Will Gu
# Sending payments from an HD wallet

(Asked by: username_0 on 2018-04-06)

I found these two questions very helpful in understanding HD wallets

1) [How do hierarchical deterministic wallets work transaction-wise?](https://bitcoin.stackexchange.com/questions/54660/how-do-hierarchical-deterministic-wallets-work-transaction-wise)

2) [a few questions about how HD wallet works](https://bitcoin.stackexchange.com/questions/73376/a-few-questions-about-how-hd-wallet-works)

However, I'm still not clear how sending payments would work in the case of HD wallet. Assume the following scenario:

* derived public key #15 received 1 BTC in one transaction
* derived public key #20 received 2 BTC in one transaction

Now that I want to send 2.5 BTC to some address, what is the procedure of doing that? Do I need to do two separate transactions?

Also I found it overall confusing in terms of what are taken care of by the wallet (bitcoin-core, etc) and what should be done by the user. Thus, would appreciate it if anyone can explain the above by highlighting some steps in bitcoin-core for example.

**Tags:** bitcoin-core, bitcoind, bip32-hd-wallets, sending


---

## 1 answers

### Answer by username_1 on 2018-04-06. Score: 4 | Accepted answer

HD wallets are not special when it comes to transactions. Transactions don't care whether the keys involved were derived deterministically or generated randomly.

Think of a wallet split into two parts: the first part (which we username_0 call the key handler) handles the private/public keypairs and creating digital signatures. The second part (which we username_0 call the transaction handler) handles transaction receiving and transaction creation. Suppose the first part has some functions `getnewpubkey` (returns a new address) and `signdatawithpubkey` (receives a public key and some piece of data to sign, returns a digital signature).

So there are two different types of key handlers - ones which randomly generate keys and ones which generate them deterministically (aka HD wallets). These two can be used interchangeable with the transaction handler; the transaction handler does the exact same thing and it doesn't care about how the keys are generated. All it needs is to get keys when it needs them, and for the key handler to sign transactions when the transaction handler asks it to.

---

In your scenario, regardless of whether a HD wallet was used, the transaction handler knows of two transactions that it can spend from. These two transactions were sent to the addresses that correspond to two keys that the transaction handler asked the key handler to provide (i.e. it called `getnewpubkey` twice).

Now when you want to send, the transaction handler constructs a transaction that has your two received transactions as the inputs. Once it creates the transaction, it sends it to the key handler to sign (so it username_0 call `signwithpubkey` twice and pass in the same transaction on both calls but one pubkey for the first call and the other pubkey for the second call). Then it takes those signatures and the unsigned transaction, combines them, and produces a final transaction which is then broadcast to the network.

Notice how the transaction handler which actually receives and creates the transaction does not know nor does it care about how the keys were derived. You could have used a key handler that randomly generates keys or one which deterministically generates them; it makes no difference.

---

> what should be done by the user. Thus, would appreciate it if anyone can explain the above by highlighting some steps in bitcoin-core for example.

The user does not need to do anything. The user clicks the buttons to get a new address when he wants a new address and clicks the buttons to send Bitcoin when he wants to send. Everything (choosing which transactions to use as inputs, creating the transaction, signing the transaction, etc.) is handled by the software. What the user does with transactions does not change whether the keys were randomly or deterministically generated.

> **Comments:**
> **username_0**: very thorough. thank you so much! as a follow-up question (and hopefully the last question before i dig deeper): if we derive a whole bunch of non-hardened `pubkey`s from `xpub`, and give out to other people as a way of receiving funds. When I need to spend out of these addresses, we need to derive the corresponding `privkey`s for them and sign the transactions, which we did not do in the first place, right? by "we", I assume this can be done by the wallet software.  
> **username_1**: It depends on the wallet software. Some software username_0 derive the private keys too and store them. Some software, and ones which support watch only mode with `xpub`s username_0 store the derivation paths. In this type of separated setup, when you create a transaction, the software username_0 give you an unsigned transaction often with some extra data that is not actually part of the transaction itself but is used by the software that does have the `xprv` so that that signer software can sign the transaction and give you something to broadcast to the network.  
> **username_0**: thanks again. do you have some detailed reading materials or resources in terms of the steps of setting up the `separated paradigm` you described using software API? I understand it replies on the software. I'm mostly interested in open source ones like bitcoin-core, electrum,  armory, etc. So anything based on any of these would be super helpful. I'll do some research too, and username_0 ask another question on SE if i can't find. :)  
> **username_0**: by the way, I'm learning to set up some payment system, and I feel that what you described is exactly what i need. so that's why i'd like to learn code-wise what kind of API functions i can utilize.  

---

