30

You can load this script to your geth console Mine only when there are transactions! var mining_threads = 1 function checkWork() { if (eth.getBlock("pending").transactions.length > 0) { if (eth.mining) return; console.log("== Pending transactions! Mining..."); miner.start(mining_threads); } else { miner.stop(); ...


16

eth.pendingTransactions are the transactions that your local Geth node has, that haven't been mined to a block. eth.getBlock('pending') is the current block your node is mining (or would be mining on). It is not a block that has been added to the blockchain. eth.getBlock('pending').transactions are the transactions that are included in this hypothetical ...


11

Just use eth.pendingTransactions to find the transaction you want to resend. Then var tx = eth.pendingTransactions[index], replacing index with the index of the transaction you want to resend. Then eth.resend(tx, <optional gas price>, <optional gas limit>). This allows you to change the gas price and gas limit of the resent transaction. ...


8

Latest means the latest block that is already inside your own chain. All transactions contained within can be considered successfully executed. Security wise of course there can be reorgs, but in general they are executed transactions. Pending on the other hand is the collection of transactions that can be executed by the network (that your own node knows ...


7

My understanding is that your understanding is correct, except you're missing one particular property of the Ethereum node software. Namely, as part of #3, the transaction is stored in the node's transaction pool (cf. Bitcoin's mempool). Normally, the transactions live there until mined, but because computers have finite memory and processing power, the ...


6

I still don't know why eth.resend was failing (and continues to fail as of geth 1.6.5), but this compatible patch works for me: eth.resend = function (tx, gasPrice, gas) { if (gasPrice) { tx.gasPrice = gasPrice; } if (gas) { tx.gas = gas; } tx.data = tx.input; return eth.sendTransaction(tx); }; I prefer to also add this convenience ...


6

The network's under strain cause of the Status ICO. Unfortunately there's not much you can do for cancelling it since the transaction has already been propagated to other nodes. If you click on the Gas Price you can set a higher price and resubmit the transaction to the network.


6

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


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

Example here using filters: How do I know when I've run out of gas programmatically? and also here by busy polling: https://github.com/barkthins/ether-pudding/blob/master/index.js#L375 I use busy polling, because I've found the filters to be unreliable (fails about 1:1000 times) EDIT: Also, how MANY blocks to wait for confirmation is debatable, ...


4

In Parity the hash is the an item for the ordering criteria, as you can see here: https://github.com/paritytech/parity/blob/1aaafa2d11b42af6be97754f4bc06e2856904464/ethcore/src/miner/transaction_queue.rs#L179 So in theory, the hash can decide the order, if the previous ordering compared to "equal". However miners can, and probably do, run custom algorithms ...


4

I have an educated guess based on the following scenario that Ethereum does permit: A sends 10 eth to B. (Tx01) While Tx01 is pending, A also sends 10 eth to C. (Tx02) Whether Tx01 or Tx02 end up in the chain (if any) is implementation-dependent and based on the node that actually mines the block. As a result, one cannot rely on anything in the transaction ...


4

You can totally simulated the transaction througth eth_call. Her are the code snippets of eth_call and apply transaction (source from go-ethereum): eth_call (could not change state) // Setup the gas pool (also for unmetered requests) // and apply the message. gp := new(core.GasPool).AddGas(math.MaxUint64) res, gas, failed, err := core.ApplyMessage(evm, ...


4

I assume you deployed it on the Main Net using MetaMask. Probably the gas limit of the transaction was too low. Otherwise the gas price was to low. Please send a screenshot of your MetaMask transactions, in case above didn't fix it.


3

Yes, that's normal Geth behavior. eth.pendingTransactions are the transactions that your local Geth node has, that haven't been mined to a block. Geth does not persist these anywhere, so they are gone when Geth is restarted. You can also see that eth.pendingTransactions is an addition to Geth and not part of web3.eth. (There's also eth....


3

Your coins seem to be in your account on the public blockchain explorer, so I don't think you have to worry. The next step is to work out what has happened in your local wallet. Presumably you are using the Ethereum Wallet. Check the block number (like 2,105,732 currently) on the top of your Ethereum Wallet screen. This should match the latest block in ...


3

Often it will appear in seconds after you transmit it. If you are asking about "pending" transactions from an exchange wallet then it will appear shortly after they actually transmit the transaction to the network


3

4371658 (7837 block confirmations) This means that your transaction was mined in block 4371658. That block was at Oct-16-2017 03:00:36 PM +UTC, about 21 hours before your question was posted. The 7837 block confirmations means that the transaction is irrevocably part of the network. Usually 30 or so confirmations are regarded as enough, which is 7-8 ...


3

Whose transaction gets priority and is added to the block? (Only one will go through while the others are refunded minus the gas for the computation) Whichever of the 3 transactions was chosen by the miner who finds the block. Miners can pick any transactions they like, so long as they allow for valid state changes. (They can do this by writing their own ...


3

Péter Szilágyi's answer on (https://github.com/ethereum/go-ethereum/issues/16284) help me to solve the problem. Every account and transaction in Ethereum has a nonce. At any given time, only the transaction with the correct nonce can be executed. If you submit a transaction with a low gas price, that will block all subsequent transactions since they ...


3

To send a transaction to the network, all you need is a connection to it. When using geth or parity, your the nodes may not broadcast your transactions until they are reasonably close to being fully synced with the network on some modes. You can always run them in a light mode setting, which allows them to connect to already synced nodes and make requests,...


3

These are both valid transactions, provided transaction 2 gets mined before transaction 1. When a miner finds a block, they include the transactions in an order they choose. If they happen to choose transaction 2 to occur before transaction 1, then transaction 1 will be successful. If they do it in the opposite order, transaction 1 will not be successful. ...


2

For what is worth, slightly related. I've sent a transaction from MetaMask with low gas price. I was searching for a solution to fix it. Luckily MetaMask offers a convenient solution: (great feature, thank you developers)


2

As far as I know you only have the two hooks you mention above: on_start() and on_block(), beyond that you'll need to experiment with what's possible. There's very little documentation on the User Service functionality, but all the source is there to learn from.


2

I also depends of who emit the tx. etherscan have to sync with its peers. If the tx is from a node close to etherscan node, it's faster than if the tx have to go trough many nodes before reaching etherscan. Longest time I experiences was about 20s to see it appear as pending, but most of the time it's much faster.


2

If you use PoW you can modify the Go code under consensus/ethash/sealer.go and add a condition to refuse seal if there are no transactions: // Seal implements consensus.Engine, attempting to find a nonce that satisfies // the block's difficulty requirements. func (ethash *Ethash) Seal(chain consensus.ChainReader, block *types.Block, stop <-chan ...


2

If you're using geth POA, you can set block sealing period to 0 in genesis file, this will automatically force geth to only create new block whenever there is a transaction in network. For 0-period chains, refuse to seal empty blocks


2

I was using @niksmac answer for mining until n confirmations are achieved but the while loop caused a very high CPU usage (above 110%). I changed it for an interval and now the CPU usage is below 5%. I check every 600ms, but any number that is < block time would work. var minimum_confirmations = 3; var mining_threads = 1 var txBlock = 0 function ...


2

No. There is no way to guarantee when a transaction is going to be mined. It is not possible for a transaction to guarantee that it is mined at a specific block N, or at a specific position within block N. Even if you are a miner, your controls are limited because mining is a lottery. A miner is not guaranteed to "win" at block N. A miner does get to ...


2

No, unless you are the winning miner. The winning miner decides on the order of transactions. See What happens when a smart contract gets several similar calls in the same block? and What is the order and concurrency behavior of multiple calls to a contract in a single transaction?. If you have multiple transactions from the same account, they will get ...


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