Are we sure that we want to use Address here instead of the scriptPubKey? I feel like we should shy away from addresses if possible and just use the scriptPubKey. That's what is in the transaction (when it is an output) so it seems most natural to use that and encode it as hex.

Also, sorry for looking at this too late, but we might not be able to use either the scriptPubKey or the "address" because we do not have them (they're never included in the transaction when they're being spent). This scriptSig is not the same as the scriptPubKey from the transaction output, it's basically an unlocking script that, when paired with the actual scriptPubKey, allows you to spend the funds. It's often empty too. For example, all deposit request outputs and all signer UTXOs have empty scriptSigs when spent in a sweep transaction. It's basically only used for legacy scriptPubKeys like P2PKH. I think that the only option is to abandon the endeavor or use bitcoin core for the information.

Also, since a transaction's first input does not necessarily map to a "definitive" source address for the deposit, we may need to make some other changes here too. For example, we might want to check all input scriptPubKeys and using that if they all match. Or maybe map all input scriptPubKeys to the same deposit. All of this is assuming we can get the scriptPubKey at all.

Man this is very appreciated! A very simple alternative would be to add an address_hex field in the create_deposit request itself. I am discussing it with @hozzjss and @setbern

Man this is very appreciated! A very simple alternative would be to add an address_hex field in the create_deposit request itself. I am discussing it with @hozzjss and @setbern

No problem 😄.

One thing to consider is how to verify that information if we include it. I couldn't think of a way without having the input transactions or bitcoin core (or a trusted equivalent).