Topic: [ANN] The Definitive List of Mac Altcoin Wallets - page 21. (Read 75331 times)

Works great. You should have your 100DGC, though I had to split it into four payments due to the transaction size limit and the fact that my DGC all comes from P2Pool mining.

Thank you!

Sorry, this was my bad--I left some dependencies out of the app bundle. I fixed it and re-uploaded--please re-download from the link in the OP and let me know how it goes.

OK, this is what I've done:

to take care of the openssl error.

Then I had a similar error:


And yeah, my berkeleydb is version5. So I followed the instructions here:

http://bitcoin.stackexchange.com/questions/3672/trouble-compiling-bitcoind-on-osx-with-homebrew

except that I already had a homebrew recipe for berkeleydb-4 so instead of downloading the older replacement, I did:


Which put the older berkeley-db4 where Digitalcoin expected it.

This led to a trickier one:


Which also looks like a version conflict. I have boost 1.54.0 from homebrew. I tried rebuilding boost with the --with-c++11 flag, just grasping at straws thinking you might have compiled with clang which expected some special support to be built in to boost. Unfortunately that didn't do the trick.

Similar message regarding a litecoin install http://trac.macports.org/ticket/39820
Another here: https://groups.google.com/forum/#!msg/mongodb-user/9hqzGYuPcsA/PUtTCgV94uQJ which suggests finding an older version of boost. Though the final message in that thread says, "fixed via binaries" which is about as unhelpful as can be.

Fortunately there is an older version of boost in brew:


Unfortunately in order to get Digitalcoin-Qt to run I have to link the 1.49 version and unlink the 1.54 version. Hopefully that won't screw up anything else that is already running.

*sigh* in most development realms I find that having a Mac means I have versions from 2010 that are too old to work with the newest source code. With everything descended from Bitcoin I have to find 2005 versions of software. Anyway, next message:


...and this is where I hit the dead end. Any thoughts?

Thank you!

The DGC client crashed on startup for me. Looks like in all my attempts to get QT clients to compile on my machine I may have screwed up some dependencies. Hopefully I can fix this myself, but thought it best to share the report here:


Yeah, OK. I have a brew install of openssl at /usr/local/Cellar/openssl/1.0.1e/lib/ and the default OS X binary at /usr/bin/openssl. I'll start with a symlink to make it look like the Homebrew version is where the binary expects it, and let you know how that goes.

Another round of updates!

• Digitalcoin to v0.2 (see above)
• Bottlecaps to 1.5.0.0
• Gamecoin to 0.8.4.0

Okay, I compiled the latest source from the thread you referenced. The version number in the source code (and hence in the about box) is still 0.6.3.0, for whatever reason, but the code is from the v0.2 archive that baritus posted. The link to the binary is in the OP.

If it works and you like it, my DGC addr is DDxEYrRZ8otUN8ABxooh8ce1RQgSee9PWN - Thanks!

And FYI there is a mandatory update to Digitalcoin: https://bitcointalksearch.org/topic/dgc-digitalcoin-client-version-02-released-mandatory-update-24-hours-289818

I'll put 100 DGC up for the updated Mac binary. It's not much, but maybe others will match it.

Thanks for the heads up. I'll see if I can get the latest version going. Stay tuned...

Hi there. The BottleCaps wallet seems to be version 1.4. I have installed it on OS X but it doesn't seem to ever synchronize with the network. Some Googling indicated there was a fork and there is a newer version (1.5) available? Is this something you folks could update?

Thanks in advance!

Ah, okay, I missed that the first time around.


Yeah, I don't think that these hashing algorithms are particularly hyperthreadable. I'm baffled by your results on the 8-core system, though. All I can think is that the threads on each core of each CPU are contending for CPU cache, but your results in Parallels contradict that.


Interestingly, looking at CPU stats in XRG in realtime while I'm running the wallet's miner shows my main cores maxing out, but the hyperthreaded "virtual" cores almost idle. Totally the opposite of what you see on your laptop. Very strange!

Although I'll add this: if you're getting 120KH/s on your quad-core system, you too might be hitting a bottleneck and might be well-served by trying fewer maximum threads. Yes, that's about twice what I max out at with my dual-core system, but I'm guessing your quad-core CPU is a lot faster than my 1.8GHz i7.

Well yeah, I did try setting the number of threads with the setgenerate command. See above.

A few further tries indicates that there is some kind of bottleneck above 4 threads.

setgenerate true 1: 36Kh/s, 101% CPU (61% idle)
setgenerate true 2: 69Kh/s, 198% CPU (52% idle)
setgenerate true 3: 98Kh/s, 290% CPU (35% idle)
setgenerate true 4: 115Kh/s, 366% CPU (27% idle)
setgenerate true 5: 90Kh/s, 360% CPU (26% idle)
setgenerate true 6: 68Kh/s, 283% CPU (35% idle)
setgenerate true 7: 47Kh/s, 262% CPU (39% idle)
setgenerate true 8: 46Kh/s, 259% CPU (37% idle)

