69
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
...
29
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.
5
Here is how to cast address to address payable:
address addr = 0x****;
address payable wallet = address(uint160(addr));
And contract cast to address payable (thx to @Cyril):
MyContract addr = MyContract(0x****);
address payable wallet = address(uint160(address(addr)));
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 () ...
answered Jun 20 '17 at 12:07
Validity Labs - Sebastian
6,8682 gold badges26 silver badges58 bronze badges
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 {
}
}
...
answered May 8 '17 at 6:09
Validity Labs - Sebastian
6,8682 gold badges26 silver badges58 bronze badges
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, ...
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
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
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
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
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.
2
You can see the amount of Eth coming in msg.value, so use it in your calculations. Add something like this:
uint threshold = 1 ether;
uint percentage = 5;
function buy(uint minPurchaseReturn) public payable {
...
if(msg.value > threshold){
//the following line introduces no overflow risk
//since there's not enough Ether to ...
2
It cost about 1200 gas according to remix.
using this contract:
contract test {
address user = 0xca35b7d915458ef540ade6068dfe2f44e8fa733c;
function send() public {
user.transfer(0);
}
}
Produces a transaction cost of 22381 gas, with execution cost of 1173 gas
Changing the value of the transfer to anything different from zero (note ...
2
Without seeing your code, this is just a guess, but maybe you're using Solidity 0.5.x and recievers_address is declared as an address rather than an address payable?
2
This works.
pragma solidity 0.5.1;
contract A {
function() external payable {
// fallback logic goes here ...
}
}
contract B {
constructor() payable public {
A a = new A();
address payable receiver = address(a); // cast goes here
receiver.transfer(msg.value);
}
}
Hope it helps.
2
Transfer may fail because there is not enough ether on sender contract's balance, or because recipient is a smart contract that does not accept payments, or needs more than 2300 gas in order to process incoming ether transfers.
Assuming that part1 + part2 + ... + part6 ≤ 100 I would guess, that at least one of your destination addresses is a smart contract ...
Only top voted, non community-wiki answers of a minimum length are eligible
