eth_listTransactions

[tymat]

This feature has been discussed on gitter in the past and we would like to see this get implemented for accounts and contracts.

Proposal

eth_listTransactions

Returns a list of transaction hashes for a given external or contract account

Parameters

String - the account or contract address

params: [
  "0x385acafdb80b71ae001f1dbd0d65e62ec2fff055"
]

Returns

DATA - A list of transaction hashes

[gavofyork]

This is useless - transactions are merely one way of two ways to send a message to an object ("contract") in Ethereum; CALL would be the other way.

Use logs. It's what they were designed for.

[gavofyork]

would close.

[Gustav-Simonsson]

@gavofyork It's far from useless. For example, it would be very useful for keeping track of non-contract txs, which cannot use logs.

This feature has been requested from several people. We shouldn't force users to only use the platform in a certain way, and If users desire a API call which doesn't conflict with anything or have any significant drawbacks, we should consider adding it.

I'm in favour of adding this.

[obscuren]

So am I. But let the community decide on this. Get enough +1 and it will eventually be considered/added.

[ethernomad]

Maybe messages to non-contract addresses should automatically get a blank log entry? It would store the originating transaction id.

[frozeman]

:+1: I fully agree with gustav here. Even though most of the cool stuff can happen in contracts, being able to simply send money from one account to the other will be heavily used. And then you need a easy way to display its transactions (e.g. the wallet needs that for example :) )

I would add a second parameter, which is the nonce, from which on you want to get transactions. This way you don't need to request the whole list over and over again.

[tymat]

eth_listTransactions is very much needed for Ether to Ether transactions. For wallet devs we need a way to present this information to users so they know how their Ether was spent and when it was spent and which TX hashes they occurred in. Adding a separate persistence layer to store this data for easy access is cumbersome and would have to be constantly updated on the client side.

This is very useful and much needed.

[slothbag]

+1 I found myself looking for this feature.. would be great to get it included.

[VoR0220]

:+1:

[VoR0220]

this is much more efficient IMO than the logs...and there's a lot of use cases for this feature for execution in other contracts.

[VoR0220]

I would add a third optional parameter for number of transactions from the top or bottom (perhaps something python-esque?)

[frozeman]

Though i +1 this feature @VoR0220 you can't get logs only from transactions, as there can also be logs created when one contract interacts with another.. So only relying on this feature won't work.

I don't like the third parameter actually, as a nonce (from which nonce to get tx on), is more than enough to control the tx flow.

[VoR0220]

how does nonce control how many transactions you would like to see?

[d11e9]

:+1:

[frozeman]

If you say i want to get all transactions from nonce 50 and there a re a total of 60 tx, you will get 10

[bas-vk]

@frozeman, what if you want to retrieve tx [100...150] when there are 10.000+ transactions?

[VoR0220]

@frozeman but that's for a nonce in the chain correct? So I would only get the transactions for that block, no (I might be totally off here and feel free to correct me)? However, if I wanted to go and see the past 50 or so transactions for a particular address, how does that nonce benefit me if I want to get specific with the transactions displayed?

[frozeman]

nonce is an ear increasing number of transactions from an account. With web3.eth.getTransactionCount('0x12345..') you basically get the next used nonce (as nonces start from 0, like array.length)

And then you can subtract whatever number you want to go back and ask for those tx.

[frozeman]

@bas-vk you couldn't :)

[obscuren]

While easy to implement its difficult to do it right. Indexing all transactions would require quite significant storage and most certainly doesn't scale.

One way to do this is as how we MIP mapped LOGs and use a similar query mechanism, but this is an expensive and CPU/IO intensive operation because there are far more transactions than there are LOGs.

Doing this for LOGs is actually fine since you more or less paid for it where as transactions incurs no additional cost in terms of upfront payment. letting the user decide what to map isn't an option either since it just won't work for light clients. Light clients depend on archive and full nodes for data retrieval and can't make use of this "user setting" option because they don't receive any other data than the data that is explicit requested.

I understand this is a much requested feature but understand that it comes at a great, expensive cost and, as I said earlier, difficult to do it right.

[frozeman]

I don't expect dapps requesting this endpoint often, rather only once when a dapp syncs for the first time. It will then keep this information in a local database anyway. And only requests the last x tx.

Remote nodes would have to rate limit their requests anyway somehow.

[m888m]

I second the need for transaction listings. Regarding implementation, to compromise between system load and user friendliness, I suggest to use nonce as single argument, and implement a filter on the gui where users can limit time, counterparties, amounts etc.

