Closed imaginaryusername closed 5 years ago
Technically makes sense since change addresses are really "internal addresses": https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#the-default-wallet-layout
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).
In other words, receiving addresses are reserved for the human operator to assign meaning to; change addresses are for everything else that needs to auto-generate a fresh address.
This should be fixed asap. The code changes should be minimal. =)
Yeah this bugged me too and I was internally suffering about this. Why didn't we do this initially? I dunno.
Yeah it's basically a 1-10 line code change.
I'll get on it today.
@markblundeberg I like how you referred to the spec. It makes 1000% sense now even more. Change is internal. Receiving is human external. So simple. I love it.
Addressed in #95.
It really simplified the code to do this. It's a sign this was a good decision either way.
And it guarantees the "Receive" tab (and other plugins that generate requests or tx's) will "play nice".
Right now a shuffle picks receiving address from the "receiving" path (0') and change from "change" path (1'); this creates many scenarios where a user might mistakenly not click "new" in the receiving tab, and receive dirty coins to a shuffled address, reducing privacy (now) or creating unnecessary shuffle burden (future, when #72 coin control is implemented).
Please change the behavior so both shuffle addresses are picked from the "change" path and never exposed to the receive tab.