So the last couple of weeks I spent my freetime on working on a dApp and I'm almost finished there's one last thing I have to implement but I really struggle to do so.
So my dApp is basically a game. To get more players I added a token which the players can earn. I want them to stake their tokens to receive some of the profit the game makes. All the ETH the game makes goes into a treasury contract. That's the same contract where people can stake their tokens. I want them to have a "pending ETH reward" which they can withdraw on their cost. Similar to sushiswap with the difference that there isn't a fixed amount of reward per block. So basically I want the smart contract to assign the Ether it receives to the token stakers based on how much they stake. I don't want the Eth to directly get send to the addresses of the stakers because this would be to pricy.
At first I thought this would be easy but than I looked into it, wasted many hours and found out that I have no clue how to do this. How can I let my contract know that it received ETH and that it should do something evertime it receives Eth? Every type of help is highly appreciated!
My current idea is to make a struct array called "Users". Each User stores the adress, pendingETHreward and amount of staked tokens. Each User should be mapped to the addres of the user. The Problem: I dont know how to update the variable pendingETHreward of each user everytime the contract receives ETH.
You will write a smart contract function that does the logic you described
-> This is simply matter of programming and outside the scope of this question - if you are not on the level of Solidity programming yet that you can do this, then I suggest tutorials and online courses
Mark your function as payable in Solidity
Users will call your smart contract function from their MetaMask and then they attach any number of ETH as the payload for the transaction
Smart contract can then hold this ETH and have internal accounting done for who it belongs based on msg.sender address in Solidity code
Related
I kinda need help figuring out the problem here, if anyone can help its very very much appreciated!
I'm trying to test out liquidity for my own token on the Binance Smart Chain, however I'm encountering a confusing issue that I can't seem to figure out.
I created a token with a supply of 1,000,000 (lets call it TOKEN). I am holding all of them in my Metamask wallet and I go to pancakeswap to provide liquidity. As a test, I added 100 TOKEN in a liquidity pool with 0.0001 BNB, setting the price at 1 TOKEN = 0.000001 BNB. Up until this point, everything is working fine.
Then I went to buy 100 TOKEN using 0.0001 BNB, and it says that the price impact is about 99.8%, which is okay with me, and I understand that since I'm buying the entire supply of liquidity.
At this point, after the transaction, I should have 1,000,000 TOKEN in my wallet again, so theoretically, at least in my mind, I can sell my 1,000,000 TOKEN for the old price of 0.0000001 BNB x 1.998 (0.000001998 BNB = 1 TOKEN), after factoring the calculated price impact. According to my calculations, this would mean that by selling 1,000,000 TOKEN, I would receive 1,000,000*0.000001998 = 1.998 BNB after the trade.
However, when I try to execute the trade, the price Pancakeswap sets for my sale of 1,000,000 TOKEN is less than what I originally set as liquidity, meaning that I end up with less BNB than what I started with.
I'm relatively new to the concept of liquidity and setting up your own crypto token, so I would really really appreciate if anyone with more knowledge can help explain what exactly is going on here?
I don’t have any pictures right now but I’ll try to add some when I’m home later.
The template I used is here on GitHub:
https://gist.github.com/mattupham/0a3af746ccbabeef3f461a9664ba4ea0
Thank you so much!
Don't kill me if I'm about to ask something stupid. But I'm very noobish in this whole crypto world, and I'm terribly fascinated about its technology.
So just for education purposes I've decided to build my own blockchain following more or less the bitcoin principles (ECC keypair generation using the secpbk1 curve, SHA256 as hashing algo, dynamic diff based on the timestamp of the previous block, p2p connectivity etc..). But I've came to a point where I'm pretty confused about the blockchain's wallet itself.
For what I've learned so far, each transaction has to be signed by a wallet. So my transactions has basically three fields: input, outputs and id. Since the user's wallet signs the outputs field of the transaction, this can't be changed anymore without being signed again by the same private key that belongs to the public key contained in the input field, how can I reward the miners?
If I got it right, the miner creates a transaction signed somehow by the chain using the fee in the outputs field, or by asking the chain itself to generate and sign a special reward transaction for that miner.
The guide that I was following was using the second approach, and was generating a blockchain wallet each time the program was executed on a client. This approach left me perplexed:
wouldn't a client generate a new wallet for "his" blockchain each time it goes back online? If so, wouldn't this create a mess on the transactions signed on the chain? Since each miner (therefore peer) signing its own reward would use a different blockchain wallet than the other peers? Wouldn't this lead to any problems?
The first one that I might think of, is that if we generate a new blockchain wallet that signs rewards for miners, each peer would create a different wallet, so wouldn't this lead to many "ghosts" wallets in the chain, that spits out rewards tokens from nowhere? Is this supposed to happen?
For what I think is definitively more straightforward to use the fee amount to reward the miner, but this doesn't solve my doubts at all. Since the outputs of the transactions are signed upon creation, how could the peer initiating the transaction know upfront the possible miner who finds the block? And if he can't know it, how could possibly the miner "extract" its reward without tampering the transaction itself? Of course it could create a new transaction, and add that to the block. But who would sign that transaction? From where those reward tokens come?
And if the answer is not to generate a new wallet each time, where could you possibly store that very first private key of the chain's wallet where no one can see it, but still be able to use it, without having to put a server in the middle?
Which in my opinion breaks the whole decentralized concept and would add a single point of failure.
I've also implemented a transactions pool, that automatically filters out invalid (tampered) transactions, whenever a miner requests a sub set of them to stamp in a block. But does this mean that the miner for that only exception can tamper the transaction since it'll be "forged" in the block? So who gives a *** if it was tampered once it got in the chain? MEEEEEH that doesn't sound nice at all.
I'm terribly confused, and I'm dreaming key pairs at night. Please help me.
wouldn't a client generate a new wallet for "his" blockchain each time it goes back online? If so, wouldn't this create a mess on the transactions signed on the chain? Since each miner (therefore peer) signing its own reward would use a different blockchain wallet than the other peers? Wouldn't this lead to any problems?
You don't say what problems you think this will lead to. I can't think of any.
For what I think is definitively more straightforward to use the fee amount to reward the miner, but this doesn't solve my doubts at all. Since the outputs of the transactions are signed upon creation, how could the peer initiating the transaction know upfront the possible miner who finds the block? And if he can't know it, how could possibly the miner "extract" its reward without tampering the transaction itself?
The simplest solution to this is for the transaction itself to just contain its inputs and outputs. The fee is the difference between the total inputs and the total outputs.
The miner just includes the transaction in the block of transactions they mine. They also add one additional transaction into the block, sending themselves the reward. Obviously, they know their own destination address. Every participant who receives the newly-mined block checks to make sure this transaction is valid (just as they check every other one) and doesn't claim a larger reward than is allowed.
And if the answer is not to generate a new wallet each time, where could you possibly store that very first private key of the chain's wallet where no one can see it, but still be able to use it, without having to put a server in the middle?
Typically in a file on the local disk. The private key isn't really needed anyway -- you only need it to send. You don't need it to mine or report. So it can be prompted for or decrypted only when actually needed.
Of course it could create a new transaction, and add that to the block. But who would sign that transaction? From where those reward tokens come?
The usual rule is that the reward transaction has no inputs, one output, and no signature. The tokens come from the pool of unclaimed miner reward tokens which can be finite or infinite depending on the blockchain's design. (For bitcoin, this pool is finite.)
I need to write my hash to block chain to make my document legit for life time (want to know how to do that)? Want to know how many block chains are out there and which few are the best ones with least expenses?
You can make a commitment in a Bitcoin transaction in at least a few ways.
1 - including your preimage in OP_RETURN data in an zero value output. This can be done by creating your own transaction manually, but you will have to pay the transaction fee. You could also use a service which aggregates many commitments into one final hash, then you share the fee (or don't pay one at all). One example is OpenTimestamps.
2 - Pedersen commitment - use your preimage to generate an EC public key along with a blinding factor. Does not use extra space in your transaction, therefore can be included in a transaction without additional fees.
3 - Pay-to-contract signature - including another preimage the nonce used in your transaction signature. This also does not take extra space in your transaction, therefore can be included in a transaction without additional fees.
Resources
A good resource is waxwing's blog: https://joinmarket.me/blog/blog/finessing-commitments/
Another good readup on this subject can be found here: https://blog.eternitywall.com/2018/04/13/sign-to-contract/
James Chiang's Teach Bitcoin curriculum: https://teachbitcoin.io/presentations/ecdsa.html#/
And wikipedia: Commitment Scheme
Save your data in any cloud server or ipfs and then deploy any sample smart contract
contract MyToken {
constructor(){}
string my_doc;
function set(string memory link) public{
my_doc=link;
}
function get() public view returns (string memory ){
return my_doc;
}
}```
//and you can use polygon you can do all the stuff in les then one dollar
//by way you watch a simple tutorial how deploy smart contract using remix ide
I am trying to send ERC20 token using JSON RPC. I am very new in this step and learning. I am using eth_sendTransaction function. What is "value" and "data" option in this case ? Please help
From https://programtheblockchain.com/posts/2017/12/29/how-ethereum-transactions-work/:
The following values are encoded:
recipient – The account address to which the transaction is being sent.
value – The amount of ether to transfer from the sender to the recipient. This amount may be zero.
data – Optional arbitrary binary data. During contract deployment, this is where the contract’s bytecode is sent. When calling a function on a contract, this specifies which function should be called and with what arguments. For simple transfers of ether, the data portion of the transaction is typically omitted.
gas limit – The maximum amount of gas that can be consumed by the transaction.
gas price – The amount the sender will pay for each unit of gas.
nonce – A sequence number called a “nonce”. The sequence number is per sender and must match the next available sequence number exactly.
signature – Data that identifies and authenticates the transaction’s sender.
If you want to send ERC20 tokens via RPC calls, you need to call the transfer function of the token contract with correct parameters.
Since ERC20 is not a well-defined standard, but rather an interface I would not recommend doing that blindly, you would have to study the contract source first to make sure it's possible.
To answer your question on a higher level:
value is the amount of Ether transferred (in Wei) and should be 0 because you do not want to transfer any ETH.
data is the hex-encoded execution of the ERC20 transfer, e.g., the method name called, and it's parameters.
I highly recommend using a wallet that supports ERC20 tokens, such as MyCrypto or Parity, but that is probably not what you are asking for :)
Note, I work for Parity.
I have written and launched a smart contract of solidity in ropsten network. And it is working well. Now I want to launch that on main net. I know few things like
1- Cost to launch depends on the opcodes. Well I have written about 50 lines of smart contract and when seeing opcodes its too large. It is tedious to calculate the approximate cost to launch on main net seeing opcodes.
2 - There is a function in web3js named estimateGas. But it used for only transaction not for launching contract.
3 - There is something like gasPrice and maxGasAmmount which can be used by a miner. Also gasPrice varies from 2 gwei to n gwei.
4 - It also depends upon the variables used in constructor.
I have also refered to this website https://ethgasstation.info/index.php and https://www.myetherwallet.com but couldn't get much info. What can be the gas price and max gas price which can be kept for an ideal contract having some basic functionalities like transfer tokens, check balance, maintain owner and transfer owner etc.
I want to make around 10 billion tokens on main net. Is it possible? If yes what can be the approximate cost for that considering March 2018 for that. I don't mind waiting for 5-15 minutes to launch the contract.
estimateGas will tell you exactly how much gas you need, but pretty much any tool you use to deploy will call that for you. (Yes, that's for estimating the gas usage of a transaction, but deploying a contract is a transaction.)
You already launched to Ropsten, so presumably you managed to use a sensible gas amount then. Do whatever you did to deploy that time.
For the gas price, https://ethgasstation.info/ is indeed a good resource. Right now 2 gwei looks good if you're not in a hurry.