While attempting to send tokens via a contract I run in to the error message: "SafeMath: subtraction overflow."
Initially I only used the transfer functionality. However, as I thought the msg.sender only has to send its tokens to the other user (via truffle console this is no issue). However, reading [this] I got the impression it is actually the contract address that becomes the msg.sender in the TokenContract. Therefore, (as only the accounts but not the contract itself) I thought that I have to send tokens to the contract first, subsequently approve that the contract is allowed to send tokens on behalf of the msg.sender and subsequently transfer the money. However, I keep having the SafeMath error.
The TokenContract (not the interface below) implements the The most simple version of my code is as follows:
contract ContractA {
function pay () public returns (bool) {
TokenContract tk = TokenContract("tokenContractAddress");
tk.transferFrom(msg.sender, address(this), 5);
tk.approve(address(this), 5);
tk.transfer("someAccount", 5);
return true;
}
}
interface TokenContract {
function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
function approve(address spender, uint256 amount) external returns (bool);
function transfer(address recipient, uint256 amount) external returns (bool);
}
contract TokenContract is ERC20, ERC20Detailed {
constructor() ERC20Detailed("Token", "TKN", 18) public {
_mint(msg.sender, 1000);
}
}
Obviously I expect not the safeMath error to appear. As I transfer money and approve. I just expect the same behaviour as when using truffle console.
I assume that the address calling ContractA hasn't set an allowance for the contract.
Requirements:
* the caller must have allowance for sender's tokens of at least amount.
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.3.0/contracts/token/ERC20/ERC20.sol
/**
* #dev See `IERC20.transferFrom`.
*
* Emits an `Approval` event indicating the updated allowance. This is not
* required by the EIP. See the note at the beginning of `ERC20`;
*
* Requirements:
* - `sender` and `recipient` cannot be the zero address.
* - `sender` must have a balance of at least `value`.
* - the caller must have allowance for `sender`'s tokens of at least
* `amount`.
*/
function transferFrom(address sender, address recipient, uint256 amount) public returns (bool) {
_transfer(sender, recipient, amount);
_approve(sender, msg.sender, _allowances[sender][msg.sender].sub(amount));
return true;
}
Caller of Contract A approves an allowance for the Token
Caller of Contract A calls pay function and which calls transferFrom to transfer from the user to the recipient within the previously set allowance.
If you are creating ERC20 tokens you may want to look at the OpenZeppelin Contracts implementation to see if this meets your needs. See the documentation for details: https://docs.openzeppelin.com/contracts/2.x/tokens#ERC20
If you are transferring a variety of ERC20 tokens you may want to consider using SafeERC20 wrapper to make these calls: https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#SafeERC20
If you need an interface for ERC20 you may want to look at using IERC20: https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#IERC20
Alternatively to ERC20 you could look at creating ERC777 tokens (no need to do approve and transferFrom in two separate transactions). See the documentation for details: https://docs.openzeppelin.com/contracts/2.x/tokens#ERC777
If you have questions on using OpenZeppelin you can ask in the Community Forum: https://forum.openzeppelin.com/
Disclosure: I am the Community Manager at OpenZeppelin
Related
I am creating an ERC20 token. Can I make initial supply 0? If yes than how will increase supply later on?
I just wanna know that can I make initial supply 0 while deploying an ERC20 token?
Yes, you can create an ERC20 token with 0 initial supply by not minting any tokens in the constructor.
Example code with the OpenZeppelin ERC20 implementation. Mind that this code is simplified and not suitable for production as it allows minting new tokens by anyone.
pragma solidity ^0.8;
import "#openzeppelin/contracts/token/ERC20/ERC20.sol";
contract MyToken is ERC20 {
constructor(string memory name, string memory symbol) ERC20(name, symbol) {
// no token minting in constructor => initial supply is 0
}
// you can call this function later to increase the total supply
function mint(uint256 amount) external {
_mint(msg.sender, amount);
}
}
The token is ERC721 by OpenZeppelin
I'm trying to add USDC payments to my Smart Contract, but I'm having problems.
This is my function to accept token.. but transfer its called by Smart Contract. Dont work...
function AcceptPayment(uint32 amount) public {
tokenUSDC.transfer(address(this), amount * priceCapsule);
bulkMint(_msgSender(), amount);
}
Allowance and approve its working fine, testing with Remix.
New try.. but get: Execution reverted on Remix
function AcceptPayment(uint32 amount) public {
bool success = tokenUSDC.transferFrom(msg.sender, address(this), amount * priceCapsule);
require(success, "Could not transfer token. Missing approval?");
bulkMint(_msgSender(), amount);
}
I can't find a solution to make the transfer from the Smart Contract itself.
The user needs to approve() your contract address to pull their tokens. This action needs to be called directly from the user address (on the token contract).
Then you can transferFrom() their address to yours.
function AcceptPayment(uint32 amount) public {
bool success = tokenUSDC.transferFrom(msg.sender, address(this), amount * priceCapsule);
require(success, "Could not transfer token. Missing approval?");
bulkMint(_msgSender(), amount);
}
I am currently using the Open Zapeline smart contract for my Dapp, I wanted to know if there is a way where users can claim my tokens (i.e transfer from owner wallet to current user) I know a method with hardcoding the private keys but is there any way wherein the Smart Contract I can set msg.Sender as Owner or Transfer tokens from Owner account to the user without any signatures?
You can use the internal function _transfer() (GitHub link) that only validates is the from param is the actual owner of the token. But it doesn't validate if the msg.sender is the token owner.
Note that this function has internal visibility, so it's only executable from inside of your contract.
pragma solidity ^0.8;
import "#openzeppelin/contracts/token/ERC721/ERC721.sol";
import "#openzeppelin/contracts/access/Ownable.sol";
contract MyCollection is ERC721, Ownable {
constructor() ERC721("MyCollection", "MyC") {
_mint(owner(), 1);
}
function claim() external {
require(ownerOf(1) == owner(), "Already claimed");
_transfer(owner(), msg.sender, 1);
}
}
This is the interface that is required for a token to be an ERC20 token
contract ERC20Interface {
function totalSupply() public constant returns (uint);
function balanceOf(address tokenOwner) public constant returns (uint balance);
function allowance(address tokenOwner, address spender) public constant returns (uint remaining);
function transfer(address to, uint tokens) public returns (bool success);
function approve(address spender, uint tokens) public returns (bool success);
function transferFrom(address from, address to, uint tokens) public returns (bool success);
event Transfer(address indexed from, address indexed to, uint tokens);
event Approval(address indexed tokenOwner, address indexed spender, uint tokens);
}
I want to keep private the address of who owns my token. So I deleted the Transfer event and the Approval event. I also made the balanceOf function private.
Is there still some way for a public person to find out who owns one of my tokens? Also is there some way for a public person to know when a trade has taken place?
Is it private?
No
Is there still some way for a public person to find out who owns one of my tokens? Also is there some way for a public person to know when a trade has taken place?
The storage of the contract can be inspected, and the transaction data can be inspected. This data is necessarily public. The best you can do is make it harder for your median user to find this information (although the people who know what they're doing could dig it out and then publish it).
Is it an ERC20 token?
No
This is the interface that is required for a token to be an ERC20 token... I deleted the Transfer event and the Approval event. I also made the balanceOf function private.
Note that deleting those things makes it not an ERC20 token anymore. Those are required in the ERC20 spec.
What now?
Transactions that are private on a public blockchain is an ongoing area of research. If you really want to implement this, it will take diving into the current research in the space, getting familiar with things like ZK-SNARKS and alternatives.
Yes, one of the major features of Bitcoin and Ethereum are that they are public. When anyone uses your smart contract, all their actions are recorded, necessarily and by design, in the blockchain.
See this tx which called a smart contract method. Notice how I can see who sent what to whom, what function was called, and with what parameters.
I'm getting a "Message signature was incorrect" exception when trying to authenticate with MyOpenID and Yahoo.
I'm using pretty much the ASP.NET MVC sample code that came with DotNetOpenAuth 3.4.2
public ActionResult Authenticate(string openid)
{
var openIdRelyingParty = new OpenIdRelyingParty();
var authenticationResponse = openIdRelyingParty.GetResponse();
if (authenticationResponse == null)
{
// Stage 2: User submitting identifier
Identifier identifier;
if (Identifier.TryParse(openid, out identifier))
{
var realm = new Realm(Request.Url.Root() + "openid");
var authenticationRequest = openIdRelyingParty.CreateRequest(openid, realm);
authenticationRequest.RedirectToProvider();
}
else
{
return RedirectToAction("login", "home");
}
}
else
{
// Stage 3: OpenID provider sending assertion response
switch (authenticationResponse.Status)
{
case AuthenticationStatus.Authenticated:
{
// TODO
}
case AuthenticationStatus.Failed:
{
throw authenticationResponse.Exception;
}
}
}
return new EmptyResult();
}
Working fine with Google, AOL and others. However, Yahoo and MyOpenID fall into the AuthenticationStatus.Failed case with the following exception:
DotNetOpenAuth.Messaging.Bindings.InvalidSignatureException: Message signature was incorrect.
at DotNetOpenAuth.OpenId.ChannelElements.SigningBindingElement.ProcessIncomingMessage(IProtocolMessage message) in c:\Users\andarno\git\dotnetopenid\src\DotNetOpenAuth\OpenId\ChannelElements\SigningBindingElement.cs:line 139
at DotNetOpenAuth.Messaging.Channel.ProcessIncomingMessage(IProtocolMessage message) in c:\Users\andarno\git\dotnetopenid\src\DotNetOpenAuth\Messaging\Channel.cs:line 992
at DotNetOpenAuth.OpenId.ChannelElements.OpenIdChannel.ProcessIncomingMessage(IProtocolMessage message) in c:\Users\andarno\git\dotnetopenid\src\DotNetOpenAuth\OpenId\ChannelElements\OpenIdChannel.cs:line 172
at DotNetOpenAuth.Messaging.Channel.ReadFromRequest(HttpRequestInfo httpRequest) in c:\Users\andarno\git\dotnetopenid\src\DotNetOpenAuth\Messaging\Channel.cs:line 386
at DotNetOpenAuth.OpenId.RelyingParty.OpenIdRelyingParty.GetResponse(HttpRequestInfo httpRequestInfo) in c:\Users\andarno\git\dotnetopenid\src\DotNetOpenAuth\OpenId\RelyingParty\OpenIdRelyingParty.cs:line 540
Appears that others are having the same problem: http://trac.dotnetopenauth.net:8000/ticket/172
Does anyone have a workaround?
Turns out this was an issue with using DotNetOpenAuth in a web farm environment.
When you create your OpenIdRelyingParty make sure you pass null in the constructor.
This puts your web site into OpenID stateless or 'dumb' mode. It's slightly slower for users to log in (if you even notice) but you avoid having to write an IRelyingPartyApplicationStore to allow DotNetOpenAuth to work across your farm;
var openIdRelyingParty = new OpenIdRelyingParty(null);
All this discussion revolves around the following question:
How does Relying Party (RP) make sure the request containing the authentication token is coming from the OP(OpenId Provider ) to which he forwarded the user’s request to?
Following steps explains how it happens
User Request comes to the Replying Party (RP), our website in our case
Application stores a unique signature corresponding to this user in a local signature store (LSS) and then embeds this signature in the Message and forward this Message to OpenId Provider(OP)
User types his credentials and the OP authenticates his Message and then forwards this Message, which has the signature still embedded in it, back to RP
RP compare the signature which is embedded in the Message to the signature which is in LSS and if they match RP authenticate the user
If the LSS vanishes (somehow) before the Message comes back from OP there is nothing for RP to compare the signature with thus it fails to authenticate user and throws error: Message signature was incorrect.
How can LSS Vanish:
ASP.net refreshes the application pool
IIS is restarted
In web farm the Message is served by application hosted on different server
Two solutions to this issue:
RP run’s in dumb mode
a. It does not store and signature locally and thus does not use signature comparison to make sure the Message is coming from the OP to which he forwarded the user to for authentication
b. Instead, once RP received the authentication Message from the OP it send the Message back to OP and ask him to check if he is the one who has authenticate this user and is the originator of the Message. If OP replies Yes I am the originator of this Message and I have created this message then the user is authenticated by RP
Implement your own persistence store that does not vanish, not matter what ASP.net does to the process, much like using SQL to store session state.
We fixed this issue by implementing IRelyingPartyApplicationStore (IOpenIdApplicationStore in newer versions of DotNetOpenAuth) and adding the store class name to the .config
<dotNetOpenAuth>
<openid ...>
<relyingParty>
...
<store type="some.name.space.MyRelyingPartyApplicationStore, some.assembly"/>
</relyingParty>
</openid>
...
</dotNetOpenAuth>
The interface is a composition of two other interfaces with five members all together.
/// <summary>
/// A hybrid of the store interfaces that an OpenID Provider must implement, and
/// an OpenID Relying Party may implement to operate in stateful (smart) mode.
/// </summary>
public interface IOpenIdApplicationStore : ICryptoKeyStore, INonceStore
{
}
We used dumb mode as a quick fix to get up an running, but in the end you'll probably want something like this.