[obscuren]

@frozeman that's quite an assumption you are making there and neither solves the issue at hand I described above.

@m888m the nonce is hardly the issue

[obscuren]

Remote nodes would have to rate limit their requests anyway somehow.

It's not about rate limiting either. Please reread

[rfikki]

list of transaction hashes for a given external or contract account. +1

[sammy007]

+1, with nonce param.

[m888m]

@obscuren nonce was not my main point, the need for user friendly transaction listings was. To push end user adoption, we definitely need a user-friendly way to show past transactions that happened during a certain time period and with certain counter parties. Furthermore, the transaction fees occurred for a set of transactions must be easily established.

[obscuren]

@m888m mine neither. I understand what everyone has reiterated over and over again but as I've mentioned above in great detail; there are issues with the requested feature. It's not as simple as it seems.

[tymat]

Indexing of this can be an optional setting when starting up the node. It doesn't have to be a requirement so clients that do not have CPU power can just turn the feature off.

Right now most of the web wallets and mist based wallets are forced to use some external persistence mechanism to have this data available to the user so any efforts to save CPU/etc... becomes a zero sum effort and you add an additional TCP/socket round-trip just to get the data from the blocks and then another connection to the persistence layer. Is the cost of doing indexing on the node greater than that? Probably not.

[caktux]

Got my vote. Maybe index the node's accounts by default and all accounts only optionally?

[ghost]

+1 add getTransactions(address) to API.

[karalabe]

Just a thought. As already mentioned, doing a full index of transactions would be costly both CPU and storage wise. However, if we consider that most people will only ever care about a handful of accounts, we could do a heuristics whereby a node would only index transactions for:

• Etherbase
• All accounts reported by eth.accounts
• Any account previously requested

This way the storage price would be linear to the operations you want to perform (i.e. you only expand CPU/HDD resources on the ops you personally need).

Note, this is not a +1 for this issue. I'm not yet fully sold on this. It's only a discussion idea that we could consider if/when implementing this feature.

[wildbunny]

If you guys are considering adding this, please can we have a 'since block' parameter? That's how exchanges sync their coin's blockchains and it would save them time to have this parameter.

[tymat]

+1 on the idea of doing a heuristic approach.

[chrisfranko]

+1 would like to see this

[altsheets]

Still no solution for this? (In September I got an answer "might do that as a weekend project").

You are funny people.

If I cannot simply check for transactions out of and into my account, it is pretty useless as a currency, no?

Until you start listening to your userbase ... please publish a fully working code that achieves the same result, that we can use for the time being.

Thanks.

[altsheets]

i.e. publish working code for getting all (recent) transactions of an account.
I suppose it is done with this: https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethfilter ?

Please give working example code not for "pending" but for transactions of an account .

Thanks a lot!

[altsheets]

Fiddling around with those suboptimal manual instructions.

I am stuck here:

var options = {address: "0xf2cc0eeaaaed313542cb262b0b8c3972425143f0"};

var myfilter= web3.eth.filter(options);
console.log(myfilter);

myfilter.get(function (error, log) {
    console.log("get error:", error); 
    console.log("get log:", log); 
});

results in

f {options: Object, implementation: Object, filterId: null, callbacks: Array[0], pollFilters: Array[0]}

get error: Error: could not decode, invalid type on field : not a number or string(…)
get log: undefined

Any hint highly appreciated, thanks.

[altsheets]

P.S.: Also tried this one

var options = {fromBlock: 0, toBlock: 'latest', address: "0xf2cc0eeaaaed313542cb262b0b8c3972425143f0"};

var myfilter = web3.eth.filter(options);

same results.

P.S.: Using v1.2.2.0 ( because chocolatey https://github.com/ethereum/go-ethereum/issues/2086#issuecomment-166142038 ).

[frozeman]

@altsheets filters are not for getting past transactions, this issue doesn't belong here ;)

This is meant as a discussion about adding some. You issue would be better in the http://github.com/ethereum/web3.js/issues repo.

Please file there again, and ideally give the line number in web3.js where the error is thrown.

BTW just tested and works for me:

var options = {address: "0xf2cc0eeaaaed313542cb262b0b8c3972425143f0"};

var myfilter= web3.eth.filter(options);
console.log(myfilter);

myfilter.get(function (error, log) {
    console.log("get error:", error); 
    console.log("get log:", log); 
});

VM176:5 Filter {requestManager: RequestManager, options: Object, implementation: Object, filterId: null, callbacks: Array[0]…}
Filter {requestManager: RequestManager, options: Object, implementation: Object, filterId: null, callbacks: Array[0]…}
VM176:8 get error: null
VM176:9 get log: []

[altsheets]

Thank you very much for your answer.

filters are not for getting past transactions

Ah. That explains it why all my such code attempts were futile :-)

