Bitcoin will live forever..... Well just the mining stop but its still there...

The obscure error code comes from bitcoind refusing the transaction, not the Electrum client

I've encountered this problem numerous times with old coins, but I've always been able to send regardless. I'm thinking this section is in need of an FAQ.

I suspect the issue may have to do with each Bitcoin wallet containing a unique set of unspent outputs. We could conceivably work around this on the client by forcing Electrum users to select higher than average fees or forcing prioritization of larger unspent outputs, but the way it works currently, users have more control over how coins are spent.

In any case, if your wallet gets stuck, consider taking the following two steps:

1. In the Receive tab (expert mode on), right-click on an address with more coins in it than you're trying to send, and click "Prioritize". Resend. This isn't especially fullproof if you've been reusing the same address to receive micropayments, but you probably haven't been doing that.

I'd estimate just doing step #1 has worked for me over 75% of the time.

2. If step #1 fails, *increase the fee*. Resend.

You should be okay. I don't think this is overly costly in terms of time or money, but we could conceivably handle the error in the GUI more gracefully, so that users aren't left with an indecipherable error code without any hint as to how they may work around it. A link to an FAQ at the least may help. I've been meaning to come up with one myself. Lots more documentation is needed. A significant amount of work has gone into the upcoming major release, and the Electrum community has really been innovating as of late on all aspects of the client.

Again, I suspect this "type -22" issue is encountered because each Electrum wallet history is unique. If you run Linux or Mac, on the command line you can check your wallet's unspent output tree for yourself by running `electrum listunspent`. You may find that your wallet has a higher number of low-value unspent transactions. You should be able to work around this in the GUI by either increasing the fee or prioritizing an address with a larger unspent transaction 'attached to it'.

I profusely apologize if this error cost you a trade. It should be an avoidable uncommon annoyance kind of thing now that you know how to work around it.

Using bitcoins as interplanetary currency has been discussed here before, several times.

The only method that makes sense to me is for each planet to have their own version. Travelling from earth to Mars? Sign in to your local exchange before you go and trade some bitcoins for Marscoins. Mining bitcoins would only work for earthlings and mining Marscoins would only work for Martians.

No, I've meant to do it comfortably, with some database with historic difficulty, which will extrapolate the projected difficulty for each day in the past. You enter the start and end date, and the hashrate. Optionally the power consumption, but it's easy to calculate manually since it doesn't change through time. There are no other variables, you should get how much BTC is mined in that period.

I would say the problem is with the client and not with the newly mined coins. The two other clients I have used don't have this problem.

Wow thanks for the reply but you sadly posted nothing relevant to my question.

It makes no difference to me if we talk LTC or BTC as BTC is generally 10x that of LTC.

I am not interested in single core 6870 stats as those are easily found.

I do not want to make assumptions that a dual a core is double a single.  That is why I made the post.

I guess a screwed up by making the assumption that I had checked the comparison pages and found nothing that people would know I had already checked the pages you linked.

See what assuming does.

what do you think how many hashes / second a z80 would get?