Hot answers tagged

3

New answer September 2020 A cool new tool was released: https://explorer.blocknative.com


3

It's just a slow node... When a node receives a transaction, it sends it to other connected nodes, who then send it to other connected nodes (repeat), until all the nodes have the transaction in their mempool. This process takes some time (but not much). It is possible that a transaction that is sent just before a block is mined could be picked up by the ...


2

You're thinking is heading in the right direction. A contract cannot monitor event logs so that activity needs to be off-chain. Using off-chain processes to identify opportunities has advantages - computing capacity, off-chain inputs, maintenance/optimization of the algorithms, cost, etc. Many (most) attack strategies require transaction atomicity. That is, ...


2

The bots are continuously listening to both onchain changes (events, transactions, etc) and offchain changes (for example, price changes). Whenever they find that the time is right, they send a transaction to one of their already-deployed smart contracts, or possibly even deploy a new smart contract. In both cases, the desired set of operations is performed ...


2

There's no predefined order for transactions in a block. The only requirement is for transactions from the same address to be sorted by the transaction's nonce but transactions from different addresses can be in any order. In Ethereum mainnet miners will sort by gas price because they will get a larger reward. But it is not always the case, search for "...


2

But where do the miners broadcast the new blocks to? Any other nodes in the network that they are connected to - their peer nodes. Anyone running a client node and/or mining can view a list of their connected peers by running one of the following commands: For the Geth client: admin.peers For the Parity/OpenEthereum client: parity_netPeers RPC method (...


2

Sean from Blocknative here. Thanks for posting the question! Etherscan appears to report a block Timestamp using the block header's timestamp field. This is also reported by Blocknative for confirmed transactions in the blockTimeStamp field. This time is set by the minor when the block is constructed (before actual mining). Note that the miner has some ...


1

If my source still applies, light node cannot maintain a pool of pending transactions (except its own transactions). A light client only maintains its own transactions. It cannot maintain a pool of pending transactions, since it cannot check the validity of those transactions (without the state, which is costly to pull from the network for every single tx). ...


1

You do not need to go through this hassle, you can use getAmountsOut on the PancakeSwap router contract to make this a lot simpler. You provide a path&amount of the first token in the path to use, and the function returns the token quantity you would receive at that moment. You can then use this data for price calculation.


1

The transaction failed because due to the higher gas price and being on the same block, it was executed before the liquidity was added. I was confusing the nonce with the block position.


1

Cancelling a transaction means replacing a pending transaction with another one that has the same nonce, but a higher gas price. You can never be sure which transaction will be mined and there is never a guarantee that your first transaction will be cancelled. Miners are free to include in a block whichever valid transaction that they want. Normally, they ...


1

Another visualisation, why breakdown into gas price ranges. Displays total gas costs and count of pending transactions. https://txpool.zengo.com


1

You can use the nonce and transaction count to validate if the nonce was mined. if (tx.nonce < getTransactionCount(sender)) { drop transaction } I don't think this situation is particular to testnets. I'd say it is worse in mainnet where short chain reorgs are common.


1

Maybe it is useful. For the mainnet you can follow the steps to install the geth client "Full Node on the Ethereum Mainnet" https://github.com/ethereum/go-ethereum. And on the command line, when starting the client geth, add txpool to the --http.api section (or the deprecated --rpcapi depending on the geth version). This will allow you to access ...


1

One transaction is (eventually) executed only once. It may be executed by different nodes around the same time and even maybe included in a block but only one such block may exist in the blockchain. So there is no point for nodes to even try adding a transaction twice so they will just ignore transactions which they already know about. The more miner nodes ...


1

Use a service like Blocknative: https://www.blocknative.com/. They have a notification service for new transactions. Run one or multiple nodes yourself. The faster you would want new transactions, the more nodes you might want to deploy in different geographical locations.


1

We have been running ethviewer.live since late 2017 with a modified geth client. It has certainly been painful to keep up with latest versions of geth. Also, we have had outages when we were unable to keep up with forks. As suggested by @Eugene I tried with web3.eth.subscribe('pendingTransactions') and it seems to be working fine. One caveat though -- ...


1

It's a bit counterintuitive, but while web3.eth.getPendingTransactions() returns only local pending transactions (from transaction field value matching accounts within the node), web3.eth.subscribe('pendingTransactions') will return a stream of global pending transactions. Please find usage examples here.


Only top voted, non community-wiki answers of a minimum length are eligible