Perhaps the wiki could be improved to state that fact "not past".

So then the existing API is telling us really only one thing: getTransactionCount ... not more.

Sigh.

I guess the situation forces a lot of ETH developers to be iterating over the whole chain, building own databases of those results, etc. (same seems to apply to my uncles rewards question https://github.com/ethereum/go-ethereum/issues/2088#issuecomment-168728900 ?).

---

Idea:

Is there perhaps a ready made (accessing geth, preferably in Python) tool which does all that (iterating the whole chain, looking at each block, storing into a private database), which I could use to simply adapt to my needs?

(I still think getTransactions(address) should be part of the base system. But if not, then) we need to find our workarounds to correct their decisions - Just because the ETH base code architects have decided to not support such questions ... doesn't mean that they exist, and want to be examined. So I guess others have already partly solved this task, right?

Where is such a blockchain-iterator-dump-results-into-database project? Thanks.

---

You issue would be better in the http://github.com/ethereum/web3.js/issues repo.

Thank you very much for that hint. Will be looking there. (Now that I know that I won't get past transaction with that code anyways, it doesn't really matter to fix it, though). It is not always quite clear where to ask which question, and where to make which suggestion. Sorry for polluting your space here :)

So ... back on topic:

[altsheets]

+1 add getTransactions(address) to API.

[frozeman]

To be correct, filters, don't give your transactions at all, expect for filter('pending'), which gives you pending transactions.

If you use ethereum for smart contracts, than tx doesn't matter so much, as they only tell the input person of an action on the blockchain, not what happens then.

But i definitely see a use case for getting past transactions of an account too. Though as @obscuren described, this is not without overhead in space in the node, as thinks need then to be index properly and we are currently looking more for where to trim ;)

[altsheets]

Thanks.

Just an idea: Perhaps ... space saving could be to store only the block height of all the blocks that contain transactions to/from an account. The block height needs much less space than the transaction id.

If I know the blocks in which to look, it is fast to collect all the transaction ids for a certain account.

And then it is easy and straight forward to allow 'since block' and 'to block' parameters.

[tgerring]

What is being described is database indexes which is a non-trivial topic and why we're not likely to get a solution to aggregates.

Although storing an index to a particular block of data will be faster than a full scan of the database, this is not a complete solution without also considering demands for covering indexes or how that might be implemented in the client. This can be a large and complex topic and would detract from other important work going on.

[altsheets]

would detract from other important work going on

I get that. Focus on the most important and innovative topics, for sure.

On the other hand, this is the best funded team out there, so there should be time to also solve side issues.

And for some users it is not even a side issue that we want to see tx of an addr.

But ... I see no hope for us here. So:

---

What about the other idea (https://github.com/ethereum/go-ethereum/issues/1897#issuecomment-169354056) then - create a new repo which is intended to solve all "for this question you have to iterate over all blocks" questions?

In that framework repo, all necessary nuts and bolts would already be there (e.g. connect to provider, connect to local database, blocks iterator, store results per block, update-when-new-block-is-mined, etc) - and (provided I know how to code) ... I can fork it and simply plug-in my questions, like:

• "in which blocks were all transactions from my address", or
• "in which blocks were all transactions from all addresses", or
• "what is the total supply, i.e. how many uncles were there ever mined" (see https://github.com/ethereum/go-ethereum/issues/2088 ), or
• "what was the difficulty evolution since block 1",
• etc.

Then we who are interested in questions that the ethereum team finds uninteresting, would be helped. We would simply generate the answers ourselves.

What do you think?

[frozeman]

Write it up :) It should be fairly easy in any language. You have web3.eth.getBlock(1234, true), which includes even all transactions and there you go..

Ethereum is a smart contract based blockchain, we might in the future even drop normal accounts completely and make even them smart contracts, then you could fire logs for you account and have them listed, for example. Read here https://blog.ethereum.org/2015/12/24/understanding-serenity-part-i-abstraction/

[Joter271]

+1 for this command too.

[bricky]

+1 add getTransactions(address) to API.

[obscuren]

I lack the understanding for this feature request.

Why not use the system as is? Is there a particular "feature" you're missing?