Martin

Reopening the issue. The original issue was ETH related and solved by the `--txlookuplimit=0` parameter. However, the new issues are not very informative. Could you plese @ciberluffy @mano92fuentesjimenez @v1adislave @alireza1371...

@alexeirojas87 Is Blockbook never able to find the tx 317a3a9d3e6ba1c1bfe9ea6e8a3d41212dee98eaa3160b15a81853de5bfb9cc7 or only for a short time after it is mined in the new block?

Are you able to get the transaction from the backend, using `bitcoind-cli getrawtransaction`?

But we have it in our Blockbook, see https://tbtc1.trezor.io/tx/d2c0f99177eb10aa8ae962b2e9b871ec407ef133563cfd677e0ce0741ba0bedf. The issue is not that Blockbook is not able to handle this transaction in general, there must be something specific to...

@alexeirojas87, @peterpan0708 Hi, please provide more details. Ideally blockbook log around the problematic case.

Timed Blockbook responses (i.e. at xx:xx gettransaction works, at yy:yy does not work, at zz:zz works again), accompanied with the Blockbook log from the problematic period.

@huanghuang933 does the transaction record reappear later? How long does it take to sync block? Is your Blockbook connected to the backend using ZeroMQ? What would help is to see...

I would estimate that on a reasonable server with enough memory, the import of a block with 1 million transactions takes less than 5 minutes. It corresponds to an initial...

This looks like a powerful enough machine. I think this PR https://github.com/trezor/blockbook/pull/427 (which was not merged) could be interesting for you . Merge it to your codebase and try to...

@liuyangc3 hi, I would recommend to use the branch https://github.com/trezor/blockbook/tree/v0.4.0 to build and install the execution and consensus layer backends. The merge is fully supported, we already run the consensus...