Page MenuHomePhabricator

T1920 - fix excessive API Calls on Tx History Fetching
ClosedPublic

Authored by hungsam on Dec 2 2021, 23:56.

Details

Reviewers
bytesofman
Group Reviewers
Restricted Project
Commits
rABC205de92b29e9: T1920 - fix excessive API Calls on Tx History Fetching
Summary

Currently, to determine if a transaction is incoming or outgoing, the wallet

  • Retrieves the transaction data by calling BCH.RawTransactions.getTxData(txid)
  • Looks through the returned transaction data’s “vin” to see if it contains the address of the current wallet
  • If it does, the transaction is outgoing
  • Else, the transaction is incoming

There is a performance problem with BCH.RawTransactions.getTxData(txid).
It populates the address property of each “vin” by making a separate api call
to retrieve the data of the transaction that generates this input.
If a transaction has hundreds of inputs,
retrieving the data for that transaction will generate hundreds of api calls instead of just one.

This problem can be solved by calling BCH.RawTransaction.getRawTransaction(txid,true),
instead of BCH.RawTransaction.getTxData().

getRawTransaction() only makes one api call, however,
the returned data does not contain a wallet address in the “vin”.
We will not be able to determine if a transaction is incoming or outgoing
by comparing the vin’s address with the current wallet address.
Instead, we have the extract the public key in the scriptSig of each "vin",
and compare it with the public key of this wallet.
If they are the same, the transaction is outgoing.

publicKey was added to the Wallet State on D10550

Test Plan

On master branch

  • Npm start
  • Make sure you have 2 wallets with some XECs
  • Send some XECs from one wallet to another
  • Inspect the network traffic
  • Activate the receiving wallet
  • Confirm that the wallet retrieved more than 5 TXs
  • Note which Tx is marked as Sent / Received

On this diff

  • Repeat the steps as with master branch
  • Inspect the network traffic
  • Confirm that the wallet retrieved exactly 5 TXs
  • Confirm that the TXs are marked correctly as Sent / Receive
  • Better to load the same wallets on a phone and compare the Tx History

Diff Detail

Repository
rABC Bitcoin ABC
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

hungsam requested review of this revision.Dec 2 2021, 23:56
bytesofman requested changes to this revision.Dec 3 2021, 22:51

Please rebase to latest master so we can see what needs to be changed in the replyAddress feature from D10611

web/cashtab/src/utils/cashMethods.js
297 ↗(On Diff #31243)

Won't want this console.log in production

This revision now requires changes to proceed.Dec 3 2021, 22:51

rebase to the latest master and update replyAddress feature implementation

bytesofman requested changes to this revision.Dec 8 2021, 14:51
bytesofman added inline comments.
web/cashtab/src/utils/cashMethods.js
295 ↗(On Diff #31312)

Please include mocks & write unit tests that confirm the comments below

This revision now requires changes to proceed.Dec 8 2021, 14:51

found a way to classify the scriptSig,
hence updated the diff to parse the tx data based on the type of scriptSig

bytesofman requested changes to this revision.Dec 9 2021, 15:29
bytesofman added inline comments.
web/cashtab/src/hooks/useBCH.js
139 ↗(On Diff #31334)

Put this logic into a try{} catch (err) {} block. If it gets to the catch block, assume it's an incoming tx.

Not sure how often BCH.Script.classifyInput will throw an error, but we don't want it to crash the entire app if and when it happens.

const thisInputScriptSig = tx.vin[j].scriptSig; through if (inputType === 'pubkeyhash') {} should be in the try {} block

This revision now requires changes to proceed.Dec 9 2021, 15:29

put the scriptSig classifying logic in a try catch block

hungsam marked an inline comment as done.Dec 9 2021, 19:39
This revision is now accepted and ready to land.Dec 13 2021, 19:47