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.
Related
It seems transactions on polygon can get automatically dropped and replaced.
original: 0xa67609bacf51ab83b1989e4097b4147574b4e26399bec636c4cfc5e12dfa2897
replaced: 0xec0d501619b5fc9cde6af41df929eeded252138a49965f15a7598bf2e532e555
What is happening here?
On Ethereum, I believe this can only happy if someone proactively replaces the tx by submitting another with the same nonce and higher gas price. Is that correct?
{"level":"error","message":"Error: transaction was replaced [ See: https://links.ethers.org/v5-errors-TRANSACTION_REPLACED ] (cancelled=true, reason=\"replaced\", replacement={\"hash\":\"0xec0d501619b5fc9cde6af41df929eeded252138a49965f15a7598bf2e532e555\",\"type\":2,\"accessList\":[],\"blockHash\":\"0x252f663dfb64dd82dff77b5e4fbe2073cd77248c5ce8dff1191c87ac22d97cf9\",\"blockNumber\":39285028,\"transactionIndex\":60,\"confirmations\":2,\"from\":\"0x90Be1Ef5EEa48f1d33e2574a73E50D208bB3680E\",\"gasPrice\":{\"type\":\"BigNumber\",\"hex\":\"0x6cdbaaf8e5\"},\"maxPriorityFeePerGas\":{\"type\":\"BigNumber\",\"hex\":\"0x6cdbaaf8e5\"},\"maxFeePerGas\":{\"type\":\"BigNumber\",\"hex\":\"0x6cdbaaf8e5\"},\"gasLimit\":{\"type\":\"BigNumber\",\"hex\":\"0x0186a0\"},\"to\":\"0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174\",\"value\":{\"type\":\"BigNumber\",\"hex\":\"0x00\"},\"nonce\":112,\"data\":\"0xe3ee160e00000000000000000000000090be1ef5eea48f1d33e2574a73e50d208bb3680e00000000000000000000000090be1ef5eea48f1d33e2574a73e50d208bb3680e00000000000000000000000000000000000000000000000000000000000027100000000000000000000000000000000000000000000000000000000063eb95950000000000000000000000000000000000000000000000000000000063eb9b71c726f5f957d29df36c915d2f2816a5906bdb096a68d79abeb83102359a3c51ef000000000000000000000000000000000000000000000000000000000000001cbaca5b2bb8c9b3a25ba94b3303be256a72cc37172886b67140c788f53eacfa0526f4bc5dd18d1e0154a0c574c12ff67b656846a731cc55e32b7d60a8ae5b21ee\",\"r\":\"0x2503d5645a7620c94678ef0a5de4bca4e03b18943cec0511d58b7e444412b467\",\"s\":\"0x72c2cf739e2bfeb8335faab2c4b87b7b0464c9681a488456fa7c8fe25aef89c6\",\"v\":1,\"creates\":null,\"chainId\":137}, hash=\"0xa67609bacf51ab83b1989e4097b4147574b4e26399bec636c4cfc5e12dfa2897\", receipt={\"to\":\"0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174\",\"from\":\"0x90Be1Ef5EEa48f1d33e2574a73E50D208bB3680E\",\"contractAddress\":null,\"transactionIndex\":60,\"gasUsed\":{\"type\":\"BigNumber\",\"hex\":\"0x0110bc\"},\"logsBloom\":\"0x00000000000000001000000000000000000000000000000000000000000000000000000000000000020000000000000000008000000000000000000200000000000000000000000000000008000000800000000000000000000100000000000000000000000000000000000000000000020000000000000180000010000000000001000000400000000000008000000000008000000000004000000000000000200000000000000000000000000000000004000000000000000000000000004000100002000000000081000000000000000000000000000000100000000000000000008000000000800000000000000000000000000000000000000000100000\",\"blockHash\":\"0x252f663dfb64dd82dff77b5e4fbe2073cd77248c5ce8dff1191c87ac22d97cf9\",\"transactionHash\":\"0xec0d501619b5fc9cde6af41df929eeded252138a49965f15a7598bf2e532e555\",\"logs\":[{\"transactionIndex\":60,\"blockNumber\":39285028,\"transactionHash\":\"0xec0d501619b5fc9cde6af41df929eeded252138a49965f15a7598bf2e532e555\",\"address\":\"0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174\",\"topics\":[\"0x98de503528ee59b575ef0c0a2576a82497bfc029a5685b209e9ec333479b10a5\",\"0x00000000000000000000000090be1ef5eea48f1d33e2574a73e50d208bb3680e\",\"0xc726f5f957d29df36c915d2f2816a5906bdb096a68d79abeb83102359a3c51ef\"],\"data\":\"0x\",\"logIndex\":250,\"blockHash\":\"0x252f663dfb64dd82dff77b5e4fbe2073cd77248c5ce8dff1191c87ac22d97cf9\"},{\"transactionIndex\":60,\"blockNumber\":39285028,\"transactionHash\":\"0xec0d501619b5fc9cde6af41df929eeded252138a49965f15a7598bf2e532e555\",\"address\":\"0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174\",\"topics\":[\"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef\",\"0x00000000000000000000000090be1ef5eea48f1d33e2574a73e50d208bb3680e\",\"0x00000000000000000000000090be1ef5eea48f1d33e2574a73e50d208bb3680e\"],\"data\":\"0x0000000000000000000000000000000000000000000000000000000000002710\",\"logIndex\":251,\"blockHash\":\"0x252f663dfb64dd82dff77b5e4fbe2073cd77248c5ce8dff1191c87ac22d97cf9\"},{\"transactionIndex\":60,\"blockNumber\":39285028,\"transactionHash\":\"0xec0d501619b5fc9cde6af41df929eeded252138a49965f15a7598bf2e532e555\",\"address\":\"0x0000000000000000000000000000000000001010\",\"topics\":[\"0x4dfe1bbbcf077ddc3e01291eea2d5c70c2b422b415d95645b9adcfd678cb1d63\",\"0x0000000000000000000000000000000000000000000000000000000000001010\",\"0x00000000000000000000000090be1ef5eea48f1d33e2574a73e50d208bb3680e\",\"0x000000000000000000000000e7e2cb8c81c10ff191a73fe266788c9ce62ec754\"],\"data\":\"0x00000000000000000000000000000000000000000000000000080d77c3b67cb80000000000000000000000000000000000000000000000003005ebfb86a0d1350000000000000000000000000000000000000000000003ebfb8e3e34e504eca50000000000000000000000000000000000000000000000002ffdde83c2ea547d0000000000000000000000000000000000000000000003ebfb964baca8bb695d\",\"logIndex\":252,\"blockHash\":\"0x252f663dfb64dd82dff77b5e4fbe2073cd77248c5ce8dff1191c87ac22d97cf9\"}],\"blockNumber\":39285028,\"confirmations\":2,\"cumulativeGasUsed\":{\"type\":\"BigNumber\",\"hex\":\"0x8d88d1\"},\"effectiveGasPrice\":{\"type\":\"BigNumber\",\"hex\":\"0x6cdbaaf8e5\"},\"status\":1,\"type\":2,\"byzantium\":true}, code=TRANSACTION_REPLACED, version=providers/5.7.1)"}
On Ethereum, I believe this can only happy if someone proactively replaces the tx by submitting another with the same nonce and higher gas price. Is that correct?
Yes, and the same is possible on Polygon and other EVM chains.
Senders can replace their transactions for multiple reasons. For example, high-frequency trading bots continuously check if their pending transactions are still likely to be profitable - and if the transaction is not going to be profitable, the bot replaces it with another one. Either with new recalculated params that they expect to be profitable or simply with transaction from/to the same address so at least they don't lose any more funds than just the gas fees.
Note: Once you send a transaction, it's impossible to drop it completely from the mempool. That's why it is sent back to the sender address.
Or sometimes transactions are replaced by regular users that specified insufficient gasPrice and want to speed up the transaction by replacing the gas price with a higher value.
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.)
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
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
When I set the Caller ID Name and make a RingOut through the RingCentral Java API, the receiving number displays only my Main Number, not my Caller ID Name. How do I get the call to show the CNAM?
Full disclosure, I am the COO of Telo, the makers of OpenCNAM and EveryoneAPI.
I wanted to clarify a few things contained in the initial answer to this question. I have had to answer the questions as my rep power on Stack Overflow limits my ability to post this as a comment to the question. :/
First is a quick overview of network CNAM. Next, a brief explanation of how it works and the caveats. After that, there are some specifics around Telo products, which some folks may find of value.
Overview of Network CNAM
In the +1 dialing plan (NANP) there are over 20 databases that store CNAM values, or caller name, on behalf of the telephone carriers. In practice, about 12 of them are actually queried by CNAM providers. The terminating carrier (the carrier receiving the call) queries their CNAM provider milliseconds after receiving the call with the CID (telephone number). While the call is being set up to ring, the CNAM provider will return the name value associated with that telephone number so that it can be delivered with the telephone call.
How This Works
If network CNAM is being delivered -- meaning, the carrier-supplied values that are being stored by the carrier's storage provider -- then the CNAM provider will route the query to the appropriate storage provider based on the telephone number. If a number has been ported, then the NPAC will contain the information needed to resolve the number to the appropriate storage source to be queried. If there is no record in the NPAC, then the CNARG will contain the information needed to match the telephone number to the carrier, and thus the correct storage provider.
Caveats
The match-rate for useful name values in the traditional CNAM network is about 50%. This is due to the fact that not all carriers participate. For example, while it is easy to set up CNAM values for AT&T Wireless, T-Mobile, and Sprint, Verizon Wireless is 'opt-in' and is not automatically supported. There are other carriers that do not participate in the CNAM network, and still, other VoIP providers that do not update CNAM values. The traditional CNAM network also does not provide values for toll-free numbers, and only has coverage inside of the +1 dialing plan.
About OpenCNAM
While OpenCNAM provides network CNAM through its Standard service level, it also provides two service levels that address the limitations of network CNAM mentioned above. The Plus service level is optimized for coverage, match-rate, and accuracy, while the Value service level provides excellent coverage and match-rates, but is optimized for cost. You can find out more about the service levels here.
EveryoneAPI For Current Carrier and Linetype
Our other product, EveryoneAPI, provides the most accurate data around linetype (landline or mobile) and current carrier, which will include ported numbers. The coverage for these data-points is global and the match-rate is nearly 100%. While the numverify looks very useful, it is providing what is known as LERG data for the +1 dialing plan, from what I can tell. This will not accurately reflect carrier information for ported telephone numbers.
CNAM Overview and Limitations
CNAM / Caller ID Name support is dependent on the the type of numbers used by the calling and receiving (callee) parties.
Caller must be using a local landline number, otherwise the phone number will be displayed.
Receiver must be using a non-mobile number, otherwise the phone number will be displayed.
I validated this by calling two numbers, a mobile number that showed only the phone number and a landline number that showed the CNAM.
You can read more on CNAM in this Knowlegebase Article:
Outbound Caller ID Name Overview and Frequently Asked Questions
This mentions the following excerpts:
The Outbound Caller ID Number must be a local landline number.
Toll free numbers are not supported. When the Outbound Caller ID is set to a Toll Free number, only the number will display.
Mobile numbers do not support CNAM. If the receiving party is a Mobile number, only the number will display.
When the Outbound Caller ID is set to Blocked, the call recipient will see UNKNOWN or ANONYMOUS as the Caller ID/Caller Name.
Checking Receiving Line Type
Given that mobile numbers don't support CNAM, it's useful to see if the number you are calling is a mobile number of not. You can verify the type of number you are calling by using the numverify API (https://numverify.com/). You can also use this CLI app and Go SDK grokify/numverify. Look for the line_type property in the validate API response which can be mobile or landline.
For example (phone number changed):
{
"valid": true,
"number": "16505550100",
"local_format": "6505550100",
"international_format": "+16505550100",
"country_prefix": "+1",
"country_code": "US",
"country_name": "United States of America",
"location": "Redwood Cy",
"carrier": "AT\u0026T Mobility LLC",
"line_type": "mobile"
}
Checking the CNAM Database
Receiving systems have their own CNAM databases, but you can check to see if your name has propagated by calling a CNAM database API, such as the one provided by OpenCNAM (https://www.opencnam.com/). Here is an example call for OpenCNAM. Adding the format query parameter is very important as the API will retry an empty body without it.
curl -XGET 'https://api.opencnam.com/v3/phone/+16505550100?format=json&account_sid=<myAccountSID>&auth_token=<myAuthToken>
You will receive a response like:
{
"name": "My Caller ID Name",
"number": "+16505550100",
"price": 0.0039,
"uri": "/v3/phone/+16505550100"
}