Show Posts
|
Pages: [1]
|
Even if the approach isn't perfect, I think it deserves some credit. At the very least, it tells what time-span are provably insecure. The reverse is not true (aka provably secure); but this knowledge is still of interest for the community. In particular, it will ultimately helps a bank to position itself as value-added middleman to speed-up transactions.
My 2cts on the question.
|
|
|
I have tried to start a 2nd bitcoin instance on Win7 (v0.3.24-beta of the bitcoin client); and the application silently terminates. Instead of telling me what has gone wrong, it dumps the following into debug.log
Bitcoin version 0.3.24-beta OS version Windows NT 6.1 (build 7601, Service Pack 1), 64-bit edition System default language is 80 French_France.1252 Language file locale/fr_FR/LC_MESSAGES/bitcoin.mo (French) Default data directory C:\Users\JoannesVermorel\AppData\Roaming\Bitcoin Existing instance found
It would probably better to have a message box telling Bitcoin client is already running, please close this instance first to open a new one.
My 2cts on this subject,
Best regards, Joannes Vermorel
|
|
|
On Win7 64b with Bitcoin 0.3.24-beta, when I try to launch the Bitcoin client against H:\ - a mounted Truecrypt container - the application crashes. It would be better to provide a more insightful message. I am pasting below the content of debug.log. (not sure if it's the right way to report bugs, don't hesitate to correct me)
[addentum] When I move wallet.dat from the root to a subdirectory, aka, H:\w, then it starts working. Odd.
Best, /jv
************************ EXCEPTION: N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_10filesystem 22basic_filesystem_errorINS3_10basic_pathISsNS3_11path_traitsEEEEEEEEE boost::filesystem::create_directory: Permission Denied: "H:\" C:\Program Files (x86)\Bitcoin\bitcoin.exe in AppInit()
************************ EXCEPTION: N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_10filesystem 22basic_filesystem_errorINS3_10basic_pathISsNS3_11path_traitsEEEEEEEEE boost::filesystem::create_directory: Permission: "H:\" C:\Program Files (x86)\Bitcoin\bitcoin.exe in CMyApp::OnUnhandledException()
|
|
|
Bitcoin really ought to offer and default to using deterministic wallets. Agreed very much. I was quite surprised to discover this feature after muddling through a lot of very geeky documentation. People can't be expected to comprehend this sort of quirks.
|
|
|
I second the idea of mBTC and uBTC, though of the same thing on my side actually.
|
|
|
It seems that a fresh wallet.dat is around 140kB, but AFAIK it contains already 100 keys. In order to secure an offline wallet, I see two very distinct threats: 1- getting the wallet stolen 2- losing the wallet
The easiest way to address No1 is to bring the wallet offline. Yet, suddenly, it becomes a lot harder to end-up with super-durable storage.
At 140kB, printing the wallet is rather cumbersome, but assuming that it could be brought down to 1.4kB (with only 1 key), it would be much easier to backup, possibly through super-naive Base64 encoding combined with plain text print (and OCR for recovery, with the option of doing it the manual way if OCR fails for whatever reason).
Are my numbers correct? Any thoughts in providing such an option to produce such thin wallets for the sole purpose of offline saving?
Best regards, Joannes Vermorel
|
|
|
The strongest way to secure a bitcoin wallet consists of create it offline and keep it offline.
As far my understanding goes, there is no way to check the balance a wallet without retrieving the transaction history. Hence, it should be possible to retrieve all transactions on an unsecure networked machine, and then to copy the transactions to a portable drive, and then re-run the Bitcoin client on a secure strictly offline machine to assess a somewhat not-too-old balance value for wallet.
Is my understanding correct? Is there smarter ways to achieve the same result?
|
|
|
In all honesty, I think the Mt Gox attack is going to be good for BTC in the long run.
Agreed, attacks can and will happen. It's interesting to see that bitcoin is already quite resilient in this respect. The more problems are faced and addressed, the more trust there will be in the future. As far security goes, nothing worse than a seemingly unchallenged system.
|
|
|
Thanks, this was what I was guessing.
|
|
|
Sorry for the naive question, but something that is still somewhat unclear in my mind is what happens to a transaction targeting my wallet (aka to one my addresses) if my bitcoin client is offline.
Well, for the duration of the offline status, it's very clear to see that nothing will happen which is just the nature of the bitcoin network; but what about the reconnection time?
I am guessing that the network provides some sort of catch-up mechanism, but I would be interested to understand better how a given wallet after of period of offline activity gets updated to its latest BTC value.
Thanks in advance,
Best regards, Joannes Vermorel
|
|
|
Hello, I am running a SaaS company (2nd picture down starting from the top), and I am considering accepting bitcoins for our service. We might need to add a few enterprise feature to the client UI though :-) Best regards, Joannes Vermorel
|
|
|
|