Topic: Bitcoin wallet QT any better for mac? (Read 2979 times)

I've had this problem, but only if my laptop runs out of power and shut offs without going to "sleep". If I correctly close Bitcoin-QT and I wait for it to close completely there is no issue in my case.

Well I have a pretty new (late 2012) iMac, and I'm pretty sure that it's not broken. But thanks for the useful response 

In other news, as World has found, 0.8.4 seems to have fixed these problems for me now

or... there's just an issue with Mac that is fixed in 0.8.4. Your experience alone can't speak for every possible machine configuration.

I think your machine is broken.  I've NEVER had Bitcoin-Qt do that, across several machines.

Bitcoin-Qt 0.8.4 works well without any problems on OS X 10.8.4
Thank you dev team

btw:here is also a good article
http://thegenesisblock.com/bitcoin-0-8-4-update-provides-security-improvements/

Sorry for the late reply, went to Notting Hill Carnival and things got a little bit out of hand!

Anyway, blockchain finished downloading with 0.8.4RC2 while I was away, I have just got back and closed down Bitcoin-QT, restarted the computer and re-opened the app: NO DATABASE ERROR.

Hooray, perhaps this app is now really slightly more suitable for those running OSX now?

Edit: Database Corrupt again.

Thanks for responding ThomasV, I agree with everything you've said, and I'm super happy to hear that you're thinking about multiple connections in electrum. That I failed to elaborate here and point out the massive improvement electrum is over webwallets was only because the user here was already using Bitcoin-qt and was being lobbied by one of your (well deserved) fans.

I plan to add queries to multiple servers in Electrum, in order to select the longest blockchain with SPV, in the coming months; this has been on my list for quite some time.

Electrum will never be a full client, and I fully reckon that it will never be as safe as bitcoin-qt with respect to certain type of attacks. However, my goal here is to provide the highest possible level of security that it is possible to have without downloading the blockchain.

I wrote Electrum because the other option that allows you to access your coins instantly, called "web wallets", is much less safe than Electrum, and has been the victim of all sorts of hacks. If you simply say that Electrum is not as safe as bitcoin-qt, without giving more explanations, you are just steering users towards javascript web wallets, and I guess that's not what you want. The demand for a solution that lets you access your bitcoins instantly will always be there and we need to address it properly.

I agree that querying multiple servers in Electrum needs to be done, and could have been done earlier. I have not done it yet because I have had limited time, and I am adressing the most pressing issues first. The security of a bitcoin client includes multiple aspects, and we need to address them all. When deciding which issues to address first, it is important to look at the facts (what are the actual security flaws that have caused some users to lose bitcoins). With this criterion, the two major causes of bitcoin losses are the lack of a deterministic wallet in bitcoin-qt (because users cannot do regular backups), and the use of hosted wallets (mybitcoin.com, instawallet, and I am sure that others will follow).

After the last block checkpoint has been reached, multithreaded signature verification will be enabled. So there should be no bottlenecks from the CPU. The biggest bottleneck is often network (slow uploading peers or slow download) or disk. Disk bottleneck can be reduced by setting "dbcache=512" in bitcoin.conf (or whatever large value you want).

I am synced up to block 240653 so far, so hopefully tomorrow morning I should have an idea of whether 0.8.4 RC2 has helped me (specifically) on OSX.

Just a slightly off topic question, does loading blocks from disk (bootstrap) use GPU? CPU? Single core, multiple cores? etc... Basically I am disappointed that it took me at least 9 hours to load my blocks from disk, before any downloading even started....

Has anyone submitted a pull request to make Electrum check all the servers against each other (increased sync delay, but nowhere near as bad as full blockchain download), and throw a red flag on the one(s) that don't match?

Not sure what to say about the second one, other than having a random set of addresses generated in the background every time for it to query, without private keys.

With moderate cost a hacked/rogue/network-intercepted server can tell you've that you've received payments you haven't really received, including payments of coin that doesn't really exist. Your client also sends its of addresses up to the server, so you lose your privacy towards it.

Any 0.8.4rc results on OSX yet?

Interesting.  I'm still running 0.8.1.  Perhaps I'll hold of on upgrading for a while longer, and see how 0.8.4 is.

Thank you for this.

I use Bitcoin-QT on OSX but on a (well power-supplied) iMac, so I do not believe that these issues are anything to do with power supply for me, but I still have corrupt database probably the last 4 times I tried to re-open the program (after successfully re-downloading the blockchain about 4 times)...

Have downloaded the 0.8.4 test DMG and it is currently importing blocks from disk (bootstrap.dat) and then after it finally catches up to the present, I will shutdown the app (properly) and will see for sure if 0.8.4 brings any improvement at all for me...

For the record, I do not think that my database has not become corrupted on shutting down (or re-opening) of 0.8.3 a single time yet.

How so, if you import your private keys, use a >30 character random letter, case, number, symbol passphrase with spaces, lock out all OS randomizer-generated seed addresses, and scan for keyloggers every run? Not talking about offline Armory (ultimate security?) here...

Electrum is categorically not "just as safe".

There is a test build of Bitcoin-QT now with fixes which may fix the corruption on unclean power down on OSX. It seems that OSX violates posix and provides an fsync() that does nothing. This fix almost certainly fixes a major cause of corruption on OSX, though there may be other ones.

Electrum

I strongly advise against doing that. You will be exposing yourself to all sorts of unfixed vulnerabilities. If I remember correctly, the reason why leveldb is wacky on Mac is because the ACPI wasn't implemented properly by apple. Ensuring a clean shutdown like DannyHamilton suggested will probably help.

I have gone back to a version that used BDB, as leveldb was just too flakey.