That makes no sense.

Why would you go to such drastic measures when you can encrypt your wallet with a passphrase using the bitcoin client?
Choose a decent passphrase and you're good to go.
Just please make sure your machine stays malware-free, ok?

Remember that if your main machine gets infected, a VM running inside it might not protect you.
A VM can be used with great success to contain a threat, not to keep a threat already present in the parent machine outside.

There is no gain in keeping the block chain on a volatile FS and re-downloading it all the time.
Keep the block chain on the persistent FS and limit your worries to the wallet file.

Also, why make the wallet file read-only??
The client will want to write changes to your wallet with every transaction you make and "read" is the only privilege the malware really needs.


If built-in AES encryption doesn't seem enough, you could always use TrueCrypt and mount your Serpent-Twofish-AES-encrypted wallet using the command line.
Alternatively, you could keep the wallet on a LUKS-encrypted volume. This way you can have multiple keys and revoke them if necessary.
Or, use the good-old gpg for securing the wallet further.
There are countless possibilities.

Funny you should say that. DeathAndTaxes and I were helping a guy just last night and -rescan fixed his problem (https://bitcointalk.org/index.php?topic=58610).

Naturally if your machine is crawling with malware you've already lost the war. Only multi factor authentication (multi-sig) can help you.
That being said, encryption by default is VERY useful because an encrypted wallet can be much more safely propagated defending it against data loss, eg. it can be uploaded to the internet and the attackers won't be able to breach it provided the passphrase is half-decent.

A great idea but the user needs to have encrypted the wallet in the first place for that to work. We don't want to rely on some hard-coded default encryption passphrase now, do we?


I only posted this here because the discussion had already watered down but you are 100% correct Luke.
I request the Mods kindly split this subdiscussion into a new topic, please.

That's one way to skin the cat. Mighty decent of you to start your adventure with these forums by posting a guide.
Quite a few guides have been already posted but the newbies tend to be terrible at using the search function.
Good job!

MtGox, obviously.

You're doing just fine with your English.

Most probably, someone made a mistake (typo) registering a bitcoin address with their pool.
It's cryptographically improbable that their client would generate identical private key as yours.

Mike, it's still going to be a cat and mouse game, as all security is.
Of course, raising the bar is always desirable. Common multi-sig deployment will render the old attack vectors ineffective.
However, we can rest assured that the bad guys will bring themselves up to speed and keep mounting increasingly complex attacks.

I do believe, however, that it's not inadequate security that's hampering wide-scale Bitcoin adoption but excessive technical issues with the client:
(1) slow initial block chain download.
(2) UI deficiencies (please put in a "Rescan" button somewhere. Non-technical users can't be reasonably expected to user the --rescan parameter).
(3) lack of wallet security (wallet encryption isn't offered by default, why?).
(4) no automatic wallet backups by the client (understandable in the light of (3) as unencrypted wallets should never be automatically backed up).

I'm sad to say these relatively MINOR issues do seem to have a heavy negative impact on the overall impression of the client.

Being active on the Newbies and Support subforums, I hear those issues being raised time and time again by very non-technical users who install the client and expect everything to just work.
They hear about the bitcoin PROTOCOL being secure and confuse that with client-side security (data theft/loss).

I'm writing this here hoping to raise these issues with the core developers.
Very little work put into purely cosmetic issues can make a lot of positive impact.

Dude, what's your gpu clock?
As I told you, any third-party program (like cgminer) is able to set memory to gpu core clocks minus 125MHz. If you OC'd to 930, you can easily set memory at 805.
It's just impossible to go lower than that.

Please don't mess around with trixxx as that's potentially lethal: this card sports a fully custom VRM, god only knows what values should be loaded into which registers and how they are interpreted bt the card's BIOS. In theory, you could unwillingly set GPU core to 1.5 volts and fry it alive.

Aren't alternative currencies supposed to be a test-bed for a whole range of ideas (even if some of them are crazy)?
Even if there was a lot of trouble with that subforum lately, I don't believe it should be closed.
Especially when users can hide any part of the forum they don't wish to participate in at will.

Your own old posts?
Profile -> Show the last posts of this person.

PM sent.

I'd just like to point out that if those are your employer's machines, you can get into a shitload of trouble running a miner on them.
Only run miners on machines that you own or have explicit permission to use for mining purposes.

So, we're basically going into higher levels of abstraction, just like with programming languages or frameworks.
That is a definition I can agree with.

What I had in mind when countering your post was:
Let's look at bitcoin protocol as a class.
It is reasonable that simplicity at the high-abstraction (public) level is paid for by greater amount of work and complexity being done at the invisible (private) low-level.
Not only can't low-level bugs usually be fixed (at best, they can be mitigated) at the high client-side level, but also the more complicated the low-level becomes, the harder it is to analyze it for flaws.
Thus, the overall complexity does not change, it's just shifted down.

Naturally, I believe we need multi-sig. I'm also confident the core developers will implement a decent and well-scrutinized approach.


EDIT::Some minor wording issues fixed.

As I already said, no one is interested in maintaining two pieces of code. The developers have much more important issues on their hands.
Version 4 client can't even filter the transactions according to user-specified criteria. It's gone past its prime and has been shot and buried.

Obviously, you're going to have to put some time in and do your homework yourself.
Read the Pools subforum for your own best interest: https://bitcointalk.org/index.php?board=41.0

As a new user, I'd advise you stay away from any proportional pool.
The reason is, you'll be one of those unfortunate sheep pool-hoppers thrive on.
Although bitcoins.lc does not publish their hash-rate graph, I'd fully expect it to look much like this one: https://bitclockers.com/statistics
This "heartbeat-like" pattern is nothing but bad news for the steady, 24/7 miners.

I've been mining on Eligius for months and have nothing wrong to say about the pool.
Just be advised that the owner has lately been a controversial and polarizing individual. Nevertheless, he is a highly skilled coder.

Having been basically abandoned by its creator, ArsBitcoin is to be avoided.
More details here: https://bitcointalk.org/index.php?topic=18567.880

No problem Jordan.

I fully expect this matter to keep popping up as simply installing 5.1 over 4 keeps the old bitcoin.exe intact.
All shortcuts will still point at the old executable.
I suppose the 5.1 installer should in a clear and comprehensible way recommend uninstalling version 4 client first.

Superseded with bitcoin-qt. The less code there is to maintain, the better. Why keep the old, clunky interface?


Such behavior ill-advised, especially for someone having posted just 12 times before.

Now now, DAT, implementing either P2SH or OP_CODEHASHVERIFY will hardly make the system less complex, would you agree?
Other than that, you're right on point.

I never even partook in this discussion because it's over my head as a mere miner.
Unless someone takes the time to study the code and do extensive formal algorithm analysis (we're talking of a huge amount of time here), the intricacies of changing the protocol are far over their head.
The concept of that poll is therefore laughable.

I don't like seeing Luke go crying wolf and turn to the general forum populace⁽¹⁾ for support of his cause.


(1) why else would he post this in Mining instead of Development & Technical Discussion?

This is far from expected behavior but such outlier situations do happen to all exchanges from time to time.

My worst snafu was with Intersango when a transfer wouldn't show up for a week :<
Apparently, they'd messed up by setting the transfer status to sent (so they thought everything was fine) without actually launching the transfer itself.

In general, I'm very pleased with how MtGox operates.
Keep your ears up, mate

Don't worry, your BTC will get to you... eventually. I'm not sure the support is active during Weekends...
MtGox may be a little slow sometimes but they do NOT cheat their customers.

(1) This card allows up to 125 MHz difference between core and memory clocks.
         You can set the memory clock to gpu_core clock -125.

(2) Yeah, you can forget RBE tricks
(3) Only ASUS smartdoctor is able to modify the voltages.

ASUS have outdone themselves in going full retard custom with this sodding thing.