Hot answers tagged

30

Summary It is limited by your computer's memory. From my basic testing in What happens when a transaction nonce is too high?, I crashed geth with 400 x 64 transactions with a data payload of 4,500 bytes when running in 4 Gb RAM. I am assuming that your question is asking what is the maximum number of transactions that can be stored in the transaction pool....


24

Look at the answer in What is the max size of transactions can clients like geth keep in txpool? What is the difference between a pending transaction and a queued transaction? Pending transactions are transactions that are ready to be processed and included in the block. Queued transactions are transactions where the transaction nonce is ...


9

It's called the Transaction Pool, or TxPool in the code. From go-ethereum - tx_pool.go, lines 35 to 62: var ( // Transaction Pool Errors ... ) const ( maxQueued = 64 // max limit of queued txs per address ) ... // TxPool contains all currently known transactions. Transactions // enter the pool when they are received from the network or ...


9

Looking at your transaction, you have set a gas price of 4 gwei. Though not very high for current traffic, this should eventually get picked up. You can check gas prices and traffic on ETH Gas watch. That could help you decide if you want to pay a lower fee and wait longer for your transaction to be mined, or pay a higher fee to include it faster. If it's ...


8

The closest I was able to find is parity_pendingTransactions and parity_pendingTransactionsStats. parity_pendingTransactions is very similar to geth's txpool_content, and gets the job done. Update: Since I was specifically looking for transactions sent from a specific account, this new method works even better: parity_localTransactions It only returns the ...


7

Geth The default config values associated with the transaction pool can now be changed from Geth's CLI: TRANSACTION POOL OPTIONS: --txpool.pricelimit value Minimum gas price limit to enforce for acceptance into the pool ( default: 1) --txpool.pricebump value Price bump percentage to replace an already existing transaction (default: 10) --...


6

This is really an implementation detail and every miner could operate on a wide variety of mining strategies. That being said, AFAIK miner miners/pools run the standard algorithm included in Geth, which is: Discard anything below a threshold Gather all the executable transactions (i.e. one for each account) Pick the more expensive one Repeat from step 2. ...


5

Answering your first question: If the transactions in a block that is declared invalid have not been already validated somewhere else in the main blockchain, they will be returned to the pool of unconfirmed transactions from which miners mine. There is no loss of data.


5

60k - 80k pending transactions sounds like a normal situation and does not seem extensive. Currently, Ethereum does ~750k transactions daily. Assuming all transactions are processed at the same rate, the content of the pool is swapped in every 2.5 hours. However, my guess is that automated services send very low fee transactions that are not critical. ...


4

These transactions are from a mining pool. You can see the frequently mined blocks in 0xea674fdde714fd979de3edf0f56aa9716b898ec8. What you saw in txpool.content.pending are just two pending transactions representing the transactions that the miner is paying to the miners in the pool. Here is the transaction list for the same account. This mining pool is ...


4

Now we can compare, since a few days ago the Ropsten network just verified a Zcash transaction via a zkSNARK. Check it out here. Confirmation time: the same as for a usual Ethereum transaction. The on chain verification transaction consumed 1933895 gas, which with a 21 Gwei gas price would approximately cost $10.722 on the mainnet. cca. 0.7kB To put ...


4

here is how you handle this issue in a practiced and proven way. First, before planning your organization to be too large-scale, please make yourself familiar with the characteristics of the Ethereum blockchain. Transactions per second is a bad measure, as the critical part here instead is the block and the time it takes to mine it. Also consider the block ...


4

I would suggest first exploring the tx-queue related configuration options. From the Parity documentation: --tx-queue-mem-limit=[MB] Maximum amount of memory that can be used by the transaction queue. Setting this parameter to 0 disables limiting. (default: 4) --tx-queue-size=[LIMIT] Maximum amount of transactions in the queue (waiting to be included in ...


4

The transactions to mine are selected given a process that is absolutely specific to each client but even more to each miner. Indeed the transaction (tx) selection and sorting process is not part of Ethereum protocol. That is, miners can decide to select and sort transactions the way they prefer. However, miners are mainly incentivised by earning money (...


4

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 ...


4

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.


3

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


3

With Web3 1.0.0 it's easy to implement it yourself: var Web3 = require('web3'); var web3 = new Web3('ws://127.0.0.1:8546'); web3.eth.extend({ property: 'txpool', methods: [{ name: 'content', call: 'txpool_content' },{ name: 'inspect', call: 'txpool_inspect' },{ name: 'status', call: 'txpool_status' }] }); Then use it ...


3

I'm not sure that this is necessary in practice; The advice you quote is for a situation where you're making raw transactions offline and may drop some of them, but if you just send your transactions through Geth it should handle the broadcasting of the transactions and the nonce incrementation, and things should generally Just Work. However, it's true, at ...


3

you have an equal chance to get your transaction mined, transaction brodcasting doesn't depend on wich client you are using. However parity is known to be faster, because geth doesn't have an optimization that Partiy has


3

To me, etherchain is more accurate to show the pending transactions. https://www.etherchain.org/txs/pending. It is possible to get the pending transaction in JSON through the following get request: https://www.etherchain.org/txs/data?draw=1&start=0&length=100


3

Update 23th of June 2017 Since the ICO craze started which are often badly designed we now have the actual need to see unconfirmed transactions. With Geth you can use eth.pendingTransactions from the console (geth console or geth attach to an other running Geth instance. This will return all unconfirmed transactions sent from on of the local accounts. If ...


3

grepping around geth's code I found the following: core/tx_pool.go const ( maxQueued = 64 // max limit of queued txs per address ) type stateFn func() (*state.StateDB, error) // TxPool contains all currently known transactions. Transactions // enter the pool when they are received from the network or submitted // locally. They exit the pool when they ...


3

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 -- ...


3

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 ...


3

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, ...


3

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). ...


2

There is no need for recovery; if the transaction is in the transaction pool, the node synchronizes (relays) it to its peers that further relay the transaction to the rest of the network which will confirm it (mine it and broadcast the result to the block chain). If the node crashes and the transaction is not relayed, then peers have no idea that the ...


2

One possible explanation for the anomaly, you could be locally mining the transaction but not connected to other morden testnet peers. The following may help if this is the case: See: Geth - Checking Connectivity Specifically, the following commands. > net.listening > net.peerCount > admin.peers You could also check your balance (locally) and ...


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