I am trying to implement this Airdrop: https://github.com/odemio/airdropper/blob/master/Airdropper.sol
Initially, I started writing tests for our use-case, but the airdrop was not working.
function airdrop(address source, address[] dests, uint[] values) public onlyOwner {
// This simple validation will catch most mistakes without consuming
// too much gas.
require(dests.length == values.length);
for (uint256 i = 0; i < dests.length; i++) {
require(token.transferFrom(source, dests[i], values[i].mul(multiplier)));
}
}
Then I moved to Remix to goe through the whole airdrop process, including our Contract deployment, token minting and allowance.
In Remix debugger I found out that the issue is on the line
require(token.transferFrom(source, dests[i], values[i].mul(multiplier)));
I also tested the transferFrom function directly on our contract using the same values on Remix.
The error I get when trying to airdrop is:
transact to Airdrop.airdrop errored: VM error: revert.
revert The transaction has been reverted to the initial state.
Note: The constructor should be payable if you send value. Debug the transaction to get more information.
What could cause this issue and how can I debug this further? :)
Thanks and have a nice day!
The error could be for several reasons:
source doesn’t have enough tokens to cover all of the transfers.
One or more destination addresses are invalid.
The approve wasn’t done correctly (it’s the airdrop contract that needs to be approved, not the initiator of the transaction).
You can narrow it down by removing the require and see if any drops are successful (the way you have it coded, one failure will roll back the entire transaction).
Related
I'm working on a uni project based on blockchain, and I have to audit our system, check known attacks, ect.
This the the document that I check, principaly, since i start to work on smart contracts issues first :
Known-attack ethereum smart contract
I have trouble understanding the example used in the "Dos With (unexpected) revert attack" part. I share the code :
// INSECURE
contract Auction {
address currentLeader;
uint highestBid;
function bid() payable {
require(msg.value > highestBid);
require(currentLeader.send(highestBid)); // Refund the old leader, if it fails then revert
currentLeader = msg.sender;
highestBid = msg.value;
}}
They say that an attacker could force the call of bid to revert everytime so no-one is able to bid, which would make the attacker win the auction by default.
But.. How would he do that, that's the part I don't get. Do we agree that at least this piece of contract is the "valid one", and isn't a payload ? If the payload is a contract, can anyone provide an exemple/explanation ?
I'll add that, if here I quote a solidity contract, we work with Vyper, but from what I read before, this is still a kind of issue that i'll find there too.
Thanks in advance !
If send() target address is a smart contract it will execute the fallback function.
If the currentLeader points to a smart contract that has a fallback function that has been intentionally made to revert on failed send, the bid() won't work for any participants until currentLeader has been changed.
More information here.
This is not a "DoS" attack but simply gotcha in Solidity programming.
I'm trying to deploy the following contract on Ropsten using an injected web3 environment (i.e. metamask) on remix.ethereum.org/
pragma solidity ^0.4.16;
contract Coin {
// The keyword "public" makes those variables
// readable from outside.
address public minter;
mapping (address => uint) public balances;
// Events allow light clients to react on
// changes efficiently.
event Sent(address from, address to, uint amount);
// This is the constructor whose code is
// run only when the contract is created.
function Coin() public {
minter = msg.sender;
}
}
I've been able to create contracts with ease using remix before. I'm not sure what has changed, but I can't create contracts at all because of the gas limit thing. I've even gone as far as setting the gas limit to 2 full Ethers (i.e. value 1 ether with max of 2). I have close to 3 ethers in my metamask wallet. The remix "Account" dropdown also displays my metamask address correctly so it seems that the injected environment is connected.
When I try to create this contract I can't get past the gas required exceeds limit 2 error. I'm scratching my head as to why this simple contract would exceed the cost of 2 full Ethers.
Other parameters for remix in use:
optimize=false&version=soljson-v0.4.20+commit.3155dd80.js
Is there a setting on remix that I've forgotten? I'm Trying to deploy this from Chrome.
edit: I'm still scratching my head on this one. I was able to create the contract above for a brief moment after refreshing my page, but I came in today to try and run the code from https://www.ethereum.org/token and I can't get past the exceeds gas error with a value of 20 Gwei and a limit of 3000000. Note, I tried using the simple sample contract above and I'm back to where I was when I started - even the simple "Coin" contract above apparently exceeds the gas limit.
edit 2: Well, I think I'm getting somewhere. I've changed the compiler version from "soljson-v0.4.20+commit.3155dd80.js" to "soljson-v0.4.19+commit.c4cbbb05.js". Then I refresh the page 3 times. After that I wait a couple of minutes and things seem to be working again. There is something else happening here because when I reject the transaction in metamask and then return to remix to create again, I encounter the gas exceeded error. I don't believe the issue here is metamask as I've tried to connect locally using testrpc - localhost:8545 - and experience the same issue. All I can say is that the same code that I try to create fails to submit because of the gas error most of the time but occasionally works regardless of compiler version.
I just started learning solidity and have some questiones about the smart contract I created for pratice/fun.
Please let me know if any of my concepts are inaccurate, appreciate for all the advices and suggestiones.
Description:
the concept of this smart contract is really simple, whoever send the bigger amount of ether into the contract wins, it will pair you with whoever is before you (if no one is before you, you are player_one) and it will reset after 2 player are played (so it can be played again)
Code:
contract zero_one {
address public player_one;
address public player_two;
uint public player_one_amount;
uint public player_two_amount;
function zero_one() public{
reset();
}
function play() public payable{
//Scenario #1 Already have two player in game, dont accpet new player. do I even need this check at all? since smart contract execute serially i should never face this condition?
if(player_one != address(0) && player_two != address(0)) throw;
//Scenario #2 First player enter the game
else if(player_one == address(0) && player_two == address(0)){
player_one=msg.sender;
player_one_amount = msg.value;
}
//Scenario #3 Second player join in, execute the game
else{
player_two = msg.sender;
player_two_amount = msg.value;
//check the amount send from player_one and player two, whoever has the bigger amount win and get their money
if(player_two_amount>player_one_amount){
player_one.transfer(player_one_amount+player_two_amount);
reset();
}
else if(player_two_amount<player_one_amount){
player_two.transfer(player_one_amount+player_two_amount);
reset();
}
else{
//return fund back to both player
player_one.transfer(player_one_amount);
player_two.transfer(player_two_amount);
reset();
}
}
}
function reset() internal{
player_one = address(0);
player_two = address(0);
player_one_amount = 0;
player_two_amount = 0;
}
}
Questions
When sending ether back to users, do I need to calcualate how much
gas is going to take? or would smart contract automatically deduct
the gas from the amount i am going to send
Is it correct to set reset() as interal since i only want it to be
called within the smart contract, it shouldn't be called by anyone else
Would Scenario#1 ever happen? since from what I understand
smart contract do not have to worry about race condition and it
should never be in that state?
Is adding playable to play correct? ( since user are going to send ether with this call)
Is using throw a bad practice? (warning on remix)
transfer vs send, why is it better to use transfer?
I coded this smart contract as a practice. I can already see that if
someone want to game the system, he could just wait for someone to be player_one and check the amount player_one send(after the block is mined) and just send a bigger sum than that. Is there anyway this exploit could be stopped? Is there other security/flaws I did not see?
Thanks!
When sending ether back to users, do I need to calcualate how much gas
is going to take? or would smart contract automatically deduct the gas
from the amount i am going to send
The gas limit specified when executing a transaction needs to cover all activity end-to-end. This includes calls out to other contracts, transfers, etc. Any gas not used after the transaction is mined is returned to you.
Is it correct to set reset() as interal since i only want it to be
called within the smart contract, it shouldn't be called by anyone
else
internal is fine for what you're intending to do. But, it's more like protected access. A sub-contract can call internal methods. private provides the strictest visibility.
Would Scenario#1 ever happen? since from what I understand smart
contract do not have to worry about race condition and it should never
be in that state?
No, it should not happen. You are correct that transactions are processed serially, so you don't really have to worry about race conditions. That doesn't mean you shouldn't have this sort of protection in your code though...
Is adding playable to play correct? ( since user are going to send
ether with this call)
Yes. Any method that is expecting to receive wei and uses msg.value needs to be marked as payable.
Is using throw a bad practice? (warning on remix)
throw is deprecated. You want to use one of revert, require, assert as of 0.4.13. The one you use depends on the type of check you're doing and if gas should be refunded. See this for more details.
transfer vs send, why is it better to use transfer?
send and transfer are similar. The difference is that send limited the amount of gas sent to the call, so if the receiving contract tried to execute any logic, it would most likely run out of gas and fail. In addition, failures during send would not propagate the error and simply return false. Source
I coded this smart contract as a practice. I can already see that if
someone want to game the system, he could just wait for someone to be
player_one and check the amount player_one send(after the block is
mined) and just send a bigger sum than that. Is there anyway this
exploit could be stopped? Is there other security/flaws I did not see?
Security is a much more in depth topic. Any data sent in a transaction is visible, so you can't hide the exploit you mentioned unless you use a private blockchain. You can encrypt data sent in a transaction yourself, but I don't believe you can encrypt sending ether.
In terms of other security issues, there are several tools out there that perform security checks on contracts. I'd suggest looking into one of those. Also, read through the security considerations page on the Solidity documentation.
I am using testrpc and truffle to test my smart contract before deploying it to the real network.
In my contract, each node has to register in the contract by calling the function register, after that he can send or receive messages to/from contract( the blockchain )
The problem is, when an address ( let say account 1 from testrpc accounts) call the functions (send or receive ) the transaction doesn't occur and this message appears
VM Exception while processing transaction: invalid JUMP at
But when I use another unregistered account to call this function, it works.
Although no messages have been sent or received but no exceptions..
Any idea how I can solve this.
Thanks
Unless your using an old version of solc to compile your solidity the chance of this being an optimization problem is almost none.
Now, what does this mean then, it can happen when for example you run a modifier and it doesn't work. or if you try to call a function you are not allowed to and it throws. For example, it happens a lot after an ICO finishes and you try to use a function that can't be used anymore due to a date constraint it returns an Invalid Jump
I can't see your code but I think you might have reversed your if condition in your modifier and now it returns true if the user is not registered.
I am using testrpc and web3.
I used the idiom below to ensure that only a previously defined user should be able to do something:
function doSomethingProtected() {
if ( msg.sender != authorizedUser )
throw;
flagSomething = true;
}
When calling the function on an instantiated contract with web3 as follows:
myContract.doSomethingProtected( { from: "0x..." } );
it worked. At first I was pleased but then I realized the web3 API had not required me to provide any passphrase for a private key or such like.
Can anyone with the simple knowledge of someones public key/address call this function?
The use of this idiom in the examples led me to believe a benefit of the Ethereum contracts was that it ensured msg.sender was cryptographically assured.
The reason is that you are using testRPC, which doesn't lock it's accounts, so you don't need a password.
If you were to do this with geth, you would need to unlock the account before sending from it.
Without the private key, that function will throw an error, so you are correct in using that authorization method.
It's difficult to be certain without seeing more of your code, but it seems likely that you were calling the contract on your local node, rather than sending a transaction. Transactions can only be signed by someone with the account's private key, meaning you can rely on msg.sender to be accurate, but messages executed on your local node won't enforce that. Any changes they make are rolled back and not applied to state, though, so it doesn't matter what your local call does.
In general, there are two ways to call a function from web3.js: Using a transaction or just using a "call". Only in transactions you can actually modify the blockchain content (reading is always possible). Transactions always require a valid signature and thus access to a private key.
The reason you were not asked for a password might be that you already unlocked the account. Furthermore, users other than the authorized user can call the function, only the changes will be thrown away.
My guess is that your account was already unlocked when calling the function. I don't remember the exact period that your account is unlocked after unlocking it in web3. I might be wrong though. Would have added this as a comment, but I am not allowed right now.