Hot answers tagged

25

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


22

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


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


8

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


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


3

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


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

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


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

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


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


2

It's a complex question, i use the briefest description as far as possible. At first read the facking source code. Broadcats Transaction. In handler.go file, there is a txBroadcastLoop method, the function of it is sending a local transaction to peers of connected, when a transaction committed, this method would be called by event. by BroadcastTx method, ...


2

I'm assuming these are the first transactions submitted by the account. If so, your nonce should be starting at 0. The image shows that the first pending transactions with a nonce of 1. Those transactions won't be processed until a transaction with nonce 0 is submitted.


2

To quote to answer found here: Normally, the transactions live there until mined, but because computers have finite memory and processing power, the transaction pool is, by necessity, also of a finite size. Transactions that have not been mined may be evicted from memory if the transaction pool is full (I assume the ordering is implementation dependent -- ...


2

It's unlikely that the implementation details of something like the memory pool are part of the specification. It might mention "there's a pool of transactions", but implementation would likely be left as an exercise for the implementer. The important parts of the Geth implementation are in tx_pool.go (and for Parity it looks like the files in parity/miner/...


2

Infura doesn't provide any methods to view pending transactions. According to this Github issue We don't support the parity specific methods. We also don't provide the txpool geth methods either


2

A transaction sent from an externally owned account (EOA) to another EOA will never fail when the data field is 0. A transaction sent from an EOA to a smart contract may, however, fail if 0 is provided for the data field. In general, when transacting with a smart contract, if the transaction's data field does not match an existing method signature on the ...


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