zcash / lightwalletd

Lightwalletd is a backend service that provides a bandwidth-efficient interface to the Zcash blockchain
MIT License
83 stars 86 forks source link

Add the ability to query for the transaction that spends a specified transparent outpoint. #498

Open nuttycom opened 2 months ago

nuttycom commented 2 months ago

What is your feature request? Add a GRPC method:

message OutPoint {
    bytes txid = 1;           // transaction identifier
    uint32 output_index = 2;  // index of the output in the transactions `vout` array
}

rpc GetSpendingTx(OutPoint) returns (RawTransaction) {}

where GetSpendingTx returns the transaction that spends the provided output, or NotFound if the outpoint is not recognized or the outpoint is unspent.

How would this feature help you? In restoring transparent history, it is possible to traverse the transaction graph from spending tx to source of funds using available methods of the GRPC interface, but there is no direct way to find the transaction that spends a given output. As a consequence, it's currently necessary to use the GetTaddressTxids method to attempt to find spends related to a given outpoint, but this is highly imprecise - it will return all of the transactions that involve that address, and queries to this method must specify a block range to query. In highly active wallets, this could result in numerous calls that each return hundreds or thousands of results, rather than just the one result that is wanted.

Adding this RPC method will make it possible to fully restore a wallet's transparent transaction graph in an efficient manner.

zancas commented 2 months ago

@idky137 let's coordinate on this

nuttycom commented 2 months ago

Instead of OutPoint, this method could take a sum type that is OutPoint | SaplingNullifier | OrchardNullifier. This API leaks the same amount of information to the lightwalletd server as does GetTransaction (though, in the case of investigating transparent OutPoints it's possible that a client may be tracing the history of someone else's transactions).

The indexer should be considered to provide all the functionality that might be desired of it in a trusted context - i.e. it should provide all the functionality that could be desired of it if the end user of a wallet is also running their own indexer, such as is the case for an exchange wallet. Then, subsets of that functionality may remain unused or disabled (or only accessible via TOR/Nym?) if it's running in an untrusted context such as as lightwalletd server.

Oscar-Pepper commented 2 months ago

I don't quite understand the benefit of this proposed gRPC method over calling GetTransaction with the txid provided in the Outpoint

nuttycom commented 2 months ago

@Oscar-Pepper You're misunderstanding it then. The txid component of an OutPoint returns the transaction in which an output was created. What we want is, given an OutPoint, determine the transaction (if any) in which that output is spent.

When we discover a transaction where one of its outputs belongs to us, we then want to also find out if that output is already spent, and if so, where.

This requires a separate index that is constructed by inspecting each transaction, and recording a mapping between each OutPoint in its vin array and the txid of the transaction being inspected.