How to get the history transactions of subaddresses?

Hi, mobilecoin community.

I’m building a simple MobileCoin wallet that interacting with mobilecoind via gRPC. I want to show all transactions related to user’s subaddresses (sent or received). But I couldn’t find an API to fetch the transactions of a subaddress.

In Bitcoin, I can use get_block and get_transaction to download all TXs in a block, then filter them. It is not very efficient, a better way is to send the raw TX and the Merkel proof(if the tx already be mined) directly to the receiver. But it’s not a big problem when the block size is small.

Does the MobileCoin transaction has txid or something similar to identify a transaction?

Cheers.

And is the “confirmation” a important thing to mobilecoin, will chain fork? If so, how many confirmations should I wait until the fund is safe?

Oh, I saw the document says we use the “key image” as an ID of TXOs.

Each transaction output (" txo ") has a unique corresponding construction called a key image .

How to find the key images of the TXOs which belong to my subaddresses in a block?

This block contains 3 TXOs, but only 1 key image, why?

In Bitcoin a transaction consists of one transaction input (the UTXO you want to spend) and one (or more) transaction outputs (the new UTXO your recipient can spend). Technically there’s 3 most of the time: the UTXO for your recipient to spend, the UTXO that is your change that you can spend, and the transaction fee UTXO.

MobileCoin transactions all have 3 UTXOs: the coins you transferred to your recipient, your change, and the transaction fee.

The key image is actually just to prevent doublespends AND it’s hard to tell which key image is associated to what input UTXO since MobileCoin does not reveal the inputs to any transaction. You can learn more here: https://www.youtube.com/watch?v=e9afDQ_M5CU (the content starts like 6 minutes in).

Cheers,
Joshua

1 Like

MobileCoin forks are a little different. MobileCoin will fork if the consensus nodes you are listening to choose to diverge from the majority of the network. This shouldn’t happen unless the owner of a node decides to diverge by changing their quorum set. This is a little deeper into the game theory of running federated byzantine consensus. I’d ask this question during our MobileCoin Consensus Protocol (MCP) discussion.

Cheers,
Joshua

2 Likes

Thank you for your patience with detailed answers, I got it. :clap: :clap: :clap:

2 Likes

Hey @Satoshi, regarding the API to get all transactions for a subaddress, you can look at the mobilecoind API proto spec. Our terminology is that you add a “monitor” for an account key and a subaddress range, and then you use that monitor to query for transactions that belong to subaddresses of that account. For example, you would send a “GetUnspentTxOutRequest” for a specific monitor and subaddress.

You can see some examples of a python client that uses this API in the python mob_client, and a simple wallet example using this in the Wallet notebook.

Similarly, for a java example, you can look at the getBalance implementation.

Hope this helps - excited to see your work on a wallet!

1 Like

Cool! Let me take it a step further on how MobileCoin is different from other networks. So one of the problems that networks have is that they don’t have this concept of enforced software state. You’ll see this play out every time the network needs to do an upgrade (do you remember the New York agreement?).

What’s different about MobileCoin is that all of the machines in the consensus network use a technology called Remote Attestation that enforces a specific software version. If you don’t have the exact right software, you can’t connect to the network to validate transactions. The practical effect is that bugs get patched network wide all at once, which is really cool :).

Because every machine is running the exact same software, the only way to fork is not to have a bug in software but to intentionally configure your quorum set to be a different group than the majority of the network. In this way, forks should be rare.

Does that help?

Cheers,
Joshua

1 Like

Thank you @drakeley . So I need to call the GetUnspentTXOut API every few minutes to get the latest TxOuts. But this API will always respond with the all TxOuts of a subaddress. Is there a way to get the TxOuts after a certain block height? Or we have to diff the new TxOuts set with old set every time to find out the change?

Great. It’s an improvement to privacy. Now I understand that key image stands for the txo I spent, not the new UTXOs.

The problem I met is the get_block API does not return the decrypted information even I have monitored many subaddresses. As a user, I don’t care about the block content which I can’t decrypt. Could we add an option to get_block which makes it only return the decrypted data (transactions related to the addresses being monitored)?

Thank you!