Open nuttycom opened 2 months ago
@idky137 let's coordinate on this
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 OutPoint
s 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.
I don't quite understand the benefit of this proposed gRPC method over calling GetTransaction
with the txid provided in the Outpoint
@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.
What is your feature request? Add a GRPC method:
where
GetSpendingTx
returns the transaction that spends the provided output, orNotFound
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.