methode to list all transactions of an account ?

[lbrth]

Somebody knows if there is actually a way to easily listed all transactions of an account/address or if this method is in work in progress ?

like: web3.eth.getTransactionList(address)

Thanks !

output : all transactions hash for web3.eth.account[x]

[danuker]

I ran into this problem myself today, sadly there is not such a method.

This can be done by going through the blockchain yourself and recording the transactions pertaining to your address.

You can do this with the Geth wallet as follows:

• for checking past transactions: transactions of an address - example code please ethereum/go-ethereum#2104 (comment)

• for when you're waiting for future transactions: eth_listTransactions ethereum/go-ethereum#1897 (comment)

[CoderXpert]

I am looking into this and still looks like there is no API for this.
@danuker did you implement this by traversing all blocks and all transaction in the block?
If yes how much time it's taking? And that must be a server-side solution, right? Fetching all blocks on clients will be slower and not scalable I think.

[fredzhu]

@danuker I tested the code to checking past transactions, but it cost me 100 seconds to find out an address even with only 1 block. It's too slow, slower than new block appears, so it's impossible to check all blocks...... @CoderXpert

for(var i = 4905820; i < 4905822; i++) {
var Block=web3.eth.getBlock(i);
console.log("blocknumuer: " + i);
if (Block.transactions!=null && Block!=null)
{
Block.transactions.forEach(function (e)
{
var getT=web3.eth.getTransaction(e);
var Tdata=web3.toAscii(getT.input);
if(getT.to=="needed Address")
{
console.log("find");
}
//console.log(getT.to);
});
}

[tjayrush]

@fredzhu it’s not impossible, just slow unless you do clever things. QuickBlocks does all of those clever things. Check it out.

[outdoteth]

Is there a particular reason as to why is this not in the API?

[AyushyaChitransh]

@Dylan-Phoon There is no implementation for this API in any ethereum client.

[tjayrush]

To add an API, the node itself would have to keep an indexed list of transactions per account. This would increase the data requirements on the node, which are already very onerous, dramatically. The index would have to be maintained at each block, which means either inserting items into the index or sorting the index at each block. As the chain grows this would overwhelm the node and make decentralization more and more difficult. Because the blockchain is basically an append-only log, the node simply has to append data to the end of the database which is much less resource intensive. At least that's my guess. I'm not a core developer.

[danuker]

@tjayrush The necessity of an index shouldn't prevent this feature from being included in a client, just disabled by default. You could have an option --index-transactions=true or somesuch.

However, the problem is one of incentives; the client devs think this feature request has a lower priority for their project, compared to other features (i.e. client scalability and performance). I think it's a courtesy that they left this ticket open (they might consider it further in the future). See the last comment here.

Thank you for your referral to QuickBlocks!!! It is just what I am looking for in the near future.

@CoderXpert What I proposed is painfully slow, and is not really worth implementing. In December when I tested it took about 10 minutes to go through an hour of the blockchain, on my SSD laptop. And unless you only check a fixed set of addresses, or a very short timeframe, you'll have to go through the blockchain from scratch again.

The only way to make the lookup faster (for random addresses) is to build an index for ALL transactions. I recommend that you use QuickBlocks which @tjayrush posted, and it does just that!

[CoderXpert]

@danuker Thanks for replying. Yeah I also did test around the proposal and it was too slow. Now I am working on creating an index of all transactions and create a db so I can query with different addresses and also different time periods.

Thanks for mentioning QuickBlocks, I will have a look :)

[calldata]

I think if we can make bloom filters cache the from and to addresses for every block (or a batch of blocks) . When we want to get all the transaction history of a specific account, we only care about those that bloom filters says '' Yes, these blocks may include transaction for this account", ignoring those says "NO, these blocks never contain this account". Due to the immutability of blockchain, queries can be easily parallelized.

I didn't have a research on the transaction distribution for accounts, but from my experience of Ethereum, most accounts have transactions sparsely scattered on the blockchain. So using the bloom filters would save us the query time.

This need us to build our own bloom filters, however.

[danuker]

@jayphbee
Suppose we use the first two hex digits of an address as a bloom filter. For instance:

• was any address starting with 00 involved in this block?
• was any address starting with 01 involved in this block?
  and so on.

This would yield 16x16=256 address prefixes requiring storage.
There are about 100 txns per block, each having, at least 2 addresses, so you'd have a false positive rate of around 80%, so two digits are not enough.
Lets go up to 3:

• This would have a false positive rate of ~200/4096, which is ~5%, which ought to be acceptable. (You need to check 5% of the blockchain).
• However, we now need 4096 bits, or 512 extra bytes per block, to store this.

This would mean for the current blockchain length of 5909736 blocks, we would need about 2.82 GB to store the bloom indices of block<->addresses.

It may be worth an extra 2.82 GB for a transaction index like this, compared to having to re-scan the blockchain for the addresses you're interested in. You'd save 95% of the time.
Having an even bigger bloom filter (say, 4 digits) would yield 45.09 GB, which would rival the blockchain itself, and make it slower to go through the filter.

[tjayrush]

There's a very long discussion of doing exactly what you're discussing here: Adaptive Bloom Filters to Identify Transactions of Interest per Account. Ethereum already has a fixed-width bloom filter at each block and then again another fixed-width filter at each receipt, but it's over-saturated at the block level and under-utilized at the receipt level. Adaptive blooms grow as space is need to ensure a consistent saturation level which means you can remove the receipt-level blooms and replace them with one or more at the block level. It allows for very fast scanning of the chain looking for blocks of interest.

Also, just FYI. QuickBlocks provides a command line tool called getBlock which has an optional parameter called --addrs which along with a block number (or range) will list all addresses associated with that block. From this, you can build a filter to get transactions per account. It's open source.

[debragail]

is anyone implementing elastic search?

[skinderis]

Do we have the listtransactions method for the address yet?

[sfarrugia15]

Any updates on this? If not, possibly efficient implementations?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions

[SleepingNext]

You guys might wanna check on Etherscan API. They provide a function that might satisfy your needs.

[danuker]

You guys might wanna check on Etherscan API. They provide a function that might satisfy your needs.

Sure, but the idea of cryptocurrencies is to work without middlemen, and Etherscan is a middleman.

[Merdi-kim]

This issue is still a nightmare

[tjayrush]

You guys might wanna check on Etherscan API. They provide a function that might satisfy your needs.

Sure, but the idea of cryptocurrencies is to work without middlemen, and Etherscan is a middleman.

You should definitely check out TrueBlocks. This is exactly what TrueBlocks does -- fully decentrally.

[lebed2045]

@tjayrush sadly this doesn't work for sidechains. Also, the link to "Adaptive Bloom Filters to Identify Transactions of Interest per Account." - doesn't work, could you please share the lastest working one?

[tjayrush]

@lebed2045 Here's a better link to some papers (https://trueblocks.io/papers/) and a blog discussing (https://trueblocks.io/blog/).

The ideas there work with any EVM-based chain. Not sure if that includes sidechains, but if they are EVM-based it works.

Sorry for the shill everyone, but it does actually work. I'm using it every day.

[Vikrant-Khedkar]

no solution yet?

[tjayrush]

https://trueblocks.io/papers/2023/specification-for-the-unchained-index-v2.0.0-release.pdf