Search content
Sort by
Showing 20 of 56 results by Moshi
You could try connecting to the site through Tor.
Alternatively, I'm pretty sure Blockchain.info defaults to sending backups to your e-mail on a regular basis. When it was down for a few days two weeks ago, I just loaded the backup into Multibit and called it a day.
Alternatively, I'm pretty sure Blockchain.info defaults to sending backups to your e-mail on a regular basis. When it was down for a few days two weeks ago, I just loaded the backup into Multibit and called it a day.
Another solution, if you don't want your computer on all the time, is to get any other PSU and, on the 24-pin cable, splice the green line with any ground. The PSU should kick on when given power, and otherwise work as advertised.
Since you won't be using too much power, pretty much any PSU will do - I've used the cheapest, most off-brand junk for a car radio and other stuff.
Since you won't be using too much power, pretty much any PSU will do - I've used the cheapest, most off-brand junk for a car radio and other stuff.
I doubt there will ever be some big population on mars this century. Enought time to see if Bitcoin will be still alive
Bitcoin will live forever..... Well just the mining stop but its still there...
Incidentally, if mining stops, Bitcoin dies, given it's the only method of propagating transactions. I still don't think it'll be around when Mars is colonized - only because of how long it will take.
Re: error: {u'message': u'TX rejected', u'code': -22} is back HELP
If I understood this correctly, is there any particular reason Electrum consistently forces the use of smaller outputs? And conversely, why doesn't the client notify the user of an insufficient transaction fee? (instead of resorting to an obscure error code)
The obscure error code comes from bitcoind refusing the transaction, not the Electrum client
Fair enough. Thanks for the clarification.
Re: error: {u'message': u'TX rejected', u'code': -22} is back HELP
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.
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.
If I understood this correctly, is there any particular reason Electrum consistently forces the use of smaller outputs? And conversely, why doesn't the client notify the user of an insufficient transaction fee? (instead of resorting to an obscure error code)
Re: snapchat value > bitcoin cap, twitter value X 5 times bitcoin cap
I think "too high" to old users refers to the spike in price and not some arbitrary limit. To new users, from what I've gathered, the relatively high price of a single Bitcoin and confusion over their divisibility seems to scare people away.
Mining Bitcoin on Mars is totally infeasible, as almost all blocks mined on Mars will be orphaned by the time they reach Earth. I have talked about a solution before:
Each planet will have its own locally-mined cryptocurrency (Marscoin, etc), which each have a floating exchange rate to the original Earth-based Bitcoin. Marscoins and bitcoins can be directly traded for each other in order to settle interplanetary trade balances, the only issue is the speed-of-light delay for confirmations (which is unavoidable no matter what). Naturally Bitcoin can't be mined on Mars and Marscoin can't be mined on Earth, but that's not important.
Depends on Bitcoin hashing speed on Mars, if you have more Bitcoin hashing speed on Mars, Earth Bitcoin miners will not mine much
True, whichever planet has the largest hashing power will eventually dominate. Regardless of who "wins", it's not good for Bitcoin as interplanetary currency. Only if the communication delay is negligible compared to the average block-time, will it interplanetary mining be feasible. A coin with a 24hr block-time can be mined on Earth and Mars just fine (assuming a network connection can be established of course).
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.
This could get interesting when miners start hopping planets to take advantage of hashrate and price discrepencies.
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.
Unfortunately, your best bet would probably be to calculate it manually and do some interpolation. Alternatively, a little bit of javascript could conceivably do the same with one of the calculators avaliable: grab the difficulty between each retarget, calculate that number, and add all of the results. Roundabout, but about the easiest I could come up with.
Re: error: {u'message': u'TX rejected', u'code': -22} is back HELP
Good luck then.
So, the problem was with newly mined coins
So, the problem was with newly mined coins
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.
I'd agree here. I was having the same error a few weeks back after my wallet was dormant for several months - at first I thought it was an issue with fees, but some google'ing denied that and redoubled frustration. It took an hour and an Ubuntu installation to get anything working again. I'm not sure I'll be sticking with Electrum after that fiasco - it ruined a trade, but I guess that's partly my fault.
Thanks for the input, but I doubt either is the issue. I've both tried many, many versions of Catalyst with no luck, and can crossfire the cards in Ubuntu with no problems. I'm rather certain this is some driver related problem, but have no idea how I can remedy it after no version works.
I have two AMD 6950s that I use for mining and gaming which were able to Crossfire well originally. After a reinstallation of Windows 7 Professional 64-bit, when Crossfire is enabled, starting nearly any modern game (IE: Metro 2033, Crysis 1/2/3, etc) gives a stop error pointing to the infamous atikmpag.sys. Crossfire still works in Ubuntu 12.04 32- and 64-bit.
I've tried using various versions of CCC - pretty much everything 12.x and 13.x so far - to no avail, netting the exact same problems as before. I'm not sure what else - besides a reinstallation - would help.
For the record, one of the cards is Visiontek's 1GB card, while the other is Sapphire's 2GB "Dirt 3 Edition" card.
Any insight?
I've tried using various versions of CCC - pretty much everything 12.x and 13.x so far - to no avail, netting the exact same problems as before. I'm not sure what else - besides a reinstallation - would help.
For the record, one of the cards is Visiontek's 1GB card, while the other is Sapphire's 2GB "Dirt 3 Edition" card.
Any insight?
Re: Can anyone using a 6870 x2 (dual core) give me some mining specs
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.
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.
It's actually a pretty fair assumption that two 6870 GPUs would be about twice the hashrate of one, given they're clocked identically. That may not be the case (although I don't think I've ever seen a dual-GPU 6870 board), and they may be clocked slightly lower.
Since they're the same cores as the single-GPU 6870, I would say divide the hashrate in the hardware comparison list by the given clock, multiply that number by the GPU clock on the card you're getting, and double it. So long as it doesn't implode or something, that's you're best guess as to the hashrate.
While I can't vouch for mining, I've heard of several and seen one case where mixing nVidia and AMD GPUs didn't cause any silly effects aside from hell getting drivers to work. If you can drive multiple displays with mixed GPUs, I don't see why you couldn't mine with them.
I'm finding myself in a very similar scenario. Incidently, the same people turned off by the $190/BTC exchange were the ones telling me that this was an "illegal nerd currency", all now just writhing to get their hands on them - provided they don't pay "alot" 
I've talked my roommate into looking into the system - enticed by the concept of cheap, nearly-instantaneous transfers of funds after he had waited a few days to pay for Bioshock. Suddenly can't stop mining, and now gawking at the exchange rate. Beautiful stuff.
I've talked my roommate into looking into the system - enticed by the concept of cheap, nearly-instantaneous transfers of funds after he had waited a few days to pay for Bioshock. Suddenly can't stop mining, and now gawking at the exchange rate. Beautiful stuff.
what do you think how many hashes / second a z80 would get?
Considering a Z80 can't draw a parabola on a low-resolution TI-84 display in a reasonable amount of time, I think you're looking at seconds/hash, instead.
That said, I'm somewhat curious as to what an ODroid could do... Mine just kind of chills out as my most expensive alarm clock ever.