1

Given a finalized transaction, is there a way to see how long it took? Perhaps using blocks to calculate an estimate?

Take this one for instance.

I have been trying to calculate transaction times of existing ones but I feel I'm missing some info and I dont know whether these sites are showing the most relevant information or that is all there is to a transaction.

Thanks.

Improve this question

2 Answers 2

Reset to default
1

There's no exact way to see how much a transaction takes to be mined. The transaction can float around in the network for a few hours, be discarded by the nodes and can be republished again (identical transaction) to the network and be mined.

There is no timestamp attached to the transaction when it is first published or created.

What you can do is create a service that connects to an ethereum node (geth / parity) and monitor transactions by hash, save them in a database and see when they were added in blocks.

You can run a parity node with

--tx-queue-gas off
--tx-queue-mem-limit 0
--tx-queue-size 18446744073709551615

Which will increase to max the number of transactions that are added to the pool. By default some are ignored

Improve this answer
1

Just to add to the accepted answer, if you're running a full node, you can monitor transactions as they're added to the transaction pool, take a note of the time that they appear1, then compare against the time at which they eventually get incorporated into a block.

This is likely how services such as ETH Gas Station's TxPool Report work.

1 Handling for the case in which they're removed from the pool and resubmitted.

Improve this answer
6
  • You don't need a full node to monitor transactions
    – Daniel Luca CleanUnicorn
    Feb 13, 2018 at 18:38
  • You might be right - I've never checked for a service provides access to its transaction pool :-) Also, if you're running your own node, you'd need to ensure your transaction pool config was such that you could be certain you were storing all broadcast transactions, which might also be difficult to do without a large amount of RAM.
    – Richard Horrocks
    Feb 13, 2018 at 18:47
  • I've added more information about how to run a node to monitor the tx pool. I'm currently running a node that has other optimizations in place, like decreasing ancient blocks that are saved in the database, disabling ui, ... but those specific parameters allow you to monitor almost all transactions floating in the network
    – Daniel Luca CleanUnicorn
    Feb 13, 2018 at 19:10
  • Yep, I've done this in the past, it's just I thought a full node was required to do this - are you saying it's possible to do this on Parity with pruning enabled? (i.e. The transaction pool is running even if you're not a full archive node.)
    – Richard Horrocks
    Feb 13, 2018 at 19:16
  • Yes, it works with pruning enabled. Not sure if you consider this a full node or not :)
    – Daniel Luca CleanUnicorn
    Feb 13, 2018 at 19:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.