Bitcoin Address Workflow on Spend Leftovers

I need to understand the correct Bitcoin address workflow for transactions. I created an address a while back with a common wallet and sent some coin there. The address is at segwit m/49'/0'/0'/0/0. I then spent some coin from that. When I looked up the address on the blockchain, I noticed that the balance was 0. The transaction that occurred had two output addresses. The funds were sent to two addresses. The second is the non-segwit address of the person of who I sent the funds to. The first was segwit m/49'/0'/0'/1/0 (address from my wallet). It appears that the wallet moved my funds to a new address in my wallet. I.e. m/49'/0'/0'/0/0 -> m/49'/0'/0'/1/0.

Should a wallet always move the left over from m/49'/0'/0'/0/x to m/49'/0'/0'/x/0? Is this logic standard practice? Or is this specific to the wallet I used? Is there a recommended practice? I need to know because I am developing a wallet, and I need to follow standard practice.

What should happen when I transfer the funds from m/49'/0'/0'/x/0 to another address, and there are leftovers? Where should the new address for the leftovers be moved to? m/49'/0'/x'/0/0?

It appears that the wallet moved my funds to a new address in my wallet.

That is normal and desirable behavior. See How does change work in a bitcoin transaction?

Should a wallet always move the left over from m/49'/0'/0'/0/x to m/49'/0'/0'/x/0?

This wallet is using BIP 49, which extends the hierarchical wallet organization described in BIP 44. General standards for hierarchical deterministic wallets are described in BIP 32. You'll want to read these carefully if you are implementing your own wallet.

Under BIP 44, the fourth level of the derivation path is to be 0 for "external" keypairs (those presented to the user as a receive address which she may send to a payer), and 1 for "internal" keypairs (to be used as change addresses).

Constant 0 is used for external chain and constant 1 for internal chain (also known as change addresses). External chain is used for addresses that are meant to be visible outside of the wallet (e.g. for receiving payments). Internal chain is used for addresses which are not meant to be visible outside of the wallet and is used for return transaction change.

BIP 32 specifies something similar:

Each account is composed of two keypair chains: an internal and an external one. The external keychain is used to generate new public addresses, while the internal keychain is used for all other operations (change addresses, generation addresses, ..., anything that doesn't need to be communicated). Clients that do not support separate keychains for these should use the external one for everything.

So it is in keeping with this standard that an external keychain address .../0/x was used to receive your coins initially, while the internal keychain address .../1/y was used for the change from your outgoing transaction. (It's just a coincidence that x and y were both 0 in this case; it would normally just be the next unused value on each chain, but since you hadn't done anything else with the wallet, you got the first keypair on each chain.)

• Thanks. I'll have a read through this and check to see if it answers my questions completely. Commented Jan 8, 2018 at 0:03
• It seems that the spec covers a lot of the cases, but not necessarily all cases. It seems that there are some cases that the spec does not dictate best practice. And, aside from that, a wallet app is able to do whatever it wants really. It could transact funds in to wherever it wants. This seems like a general problem, but it's hard to say whether this will cause issues down the line or not. I can only try to follow the spec the best I can. Commented Jan 8, 2018 at 0:12
• I think this is mostly correct, but the wallet implements BIP0044, and BIP0049 so BIP0032 doesn't seem to be enough to answer the full question at this point. Commented Jan 8, 2018 at 2:32
• Ah, yes, that's a better reference in this case. Thanks. Commented Jan 8, 2018 at 2:38
• , if you modify your answer, I will mark it as the answer. Commented Jan 8, 2018 at 3:02