15
The page "Verify Contract" ask for "Constructor Arguments ABI-encoded".
In your case the constructor has no parameters, so you can leave such field empty.
In the general case when your constrctor has parameters you can proceed as follow:
You can use ethereumjs-abi to encode/decode the parameters for transaction calls.
Let's suppose your constructor is ...
9
It is not possible as on 24th March 2018. Etherscan is unable to locate contract code on the address of subcontract.
Here is the transaction which deploys two contracts. But for the second contract, etherscan is unable to find contract code.
The second contract does exist and this was verified by using "at address" feature of remix. Until there are some ...
9
Currently etherscan does not support verification of multifile contracts. But there is discussion on etherscan's reddit about this issue.
Concatenating files into one worked some time ago, but since version 0.4.7 Solidity includes hash of contract's metadata at the end of compiled contract. As this metadata contains file names and hashes, you may get the ...
6
I don't think so. If you could, then anyone could come along, copy the source code, and reverify it with completely different comments, which opens up for all types of attacks, including phishing. You could possibly contact Etherscan directly and they might let you replace the code if you can prove that you're the creator of the contract.
6
Guys I really hate my life. It took me over 10 hours to find the solution to this problem.
I compiled the contract with various different methods. Deployment worked with each of the but the contract couldn't be verified nontheless.
After a while I figured out that I didn't set the optimisation checkbox on etherscan to "yes".
I was compiling optimized all ...
5
There are a few different reasons for verifying your key.
To make sure you actually saved the private key and address correctly. e.g. You saved a private key but recorded the address 0x122... instead of 0x123... (note: you should avoid hand writing things anyways).
To make sure you have all the necessary information, including the password. e.g. You ...
4
You need to correctly ABI-encode your constructor parameters. You can easily do this with online tool https://abi.hashex.org. Just paste in your abi to auto-parse constructor parameters or manually add them and enter values. ABI-encoded constructor parameters would be automatically calculated. Just copy them and paste in etherscan.io constructor parameters ...
4
It depends on how strongly you want to verify the identity:
If you want a person, who you already knew, to prove that they sent the transaction, it's easy: They can just attach a piece of data to the transaction containing their name, email address, date of birth and/or any other data you require. (preferably hashed, for anonimity)
If you want someone to ...
4
Disclaimer : I am not a cryptographer nor a mathematician nor a low level software engineer. Please correct me if any information provided below is incorrect.
Very short answer: Yes
Short answer: Possible, but very difficult today.
Longer answer: The main challenge with Ethereum is that since you have a programmable blockchain, you effectively need to ...
4
Etherscan is the most cut-and-dry, but there are at least a couple of other resources available:
SmartContract.Codes - a p2p search engine for smart contract source code.
ethPM - a decentralized package manager used to distribute EVM smart contracts and projects.
I'm a big fan of ethPM, but it can take a bit of time to understand. Here are a few more links ...
3
I have deployed a contract from another contract:
https://etherscan.io/tx/0x8fd885ce7ad7b6a591d9614d41cbb1d97aa7d2e290f6aa52531ce3d4c799a5ff
which deployed:
https://etherscan.io/address/0xb1400278014f34c8243b15613a4b463b51fb6f2a#code
and I was able to verify contract using the same compiler version and optimization. You have to encode all constructor ...
3
I was able to verify my contract with optimization turned on, when compiling from remix:
https://ethereum.github.io/browser-solidity/
For some reason, it produces a different bytecode from Parity, even if you select the same compiler version and the same optimization setting.
3
You need to correctly ABI-encode constructor arguments. You can easily do this with online tool https://abi.hashex.org. Just paste in abi to automatically parse constructor parameter types or add them manually.
3
In case you want to use a simple online tool to encode parameters you may use https://abi.hashex.org
You can enter abi to automatically parse parameter types or just enter them manually. In Function type selector constructor should be picked.
Here is example of using this service, at the bottom are abi-encoded parameters that you enter in etherscan.io ...
3
I've met same problem with contract verification at etherscan.io.
https://etherscan.io/verifyContract2 - helped in my case.
Thank you
3
I was able to successfully verify the contract code you linked in a new deployment.
Are you sure the parameters and source code you used were identical to those you used in the verification tool?
For reference, here is the verification of the new deployment of your contract.
EDIT:
It might be that you are having the same problem as I am having now. It ...
3
In case you want to use a simple online tool to encode parameters you could use https://abi.hashex.org
You insert the abi code to automatically parse parameters types or just enter them manually. In Function type selector constructor should be picked.
Here is an example, at the bottom are abi-encoded parameters that you enter in etherscan.io constructor ...
3
The compiler was timing out, and documentation online suggested that truffle optimizes the compilation -- nevertheless, I selected "no" for the optimized option, and didn't enter in the library addresses, to find it successfully compiling in under 30 seconds!
2
I was able to verify the contract on Etherscan by checking the "Input Data" of the transaction that created the contract. It includes the contract bytecode and the constructor argument bytecode right after. So you can copy the constructor argument bytecode into the "Constructor Arguments ABI-encoded" field to be able to verify the contract. Thanks for that ...
2
Sorted.
Had pasted contracts in wrong order
Removed import references
Pasted constructor argument bytecode from end of deployed TX
2
The contract you're looking at is a stub. If you look at the contract's code and select Switch to Opcodes View, you can see it references another contract at 0x273930d21e01ee25e4c219b63259d214872220a2 with source code and abi published.
2
Q1: I don't see an obvious way to do that without getting into a gas-expensive loopy process that won't scale. A web3 client would be better suited to searching for it in my opinion.
Q2: I would incline to this approach if it's necessary.
It looks like it should be bytes32 instead of string. According to this: http://solidity.readthedocs.io/en/develop/...
2
You're generally describing a trust-verification system ("Can I trust that Alice is who she says she is?"). Public/private keys allow you to concretely prove a message came from a particular private key, but the question then becomes do you trust the private key to be truthful (about anything; shipping addresses, names, the weather, etc.). There are several "...
2
This is probably what you're looking for,
https://ethereum.stackexchange.com/a/1173/19016
Each account has a globally accessible nonce which prevents double spends. The nonce is the sequence number, which miners check, because a block that has a transaction with an incorrect nonce is an invalid block (other miners won't build on top of it). (The nonce ...
2
You were trying to verify the "Migrations" contract that you used in your truffle configuration.
You incrementer contract was the next contract you created, and can be found here:
https://ropsten.etherscan.io/address/0x8705c513da621a16fd1defc9de8ae7cdead01fb8#code
I verified it for you, using the Optimizer but setting it to 0 optimizations. You were using ...
2
Summary
Your comparison will never work.
The compiled code at 0x01861C6Dfab20bAe0FA4EE698912630697D78cE4 is way too small to represent the compiled wallet.sol source code.
Why do you think the contract code at the address 0x01861C6Dfab20bAe0FA4EE698912630697D78cE4 is the wallet.sol compiled code?
Details
Compiled Code At Address ...
answered May 8 '16 at 14:20
The Officious BokkyPooBah
36.1k10 gold badges105 silver badges177 bronze badges
2
Looking at the etherscan verification page,
NOTES
1. To verify Contracts that accept Constructor arguments, please enter the ABI-encoded Arguments in the last box below.
2. For debugging purposes if it compiles correctly at Browser Solidity, it should also compile correctly here.
3. Contracts that use "imports" will need to have the code ...
2
It's hard to say anything without seeing the code you tried to compile. Since you have already tried the compiler 2. beta version, as a suggestion; compilers spend sometime removing comments etc. from the during the compilation time as explained here.
Are comments included with deployed contracts and do they increase
deployment gas?
No, everything ...
2
A transaction will not be mined without a valid signature, under current consensus rules. Thus, if it has been mined, a valid signature was provided.
This means that you can retrieve a historical transaction, and a historical state trie from just before that transaction, and replay the execution to validate the result.
Moreover, although the signature is ...
2
It depends on what you mean by "safe".
You can confidently derive the source code of this contract by the source code of the deployer. It will normally happen from a statement in the form of new Contract(arguments) and analysis of the deployer contract will leave no doubt about what it does.
It does not mean that the quality of the contract or the intent ...
Only top voted, non community-wiki answers of a minimum length are eligible
