Quote from: Abdussamad on July 17, 2014, 07:49:50 AM

Quote from: shorena on July 17, 2014, 06:58:13 AM

Quote from: btchris on July 17, 2014, 03:31:35 AM

Quote from: doldgigger on July 16, 2014, 09:45:43 PM

Hi!

Is there any wallet software which guarantees that private keys are always committed to disk (using appropriate kernel primitives - there must be no chance that the key is still waiting in a write-behind cache) before being used on the network?

Thanks!

This answer is sort of cheating, but any deterministic wallet (Armory, Electrum, MultiBit HD) should qualify (even if it's not because they do so explicitly), assuming you do a reboot or a sync after initial wallet creation.

Electrum and Multibit are written in Java IIRC, thus AFAIK you have no control over the memory. So while a reboot is a solution to wipe the key off memory, OP was (if I got that right) talking about the moment before you send a TX. You need the private key in memory in order to sign the TX. Then the signed TX gets broadcasted over the network. OP wants a wallet that makes sure the private key is off of memory when the TX gets broadcasted. A reboot would maybe work here, not sure how e.g. bitcoin core handles a reboot just before the final confirmation ("are you sure you want to send x btc to y?), but I doubt it will just continue like nothing happened.

@OP any Java is not an option. I might be mistaken in my Java knowledge, but AFAIK as a Java dev you do not have sufficient control over memory to ensure this. Apparenty [1] you have to go out of your way and rewrite the data that previously stored your key. Since most wallets are open source you can check if they do that.

[1] https://stackoverflow.com/questions/6473352/java-security-how-to-clear-zero-out-memory-associated-with-an-object-and-or-e

I'm reading the OP's question in a different way. He wants to ensure the private key has been written to disk so that if there is sudden power loss you don't loose bitcoins. Sort of an atomic operation. I don't think he's worried about some malware reading the keys from memory. If you have malware it could just as easily read the keys from disk.

(Also, electrum is coded in python not java. Your point about lack of low level hardware access stands, though.)

Yes. I am currently more concerned about reducing the risk of key loss. I think the client should not run in an environment which makes it easy to sneak in malware anyway.

I also don't think the client I'm looking for would necessarily degrade security. The keys could still be written to disk encrypted.