Address filter

[sanderkruger]

I know this may be out of scope, but I'd like to submit it here as a feature request.

I have a use case where I only want to monitor transfers of a certain set of addresses. Of course this is possible with this project, but because it indexes all transactions, there's a huge database overhead. Would it be possible to add a feature where addresses can be added or removed for monitoring, such that the indexer only stores transactions that are from, to, contract_from or contract_to one of those addresses?

Typically, a user would submit a newly created address for monitoring before using it, but it might still be a good idea to offer the option to rescan (from a certain start date or block). Those familiar with blockchain will see the familiarity with bitcoind's wallet functionality.

[adamant-al]

Hi,

I've got your idea.
Setting an indexer for special set of ETH addresses is possible. Re-scanning is more complex task, but still possible.

These tasks are out of our scope. Still if you'll make a PR with implementation, we'll review them.

[guenoledc]

I have looked into this to see how the rescanning can be done effectively without asking for an initial block for the address.

I tested the following algo and it seems to work but if the address has been first used a long time ago it takes some significant time.

It goes as follows : findFirstBlockAndTransactions(address)

• Get the current block : block

• Get the balance and nonce at ˋblockˋ: ˋbalanceˋ, ˋnonce`

• if balance=0 and nonce=0, then return block and no transaction. This means that the address has not yet been used.

• until balance !=0 and nonce !=0

  • get all transactions in ˋblock`
  • for each transaction in reverse order:
    • if address in [from, to]
      • keep transaction in return list
      • if address = from:
        • balance = balance + value + gasUsed*gasPrice
        • nonce = nonce of the transaction
      • if address = to:
        • balance = balance - value
  • if balance !=0 and nonce !=0: block —

• return {block, keptTransactions}

On Rinkeby it takes 1s fir 10 blocks via infura. It is not so quick.

What’s your views on this?

[adamant-al]

@guenoledc

Hi!

Your solution is definitely good and it's much better then scanning from the beginning.
Another option is to refer to a third-party service like etherscan to get Tx list before current block.

The feature of filtering some addresses, and adding/removing addresses during the online indexer process, with backward-scanning possibility, is a big work. And next request will be to add/remove addresses via API.

Will someone take the task?

[guenoledc]

Hi, @adamant-al

I agree that using etherscan works well. I tested this and its fast and reliable. However, when you need to work for testing and dev on a local node its not available.

Also, I have to confess that not being fluent with Python I have redeveloped entirely the solution in typescript on MongoDB (easier).
Since this is part of a project that may not be open sourced (see below) I don't think I should share the code yet.

If you are interested, my project is based on the idea that many companies who need to interact with bockchains do not want to buy crypto and record for it in their accounting system (risk, compliance, volatility ...). But still they need to have some gas in their wallets. So the project is to build a solution (and a company) that offer the service to automatically refill the customers' wallets with some crypto when the amount is below a threshold and invoice them in euros/usd/any legal ccy for the crypto. The company takes the risk, compliance burden etc for them.

Let me know if you are interested, I would be happy to have some contributors on this.

[adamant-al]

Hi, @guenoledc

I see you have an interesting idea. If you want to speak more about it, contact [email protected]