I doubt I'm running out of RAM—I have almost 9GB free with everything running right now. The only thing I can think of is that my slow 800MHz DDR2 RAM could be the bottleneck. But that seems intuitively farfetched.

If I set the Windows CPUminer to four threads (-t 4) and setgenerate true 4 I'm getting nearly 18KH/s per thread in CPUminer plus 48Kh/s in Securecoin for a total of 120Kh/s. For whatever reason I'm maxing out at 120Kh/s.

Confirmed: this is true even if I am running the Windows Securecoin client and the Mac Securecoin client concurrently.

Just for comparison's sake, on the laptop I get:

setgenerate true 1: 37KH/s, 100% CPU (63% idle)
setgenerate true 2: 54KH/s, 198% CPU (39% idle)
setgenerate true 3: 58KH/s, 270% CPU (14% idle)
setgenerate true 4: 57KH/s, 320% CPU (3% idle)

Since this machine has only two cores, this supports your assertion that the addition of hyperthreaded virtual cores does not help. (Which sort of makes sense.)


That is what I thought, but I actually had better results with the Windows Qt client mining than with the Windows CPUminer. Again, there may be a lot more going on. But it is interesting. And useful to know that I may as well not run my CPUs full tilt if I'm not getting anything more out of them. On the laptop I get 54KH/s with my CPU at 80°C or 57KH/s at 97°C. Guess which one is better for the life of my CPU.

Thanks for listening. I think I've established here that I am running up against limits of my own system, whatever those limits are. This does not seem to indicate any changes to the Qt client.

That's awfully strange. I tried it on a quad-core CPU with hyperthreading, and got about 120Kh/s at about 400% CPU usage. I'm not sure what to tell you; one thing you can try is specifying the number of mining threads in the setgenerate command, e.g.
for 4 threads.

Ultimately you'll probably be better off with the Securecoin version of cpuminer, if you can get it compiling--it's way better optimized than any of the wallets.

More info: I just installed on a newer machine (1.8GHz i7, single dual-core processor with hyperthreading) and I'm getting 45Kh/s out of it. Activity monitor reports Securecoin-Qt using close to 300% of CPU so it does seem to be taking advantage of hyperthreading. I don't have any third or fourth cores to allow one app to use more than 200% of CPU.

(I just closed down a bunch of apps and I'm getting closer to 60Kh/s now on the laptop—not sure what the CPU usage is exactly because Activity Monitor itself is one of the apps I closed—closing Activity Monitor gains me about 5Kh/s)

I have in my securecoin.conf but setting , restarting, and doing it from the debug window as you suggest seems to have the same result. I'm getting 45Kh/s and Securecoin-Qt is using about 250% CPU and over 40% of my CPU idle.

If I specify the number of processes () I get exactly the same result. If I limit to one process I'm getting about 36Kh/s and use about 100% CPU with roughly 60% idle.

Those numbers don't make any sort of linear sense, but that's what I'm seeing.

As a reference, when I use cpuminer (non-forked version) to mine scrypt-based coins I can get over 700% CPU if I close down enough other apps. Running Parallels (either running the Windows Securecoin-Qt or the forked cpuminer) the virtual machine uses something north of 600% CPU with 0% idle.

I don't have hyperthreading. This is a dual quad-core 2.8GHz Xeon (Harpertown) system.

I suspect that if I want this to work like I want it the best thing would be for me to look at compiling the client for my system, on my system. And that's a topic for the Mac wallet development thread. :-)

That's strange; I just tried the Securecoin-Qt miner and it's using all my cores (or at least all my physical cores--it doesn't seem to count hyperthreaded "cores").

How are you starting the miner? I'm opening the debug window and typing:

Wow, maxpower, that was fast. Thank you!

Running smoothly on my Mac Pro. The only issue I have to report about it is that the built-in miner doesn't appear to try to make use of all the CPUs. The Windows version (running under Parallels) got around 110Mh/s; the Mac version gets 35Mh/s and Activity Monitor reports lots of idle CPU.

That's only an issue because I haven't successfully compiled one of the forks of cpuminer. But using your Securecoin port is still a huge improvement. When I was running the Windows cpuminer (under Parallels) against the Windows Securecoin-QT I was getting 90-100Mh/s. Running that same Windows cpuminer against the Mac Securecoin-QT I'm getting 120Mh/s. Admittedly a somewhat surprising result but until I can get cpuminer to compile this is the best setup so far.

So once again… thank you!

UPDATES:

• NEW: Securecoin 0.8.3.0
• UPDATED: Worldcoin 0.6.4.5
• UPDATED: Gamecoin 0.8.3.1

I got it, thank you very much!

I'll take a look at Securecoin as soon as I have a chance.

Matched ryanb's 1000 ZET with 1000 ZET of my own, sent from the Mac wallet.

If you don't receive it, let me know and I'll file a bug report.