Add options to inscribe straight to an address, and/or send commit change to an address

[rot13maxi]

if you want to make sure that the change from the commit transaction goes to a specific address, you can now provide the --commit-change option. Note that if a specific satpoint is being inscribed, we might need two change addresses because the UTXO might need splitting, so passing both the --satpoint option and the --commit-change option will throw an error.

Also, now you can set the --inscription_destination option to set the reveal transaction output to a specific address.

I thought making the change field that gets passed around an enum was the best way to encapsulate the optionality. Happy for feedback on if there's a different way we want to model this.

[casey]

if you want to make sure that the change from the commit transaction goes to a specific address, you can now provide the --commit-change option.

What's the use case for a separate commit change address? If its a desire to control the destination of all change addresses, then we could make it just a --change flag, the user could pass it as many times as they wanted, and we would would initialize the transaction builder with either the default of two change addresses from the wallet, or the change addresses that that had been passed on the command line. This would be a pretty easy change to make and might fit in better with the existing code.

Note that if a specific satpoint is being inscribed, we might need two change addresses because the UTXO might need splitting, so passing both the --satpoint option and the --commit-change option will throw an error.

I kind of don't like adding this specific error case, which would then need a test. See my above comment for how we might avoid this.

Also, now you can set the --inscription_destination option to set the reveal transaction output to a specific address.

This is a great change and I'd like to get this in soon, since users have been asking for it and I clearly understand the use-case. Would you mind splitting that out into its own PR?

I thought making the change field that gets passed around an enum was the best way to encapsulate the optionality. Happy for feedback on if there's a different way we want to model this.

Unless I'm mistaken about the purpose of commit-change, we might be able to reuse TransactionBuilder::{change_addresses, unused_change_addresses} and avoid an extra field.

[casey]

I hate the red angry "changes requested flag", but this lets me see what's currently blocked on someone else at a glance. They should really make it blue or something T_T

[casey]

Also, just looked at the code more carefully, I see you're already reusing the change address fields, but we could make it a vec, to make the code more general.

[rot13maxi]

Ill go ahead and split out the inscription address change. I was able to obviate my usecase for specific change addresses over the weekend, so i might shelve that until someone else needs it.

…

On Mon, Feb 6, 2023 at 6:02 PM, Casey Rodarmor ***@***.***> wrote: Also, just looked at the code more carefully, I see you're already reusing the change address fields, but we could make it a vec, to make the code more general. — Reply to this email directly, [view it on GitHub](https://github.com/casey/ord/pull/1512#issuecomment-1419904889), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/A3UR6LW2SKAEZ64TQVIRKIDWWF7G7ANCNFSM6AAAAAAUR5PF3E). You are receiving this because you authored the thread.Message ID: ***@***.***>

[rot13maxi]

closing in favor of #1536