73
address.transfer()
throws on failure
forwards 2,300 gas stipend (not adjustable), safe against reentrancy
should be used in most cases as it's the safest way to send ether
address.send()
returns false on failure
forwards 2,300 gas stipend (not adjustable), safe against reentrancy
should be used in rare cases when you want to handle failure in the contract
...
34
Both send and transfer are considered to be a safe way to move funds as they have a gas stipend of 2300.
If you are curious about the reasons for adding a transfer you may follow an original discussion about the feature.
EDIT Dec 2019: call.value()() should now be used for transferring ether. (Do not use send or transfer.)
Please see:
Is transfer() still ...
7
UPDATE:
Solidity 0.6.x now have explicit conversions to payable:
payable(userAddress)
And for smart contracts:
payable(address(smartContract))
Old answer for Solidity 0.5.x:
Here is how to cast address to address payable:
address(uint160(userAddress))
And contract cast to address payable (thx to @Cyril):
address(uint160(address(smartContract)));
5
ETH + ERC20 tokens sent there are burnt
Effectively. Unless someone generates the private key, in which case they'll take ownership of those funds.
Note that you could pick any other unused address as a burn address, it's just people seem to have used 0x0 (and various others) as Schelling points.
That there should be no owner of the private key of that ...
3
send() will be deprecated in the future in favor of transfer(). You can read about the differences in this answer <address>.send vs <address>.transfer best practice usage?
address.transfer()
throws on failure
forwards 2,300 gas stipend, safe against reentrancy
should be used in most cases as it's the safest way to send ether
...
3
You have basically two different approaches:
do the distribution via smart contract wallet or
have a client watch your private-key controlled account and then initiate a payment
In detail, for 1 you could use something as simpel as this:
contract relay {
address target;
function relay(address _target) {
target = _target;
}
function () ...
3
ERC20 token transactions don't have to follow the same rules as Ether transactions.
What the list of token transfers for address 0x00 is showing you is a list of Transfer events that have been raised by contracts that resemble ERC20 tokens. Any token contract can raise a Transfer event with any contents, so it's not necessarily reliable.
Take, for example, ...
3
Problem: You are trying to send Ethers with the command receiver.transfer(amount); and specifying the amount as a parameter. Since your contract do not have enough ether balance it reverts the transaction.
Solution: You need to have enough ethers in your contract or you should send ethers along with the function call to solve the problem.
Change your smart ...
3
I setup a minimal test example that you can find on https://gist.github.com/anonymous/07d4714c27dbf1af0e5cb16c9f833353
pragma solidity ^0.4.11;
contract Test {
Receiver myR;
function setReceiver (address a) {
myR = Receiver(a);
}
function callR() {
myR.call(this.balance);
}
function sendCash() payable {
}
}
...
3
Yes this is true. If you read the Ethereum Yellow paper you can see in Appendix H that you have to pay extra gas if you send Ether to a new account.
This is to discourage addresses sending a load of transactions to new addresses, blowing up the chain size like that.
3
The payer of the transaction pays for the gas cost. There is currently no option of making the recipient pay for the ether. You can do a gas estimate and deduct the amount of ether the recipient would get manually on your end, but the paying account still needs to pay the gas up front.
Response to edits:
I think note 1 is just not rigorous. I think that ...
3
This line:
recipient.transfer(amount);
transfers amount wei from the contract's balance to the recipient. This line:
recipient = msg.sender;
means that the recipient is the account that called the function.
So when you call the function from the address 0xca35b7d915458ef540ade6068dfe2f44e8fa733c, with the parameter 10, that address will receive 10 wei, ...
3
Looks like the answer to your question is CREATE2. This is an EVM opcode that was created to allow contracts to be created deterministically, (other people use the term 'counterfactually')
It's a fairly complicated topic. One link is here: https://hackernoon.com/using-ethereums-create2-nw2137q7 but there are many you could check out.
Perhaps most simply ...
3
There are no "wallet aliases" in Ethereum. Sounds like you came up with this term yourself.
It is not possible to avoid paying gas and somebody needs to pay for it. Ethereum network is public infrastructure and its security is supported by the transaction fees. There are some other blockchains, like EOS, which offer limited free tier transactions ...
3
The contract can't prompt the user for any input. It has to be the frontend code which asks the user for input.
So in your frontend you need to ask the user to input the amount of Ether to send and then you can use that amount in the value field for the transaction. Examples can be seen here: https://web3js.readthedocs.io/en/v1.2.11/web3-eth.html#id86
2
EDIT Dec 2019: call.value()() should now be used for transferring ether. (Do not use send or transfer.)
See:
Is transfer() still safe after the Istanbul update?
2
tl;dr contract addresses are always unique as they are determined based off the address creating the account, and the nonce of that address. This means that no two contracts will have the same address, but that with a bit of trial and error we can easily make contracts with "vanity" addresses. See below
The address of a contract is determined based on the ...
2
I assume you mean being able to create vanity addresses that start with some characters of your choosing. If it's that so, you can check this tool:
https://github.com/MyEtherWallet/VanityEth
** I haven't tried it, can't vouch for it and its security.
** If you are going to use it, make sure the accounts or contract addresses generated really work before ...
2
I'm not sure this kind of mistake is possible. Bitcoin addresses are represented by ~34-character base-58 strings, while Ethereum addresses are represented by 40-character base-16 strings.
2
As i feel easy way is to keep a mapping that would store Boolean value true for already in addresses.
Contract Hello {
address[] internal Pool;
mapping (address => boolean) private oldUsers;
function () public payable {
require(msg.value * 10 == 1 ether);
//check for old users
if (oldUsers[msg.sender]){
revert();
Rejected();
} ...
2
I believe that it won't consume all of the gas provided.
Whilst as per the documentation it will throw:
<address>.transfer(uint256 amount): send given amount of Wei to Address, throws on failure
Since the "REVERT instruction" EIP it looks like not all of the gas is consumed anymore.
To test this, I created some simple contracts - that can be seen ...
2
Instead of return(false) you can use revert() or maybe use events so on frontend you can have listeners to be triggered by each event.
I suggest read these:
Error handling: Assert, Require, Revert and Exceptions
What is an Event?
Solidity Events Tutorial - Using Web3.js to Listen for Smart Contract Events
2
There is a reference implementation in EIP 677 and also in ERC223
This function must transfer tokens and invoke the function tokenFallback (address, uint256, bytes) in _to, if _to is a contract.
The token fallback function, which will be called at the receiver contract, must be named tokenFallback and take the parameters:(address, uint256, bytes). It’s an ...
2
HIGHLY recommended that you require users to pull their funds instead of push them to the users with a for-loop.
A lot harder to implement with a large amount of users, need to run though the loop until getting low on gas, hold position in the loop, and then wait until the next execution. If you don’t implement this then one one will get paid (ever!) when ...
2
You can see the specifications set out by the ERC-20 standard here.
For the relevant functions, transfer and transferFrom, there is no mention of mutability restrictions (or for any other function).
If you made these functions payable, and required that the value be 0.000001 ETH, it probably wouldn't be breaching the ERC-20 standard (as laid out by this ...
2
A contract can't forcefully extract ETH from a wallet address, if you want to pay Ether into a contract, you must set the "Value" of the transaction when calling a function (or just send ETH to the contracts address if the fallback function allows it).
Using transfer will transfer from the contract to another address, so with address(this).transfer(msg....
2
Using tx.origin will create issues when the factory is called from within another contract.
Wallet (A) calls > multisig contract (B) > which calls your factory (C) > sub contract (D).
In this case the tx.origin is wallet A. In most cases users will expect the owner to actually be the multisig B contract, and not A.
To prevent this, just use msg.sender in ...
2
It's probably because the receiving contract does not have its "default" function as payable.
You have to include at least this in the receiving contract.
function() payable {
...
}
2
wtk answer right, here is more details about Eth fee
When you are transferring a crypto currency from one address to another you need to pay a fee for the transfer to happen. With crypto coins like Bitcoin the fee is paid depending on the amount of the data that need to be included in a block for the transaction to happen, it is a single fee per Kilobyte of ...
2
As easy as this:
the_other_half_addr:=common.HexToAddress("0xlajfklsadjflsafjklsadjdflkadjfl")
state.AddBalance(the_other_half_addr,changedRew)
You are doing it securely, but you forgot to take the half from the uncles too.
Only top voted, non community-wiki answers of a minimum length are eligible
