It would be great to have the L3 wallet generate change addresses so the user doesn't have to manually pick one or spend the whole UTXO.
I got it working on a branch of Ben Westgate's yeti.Bash: https://github.com/a5an0/yeti.Bash/blob/change-addresses/CreateWallet.sh#L113. I needed to add another level to the (implicit) derivation path on each xpub (the end of each xpub is now /0/* and /1/* for change instead of /*, and then when importing the descriptor into an empty wallet, you put two in a json list and mark the change descriptor as internal: true. I also update the descriptor to do sortedmulti to just avoid any order issues in the future.
I think this would be a good change, but would make the code for (for example) the descriptor import step a bit more complex: you'd want to support both change-enabled and not-change-enabled wallets so we don't break existing wallets. One of the killer features of yeticold is how simple and easy-to-audit the code is, so there's some risk in adding a bunch of logic to handle both cases.
If this upgrade is something you're interested in, I can try to get some patches together. If you think the increase in complexity is not worth it for change addresses, I won't bother.
a5an0
commented
2 years ago
It would be great to have the L3 wallet generate change addresses so the user doesn't have to manually pick one or spend the whole UTXO.
I got it working on a branch of Ben Westgate's yeti.Bash: https://github.com/a5an0/yeti.Bash/blob/change-addresses/CreateWallet.sh#L113. I needed to add another level to the (implicit) derivation path on each xpub (the end of each xpub is now
/0/*and/1/*for change instead of/*, and then when importing the descriptor into an empty wallet, you put two in a json list and mark the change descriptor asinternal: true. I also update the descriptor to do sortedmulti to just avoid any order issues in the future.I think this would be a good change, but would make the code for (for example) the descriptor import step a bit more complex: you'd want to support both change-enabled and not-change-enabled wallets so we don't break existing wallets. One of the killer features of yeticold is how simple and easy-to-audit the code is, so there's some risk in adding a bunch of logic to handle both cases.
If this upgrade is something you're interested in, I can try to get some patches together. If you think the increase in complexity is not worth it for change addresses, I won't bother.