I keep getting " file is damaged " when I open the last version of macminer

any clue?

If you are interested I shared my experience on egpu.io: https://egpu.io/forums/mac-setup/my-experience-with-cryptomining-on-macos/

Right now I got Keccak working pretty nice but I haven't tested out all of them. I'm planning on testing out other algorithm later this week and keep sharing my experiences on egpu.io

Super happy it works on High Sierra Beta with native eGPU detection!

Hey

I just got an eGPU with a RX580 + MBPro 13" over tb3 and was interested to see how the performance would hold up in a mining environment.

I've got it working with nicehash but I suspect that both GPUs are trying to be used for mining. Or atleast thats what I gather from the console. Device 0 being the internal Chip and 1 being the RX580. If this is the case I would like to just use the eGPU for mining and exclude the internal if possible. Is there a command or setting to chose exactly which GPU is used? I can provide more details and console messages if needed.

Cheers

Hi, is there a possibility of the macminer supporting the new coin Signatum? All other options I've tried via wine with no success unfortunately.

Denarius v1.0.4.0 for macOS is available, updated the release links and added the .dmg to the Github.

I see you didn't get any replies.  So though I am a total newb at this, I'll share my experience thus far with Macs and maybe you can share back what you've learned since you posted 2 months ago.

I fist tried minergate.com's mac client and got the following results CPU mining XMR:

Harpertown 2.8Ghz 8 Core Mac Pro (4GB RAM) - 175H/s
Nehelem 2.8Ghz 4 Core Mac Pro (8GB RAM) - 85H/s
Core i7 2.6Ghz MacBook Pro (16GB RAM) - 75H/s 90H/s

In other words, totally not worth it.

I'm just now installing Ubuntu on the Harpertown Mac Pro and will try both Minergate and Wolf's if the Minergate hashrate under Linusx is lower than what reports for Wolf's have been here: https://docs.google.com/spreadsheets/d/1MI-ic0Os25hgGUImW54sUIjZY_pUNQNa_W8Se5pRGBs/edit?pli=1#gid=0

Edit: Unbuntu Minergate on Harpertown Mac Pro - 190H/s

Hi, Did anyone ever figure out how to make the Antminer U3 work at 63GH with MacMiner? I'm only able to get 35gh out of it and I've tried everything!

Nothing but speculation, tor is as safe as it was two years ago
Hey OP, how whould you do phising? wont people be directed to a .onion page?

There are already so much confusion from people about Bitcoin... If you now tell them, that they are making it even more complex, by splitting it into 2 versions... you will be doing more harm than good.

I had a uphill battle trying to explain Bitcoin to NEW people... I can just imagine what they will be thinking now...

We have to make some hard choices NOW.... and this would not have been neccesarry, IF these developers had put their self interest and agenda's aside, and made the success of Bitcoin their main goal.

This will either make or break Bitcoin... We will soon see. 

FabulousPandaCo 2 points 4 hours ago

Thanks for the linkage - FYI I don't personally know any of the individuals on the dev teams, and wrote that article as a result of it not being too easy to at a glance figure out what was going on. I think perhaps Gavin has expressed support for XT as a means of convincing the core team to agree on some important issues they've failed to which have been apparent since at least 2011. I have had some limited contact with luke-jr on github and I used eligius.st but I am not declaring support for any team or individual in this. I do believe however that there are significant issues that need to be addressed, and that a raised max block size (even were it 2MB rather than 20) would be best for now, and the issues regarding maintaining decentralization and/or implementing sidechains should be explored fully, but not immediately forced upon us.


luke-jrLuke Dashjr - Bitcoin Expert 0 points an hour ago

   But the debate over the block size limit and how to manage it has caused some of the best known developers to set up another client for bitcoin, here:

Bitcoin XT actually predates the block size matter entirely, and was forked by Mike Hearn (not a Core developer) to merge some relatively ill-advised things appropriately rejected from Core (because they don't/can't work): particularly, double spend relaying/detection.

   essentially, if you have 1 Bitcoin, after the fork (if you have today's wallet backed up) you will have 1 Bitcoin, and 1 'BitcoinXT', each with independent values based on their popular adoption.

To complicate matters a bit: if you send 1 BTC, you also send 1 BTCXT, and vice versa. Unless the bitcoins being redeemed (essentially chosen at random) happen to only exist on one or the other blockchain.


FabulousPandaCo 1 point 6 minutes ago

Thanks for the response luke, I will update to address and clarify on that, however from what I've read (and I'm not as in the loop as I have been) it doesn't seem that clear cut. Mike Hearn certainly set up the other github some time ago, although it attributes the double spend relaying to Gavin Andresen and Tom Harding. It freely admits not to completely solve the double spend issue, but aims to improve it, could you please expand on the advantages/disadvantages of the implementation proposed in XT?

As far as I can tell, supporters of the changes in XT are willing to allow for increased data usage in order to allow for increased usage of Bitcoin in the short term, whereas the opposition would prefer to allow necessary transaction fees to rise as we approach/hit the max block size ceiling for transactions to be successful on the basis that such data requirements would cause increased centralization. But as it stands we don't have an accepted viable alternative - only a brief whitepaper on sidechains which leaves a lot to the imagination, and would require a significant period of testing and some real world implementation before the community would trust it, and I'm sure you're aware of the fears that Blockstream may result in centralization - can you do anything to allay those?

Gavin also seems to be claiming that his support for the increase in max block size and to a lesser extent the other changes in XT are a call for action on the part of the Core team to adopt some change to max block size whether set specifically or adaptive as that change on it's own is not a deviation from the initial spec of Bitcoin. Surely if that minor change were implemented the risk of a hard fork to XT would be drastically reduced, and it's role limited to a a beta branch of Core?

Regarding the fork, as long as the Core protocol doesn't change significantly and XT doesn't reach 90% adoption it's not going to happen, right? Can we get some clarification on the future of the Core - for instance, is Gavin still going to have influence on it?

I would agree that just allowing the max block size to increase indefinitely is fraught with problems, but problems that are a way down the road and also not a deviation from the Bitcoin whitepaper. For that reason I wonder why Blockstream don't start their own cryptocurrency to start pegging sidestreams to?

I am still a little confused. I have all of my BTC in paper wallets. so if the fork does happen, I can choose what network to import the keys into when I decide to spend them? also what if I want to switch networks? do I just make a new paper wallet and then import it into the other network? I also cant see how both wallets can exist in both networks, since they allow us to have double the coins. will their just be a blockchain.info that shows the balance for your paper wallet on bitcoin QT and a blockchainXT that shows the balance for the paper wallet on the XT network?

Thanks

Thanks for this thread... we need some sanity in here sometimes

As for both options on the table... Both are valid, but why sidechains instead of just increasing block size? Is the usage of sidechains documented enough for it to be a powerful solution comparing to increasing block size?

What about those who are not using QT/XT, i.e. using blockchain.info, electrum, armory etc. ? What would happen to the coins which are kept on paper wallet and p2sh addresses ?