Click on the contract you want to delete. On the contract page, hover over the name. You see a trashcan. Click on this to remove the contract.
EDIT: As noted by @Vesa, you may not be able to access the contract as Mist freezes. What OS and version of Mist are you using.
I have had some problems with Ethereum Wallet 0.7.2 that are not present in 0....
I saw this when my blockchain wasn't fully synced. The contract was expecting a string to be returned, but since that string hadn't been set yet it was returning null, which would blow up on parsing.
I believe the same thing could happen when pointing to an address that doesn't actually implement that API. If the fallback function doesn't return a string ...
The issue was the following:
/// TODO: careful
Apparently /// is treated specially by the Solidity compiler and lead to the error.
Removing it fixed the issue.
comments added with /** my comment */ also lead to the error. Notice the double asterisk at the start of the comment
Yes, wallet files can be corrupted however, if the wallet was corrupt, you would not be able to decrypt / access it, so that is not the issue.
I'm waiting on kvhnuke to get off work to see if he can figure out what else would be causing this issue beside (1) connectivity issues and (2) firewall. The only time I have encountered the "Generate Wallet" button ...
This bug was apparently due to the fact that:
After calling eth_getFilterChanges testrpc reports the events, and forgets that it reported it for current block, so when the next eth_getFilterChanges happens, testrpc reports the same events again, and again, infinitely, until the new transaction(block) happens, then it starts reporting the event from new ...
From the Github issue:
The BigNumber() is not a base 16 number error can happen in many
cases, yet the causes are not necessarily the same. I believe the
original post's issue is with using Events that index on "string"
types, which I'm running into as well. If my contract event marks a
"string" type as "indexed", i get the same error. But if I ...
This is an issue with windows, which is already fixed in geth#develop branch. Please wait for one release after homestead. This one will then include the fix.
Optional you can build from the develop branch yourself.
I had a similar issue. If you are running in a virtual machine. Make sure you allocate enough ram memory. I used 800MB initially and mining did not work (Hash rate was very low). Allocated 2GB of memory and it worked fine.
The cause of this is probably a corrupt database, itself caused by Parity having previously been shutdown in an ungraceful manner.
The error you're seeing is covered by issue #2201, but was fixed in #3020. I'm struggling to see which version the fix went into, but presumably not v1.5.0-unstable, which is what you're running.
The recommendation in the notes ...
Opened an issue here, github, ethereum, solidity, issue 1731: https://github.com/ethereum/solidity/issues/1731
If I understand their process correctly, original issue 1731 is closed by issue 1737 which is now merged. Possibly the compiler is going to emit an error for this sort of thing in the future.
Both thumbs up for the devs!
Using $ meteor add ethereum:tools worked for me. As you may see below, it added web3. Thanks
3stack:bignumber added, version 2.0.0
amplify added, version 1.0.0
ethereum:tools added, version 0.6.0
ethereum:web3 added, version 0.15.3
frozeman:persistent-minimongo added, version 0.1.8
It seems you have an issue with coloured output in your geth client. The ←[31m0←[0m are colour codes which were not interpreted by your terminal. However, if you ignore everything between ← and m you will see there is a 0 in the middle of that snippet, which tells you your balance is 0.
To find out when you will recieve ether, please consult a mining ...
Using Ethereum Wallet 0.7.3 with geth 1.4.3-rc solved the IPC Issue for me.
For that geth needs to be downloaded from https://github.com/ethereum/go-ethereum/releases since the geth version shipped with Ethereum Wallet 0.7.3 is 1.3.6.
I just encountered the same issue yesterday trying to send ethers to TheDAO.
It's an issue with the IPC connection. See my answer to Is the Mist Wallet stable? for details on how to diagnose it (Mist console).
To get Mist working so you can send your transactions, start Mist check the Mist console (Developer -> Toggle Developer Tools -> Wallet UI). You ...
There is a bug in 0.7.2 (as well as some previous versions?) that seems to occur when you use the "send everything" function to send to a contract.
If you send everything but 0.1 ETH the transaction should go through.
There is a separate syncing bug that seems to be occurring quite frequently with Macs. Some people have had success with the following:
Yes, unless you have a specific need to build from source yourself, I would agree that you are better off just using the PPA.
Trusty is a bit of a pig for us to build against, because many packages are so old there now, so using OUR binaries will give ...
(This page will be reorganised when this problem is solved)
@spraff, looking at your latest data:
Miner produces this output when started with
geth --networkid 1100 --maxpeers 5 --mine --minerthreads 1 -rpccorsdomain "*" --datadir /ethereum/.ethereum-test-miner --port 33301
And IPC server produces this output when started with
You are using the wrong command, the command is coinbase, not eth_coinbase.
I suggest to use this code:
eth = Ethereum::IpcClient.new
This will automatically use the default path to get geth.ipc
And this will return your coinbase.
You can see that this line, used to create the new method, is not getting the first part of ...
This is often caused by a corrupted database and can be solved by resetting it completely with:
parity db kill
This wipes the chain and the state and causes a full resync, but enables you to use parity again.
There seems to be an open bug related to the issue-issue-3056
The present solution which works for me , I run folowing command before mining again
geth makedag <blocknumber> <ethash dir path>
then start mining again.
You can solve it by removing the word public from the mapping.
The storage structure itself is acceptable and can be expected to work. However, the "free" getter for such a structure is not implemented in the compiler.
It appears you are right about a breaking change, given that it compiles without complaint under 0.4.25. Possibly another kind soul will ...
We've seen occasional reports of such behavior, alas given that it needs 2-3 days to crop up we haven't been able to reproduce it ourselves (I personally have both main net and test net nodes running 24/7 for weeks and didn't see sync issues as of yet).
Since we can't reproduce it ourselves, could you help us out in doing a repro? To do such a thing we'd ...
I downloaded the binary from here and it works on my system (OSX El Capitan). Mix is under hard development as I understand so a thing might be working today, but broken tomorrow. Just have a bit of patience (I know it's frustrating ;) ).
If that doesn't work for you, maybe you could also try homebrew. Haven't tried it myself but it should be as easy as: