While testing the CPFP feature, I realized that the default destination is the next unused change address.
However it's important that pending transactions are also taken into account when finding the next unused change address. Many CPFP child transactions are spending the change output from the parent transaction.
In my parent transaction my change was going to address ending in "navvf". However the "navvf" address is also where the child transaction would send the bitcoin by default. The problem with this is that the child transaction spends out of "navvf", publishing the locking script publicly. Therefore the result would be the bitcoin balance sitting in an address that had been previously spent from, against best practices.
Instead, the default address should be the next unused change address that also has no pending transations, in this case not /1/0, but /1/1, the address ending in "c8k37"
While testing the CPFP feature, I realized that the default destination is the next unused change address.
However it's important that pending transactions are also taken into account when finding the next unused change address. Many CPFP child transactions are spending the change output from the parent transaction.
In my parent transaction my change was going to address ending in "navvf". However the "navvf" address is also where the child transaction would send the bitcoin by default. The problem with this is that the child transaction spends out of "navvf", publishing the locking script publicly. Therefore the result would be the bitcoin balance sitting in an address that had been previously spent from, against best practices.
Instead, the default address should be the next unused change address that also has no pending transations, in this case not /1/0, but /1/1, the address ending in "c8k37"