transfer() and send() should be avoided.
Gas specific code (call.gas().value()()) should also be avoided.
call.value()() should be used, for example: contractB.call.value(1000)()
It is also critical that you make sure to guard against reentrancy by making all state changes, before call.value()().
It sounds like you are being front run. This means that a bot is watching you send a transaction, reading the input (specifically, _answer), and submitting a transaction with the correct answer but a higher gasPrice. A miner will accept their transaction before yours, causing theirs to succeed and yours to fail.
You can see that this is, in fact, what is ...
In short: It's exactly as you suspect, a higher gas limit means your transaction is less likely to be included by miners.
The reasoning: miners seek to maximize their profit within each block. Calls to eth_estimateGas can be computationally heavy, so miners typically do not determine the actual gas each tx will consume. Instead they calculate gasPrice * ...
Trust me. Everytime (everytime!) you are thinking to loop trough a dataset whose dimensions you cannot predict at the “start of the time“ in a blockchain based system, you are using blockchain for the wrong thing and/or your algorithm must be changed by rethinking it.
Your model should be something where if a new “user” is added, the simply operation to add ...
A reverted transaction generally means that the logic of the smart contract being used failed or there's not enough gas to complete the transaction. The transaction was still executed by the miner, and any gas used prior to the transaction being reverted needs to be paid for. Based on this, the reverted transaction is still mined and included into the block ...
This is possible, but not advised. If you do this, you should cast the int32 to an int256 in order to be explicit.
int32 a = 1;
int256 b = 3;
int256 c = int256(a) + b;
However, using types smaller than 32 bytes may actually be more expensive than using types that are 32 bytes exactly (such as int256, uint256, etc.). The reason for this is that the EVM ...
The name of a variable does not affect gas usage.
In this case, you are using a uint, so the gas for this variable is already defined by that size. All STOREs performed on this will behave the same no matter the length of the variable name.
The pattern you are using is valid for certain table-like sets, but you should be aware of the limitations.
It is ill-advised to do anything with a contract that loops - Getting Loopy with Solidity.
You can, however, make it possible for a client to loop. It should be understood that "client" is an off-chain entity, in this context, because if it wasn't ...
Below calculations are valid as of 09 December 2019 on Ethereum mainnet.
My guess is that most of the confusion comes from the fact that constant of 2300 is used both by Solidity compiler and EVM itself. Here is what I've found so far (assuming that target account is an already created, and not self destructed, contract).
During the CALL(gas, ..., ...
From this reddit message it was fixed in geth 1.6.5 https://www.reddit.com/r/ethereum/comments/6ene3u/the_attacker_is_back_account_related_to_devcon2/
Pull request with the fix: https://github.com/ethereum/go-ethereum/pull/14570
core/vm: Use a bitmap instead of a map for jumpdest analysis
As it sounds you do not need to interact with hashes from smart contracts, you could do something simpler. Ethereum blockchain that is designed for transfer-of-value is not good for store-of-hashes use case.
Collect hashes to a single file
Publish this file in a decentralised storage network like Storj, Sia or FileCoin
Storj Tartigrade cost is $0.0045 per ...
Gas will never be free. It has a purpose and that is to create a cost for a computation. If there was no cost for computation it would be possible to do infinite loops (with each loop being free) that would cause problems for the miners and system.
(I'm sure this has come up before. If someone can find a previous answer then please duplicate... )
From the Yellow Paper, Appendix G, you'll see the following line:
Gsset - 20000 - Paid for an SSTORE operation when the storage value is set to
non-zero from zero.
Meaning the first time you write a variable to storage, it's more expensive by 20,000 gas....
What is the meaning of stipend if transactions are always have gas limit set by sender?
Not really. When EOA calls contract A, the gas limit is set in the transaction, this is true. However, when contract A calls contract B, contract A may set limit on how much gas the contract B is allowed to spend. This limit may be lower than the remaining gas ...
The length of a variable name has absolutely 0 effect on gas, and therefore transaction fee.
The length of a function name also has no effect on the transaction fee, because a 4 byte hash of the function name and its parameter types is used to select the correct function to execute, instead of the full function name.
Transactions from an exchange are usually sent from a "hot wallet", basically a wallet that is managed by the exchange. Most of the time exchanges pay for the gas, so you don't need any ETH in the exchange to withdraw tokens.
In the case of a decentralised exchange (DEX), you do need some ETH, since those kinds of exchanges are based on a smart contract.
Yes! This pattern of transactions is called metatransactions.
As you described, your user would sign the transaction, but you would send the transaction to the network via a metatransaction.
There are a number of different ways to implement it. The Gas Station Network (GSN) by OpenZeppelin provides this as a service and is worth considering for your use.
Your Mutex (locked) will prevent reentrance but reentrance is not the only vulnerability.
A DoS is possible and it might not be intentional.
This line, after payment 2:
require(success, "Transfer failed.");
Have you considered that payment 1 will not happen if the transaction aborts at this stage? That means player1 doesn't get paid unless ...
Overall fee you pay for a transaction, counted in fiat currency (EUR, USD, etc), depends on the following things:
Ether to fiat exchange rate (may change over time, out of your control)
Gas price (set by you, but miners may reject mining your transaction if gas price is too low)
Actual gas used, this depends on what smart contract actually do and how ...
There is no cost associated with calling bytes32 off-chain. If you are using this data for your application, then the off-chain call is free.
If you are calling it on-chain, there will be a cost associated with each lookup and therefore it will be possible to run out of gas. To get each value of the array, you will need to loop through the array. The cost ...
Your calculations are correct.
gasUsed = 68988
gasPrice = 11.1 gwei
totalCost = gasUsed x gasPrice = 765,766.8 gwei
Considering that 1 ether is 1,000,000,000 gwei and as of 2020-04-12 22:40 UTC 1 ether = 162 USD, then we have
1,000,000,000 gwei are valued 162 USD
765,766.8 gwei are valued 162 USD * 765,766.8 gwei / (1,000,000,000 gwei) = 0.1240542216 USD.
First of all, you don't need to add the gas-price into your computation.
This factor is chosen by you (the transaction sender), so there are no questions about it.
The only part in question is the 64244 gas units used in the transaction.
According to the white-paper, you have determined that it should be 21000 + 68 * 7 = 21476:
21000: Paid for every ...
Data storage in the blockchain always costs gas. Data reading also costs gas if it is performed in a transaction (typically when the same transaction stores and reads data).
You always use a node to access the blockchain and the node has all of the blockchain data. Therefore you can read the data directly from the node without sending any transaction (called,...
Can it be called with a small amount of gas despite it uses much?
No, gas is refunded at the end of transaction execution. If the transaction runs out of gas before that, the transaction is reverted, and no gas will be refunded. You always need to provide enough gas for transaction execution, without any gas refunds.
Can such a function be called by a user ...
"Dropped & Replaced" means the transaction has been replaced by a new one and the new one has been validated by the network (more info here : https://info.etherscan.com/transaction-dropped-replaced/).
Ethereum is effectively currently overloaded and the average gas price is very high (see here : https://ethgasstation.info/). My guess is that ...
You can use this solution to sync the state of public ethereum chains into your local private blockchain in truffle (or embark) and then locally simulate the execution of both transactions in the correct causal order to properly estimate the gas cost.