Enhancement: an API to get all details, including input addresses, for a set of transparent transactions.

[gmale]

Enhancement Story

As a wallet developer, I'd like to fetch transparent transactions from Lightwalletd along with all the related details for that transaction (in particular the addresses associated with the inputs, which requires additional context and lookups from the insight explorer. outputs don't have that problem.) so that I can display these relevant details to the user, when they inspect their transaction details.

In other words:
Given a single transaction, give me as much available info about it as possible, within reason. Particularly with the tx inputs.

Details

In a transparent transaction, each input does not contain enough information about where it originated. All you see is pointers to where the money came from. Getting the relevant details requires an additional lookup. You have to look up the UTXOs that were used when the transaction was created. The UTXO map is, essentially, a backwards map that can serve as a lookup for address info. We want to show that address info to the user, when they inspect their transactions that have transparent components.

Criteria

For a given transaction, a developer interacting with lightwalletd can:

• receive all details about the transaction inputs that an average user would care to see (currently missing)
• receive all details about the transaction outputs that an average user would care to see (currently available)
• ideally, not have to make individual server requests for each transaction
  • i.e. can request over a block range for a given address
• receive typed objects rather than raw binary
• can include commitments that can later be added to flyclient trees
  • currently, the root is available but we can add other roots in the future
  • eventually, this commitment can be used to verify the information returned by lightwalletd

[LarryRuane]

I'm curious why you labeled this "enhancement" -- isn't this required for t-addr support?

Here's a proposal:

The GetBlock() and GetBlockRange() functions return compact blocks, which currently include only transactions that have at least one shielded input or at least one shielded output. (That is, purely t-to-t transactions aren't included). Would it make sense to modify those (or write new versions to preserve backward compatibility) to also return t-to-t transactions? In other words, return compact representations of all transactions in the block?

And if we did that, perhaps we'd want the compact form of the t-to-t transactions to be, in a way, less compact than what you get from the zcashd getrawtransaction rpc, because the transparent inputs would be not just the source TXO (txid and index), but the address and amount as well (or maybe that's all they'd be). That is, the lwd could look those up for you, so you wouldn't have to do that yourself, saving you having to call GetTransaction gRPC for each of these inputs. In other words, "all the details" as you put it in your comment above. (Yes, this will require that lightwalletd make more rpcs to zcashd, but those are extremely fast since they're local.)

These "compact" transactions would still be in some ways more compact than what zcashd getrawtransaction returns (even though they'd be less compact in other ways) because they would contain only exactly what you need, nothing else. An example would be what I mentioned, maybe an input is only the address and amount. Whatever you need.

[gmale]

I'm curious why you labeled this "enhancement" -- isn't this required for t-addr support?

I've been using "enhancement" interchangeably with "feature" for anything that's not a "bug" because that tag is present on most repos by default (whereas "feature" something else more fitting, isn't). From there, I loosely have been using that tag to track the "non-bug" issues that I've added in various repos that need to be discussed and vetted.