Antivirus has always and forever detected mining software as malware. To an extent, I even suspect that file hosting and git repositories may have removed them because they ran automated malware scans and decided their course of action on that. Mining applications are almost all closed source because the developers implement a fee they benefit from, but also to keep whatever makes theirs good away from competition.

There are always risks associated with running closed source software from anon devs that is also detected as malware. It has always been the case and the most we can do is trust teams with a history of development and community trust. They can also be run without admin rights, sandboxed, or closed in by additional security software that supports HIPS/rules on what it can and cannot change. Furthermore because most of the mining work is done on dedicated rigs, the damage from infection or data theft is low, provided you're smart enough not to keep sensitive info on a rig.

If you're looking for open source software, Excavator is in active development by the NiceHash team. But it currently only supports nVidia cards. In terms of a mining software that can run on both AMD and nVidia cards just as effectively, it's hard to beat PhoenixMiner, although some people use specific miners for specific brands of cards to get an extra 2-3% out of them. Again, most of that software is also closed source and the devs are anonymous.

If the software is to be closed source and is well enough protected from tampering, non-anonymous teams would be putting themselves at risk in terms of blackmail, threats or violence from people who would want to hijack it for nefarious purposes such as malware or secretly mining for them. The more popular the miner, the bigger the target.

The crypto world has always been very fast, very technical and perhaps also owing from its crypto-anarchist credos, very anonymous. This has made it very treacherous for the uninformed. Always follow sensible practices on informing yourself, securing your systems, protecting your wallets and sensitive info, and setting up safeguards just in case. I have folder-wide rules on what applications, registry keys, device APIs and file paths the mining software can use. This is both to protect from malicious devs and the possibility of an unknown vulnerability hijacking them. I'm also careful of how and where I store my wallets. You feel much more confident in running something like PhoenixMiner once you know you've done your due diligence.

The scammers are getting more sophisticated. They've apparently found a way to quickly cross 100 activity/posts to make posting restrictions even harder.

Seconded, I am also looking for an answer on this. Absolute Core Clock lowers mining power usage by about 20% and that is already two major players supporting it. Can't be falling behind now!

When a GPU crashes, is there any indication in the log of which card crashed? I normally look to see which one is stuck at 0 MH/s but sometimes the card crashes and then resumes mining normally. Is there an event logged anywhere?

There are many reasons why MEGA would take mining software links down that aren't as straightforward, from hosting servers in China where there is currently a crackdown, to deciding they can't be bothered to check the safety every upload to see if it's legit when so many more of them are re-uploaded altered versions with malware versus only a handful of legit ones.

You could opt for a middle ground, producing your own private key and signing all subsequent PhoenixMiner releases with it, without registering with an official CA to sign that key. You could then post your public key here in the thread's first post, so any future binaries can be verified against it.

Do we have any hashes of the purported fake versions they pushed before they realised something was wrong? I'm not saying they did, or didn't, but I have auto-updates disabled on my mining rig and haven't updated in a month, and on my PC I use Excavator because it has no fee and I have an nVidia card while my rig is all AMD cards. So I went ahead and checked my PhoenixMiner version and all the hashes checked out. What exactly was the malware version?

Hello, could you please confirm tx

d57fa2be1632f04cd856eb7a6d89072e4d3844c0059e535dcf483848450d049f

thank you. <3

Only goatpig could know.

Does it work if you don't do that? Long story short I'm having your exact issue, except my armorydb.exe silently exits instead of hanging. And it does it only if I generate extra addresses.

https://icodaily.net/2017/10/23/bittrex-warning-on-bitcoin-gold/
https://www.reddit.com/r/BitcoinScamCoins/comments/7fwugs/what_are_bitcoin_scam_coins/
https://bitcointalk.org/index.php?topic=2284289.msg26318374#msg26318374

Faceti-va researchu atent cand va bagati la facut -orice- cu cryptomonezile voastre, mai ales cand sunt sume importante in joc. Ca idee generala daca aveti de gand sa va redeemuiti monezile de pe un fork, mutati-le pe alta adresa pe chainu principal inainte sa semnati orice tranzactie.

Pe langa pericolu de wallet-uri cu malware ale fork-ului, e posibil ca pe fork sa nu existe protectie anti-replay - adica o semnatura pe fork sa fie facuta in exact aceeasi maniera ca pe chainu principal, si atunci cand semnati o tranzactie catre o adresa pe fork, semnatura sa fie valida si pe chainu principal pe care va tineti monezile. Adresele de pe aceste chainuri pot arata complet diferit, dar pot transfera in aceleasi chei publice, doar ca schema de hashing se face altfel, si cineva care stie ce face poate ingineri o tranzactie favorabila lor! Chiar daca e vorba de adresa unui exchange si nu iti pot lua banii, un troll poate broadcasta tranzactia pe BTC si sa te lase fara monezi ducandu-le astfel la o adresa la care nimeni nu are cheia privata.

Eu mi-am redeemuit bitcoin goldu pe un exchange dupa ce:
1. Mi-am facut researchu si am vazut dubioseniile.
2. Mi-am transferat BTCu pe alta adresa inainte de orice schimb
3. Am luat un wallet cu oarece reputatie(coinomi) care suporta tranzactiile pe BTG in loc sa il folosesc pe al lor

So if there's another testing build is it gonna be an RC or a CR? (christmas release)

Nay, I ain't using McAffee either.

EDIT: I found something that may be useful. I had generated 22 P2SH-P2WPKH addresses by clicking on the "receive bitcoins" button and another 2000 using compute. However, on the next restart of Qt, it moved ALL those addresses that I hadn't spent from into the P2PKH area, where they looked completely different. The only way I was able to tell was because they carried the labels I had given them. And the unused P2SH-P2WPKH field became empty. They were effectively all converted. I now had 2022 P2PKH addresses and none others.

No encrypted HDD, no NAS, and antivirus already excludes the Armory folder(which cotains both ADB and Bitcoin blockchain) due to some well-known trolling events where ppl deliberately included transaction bytes to resemble malware and flag false-positives.

This seems oddly familiar. By chance did you generate any new addresses from the wallet? And if so, how many?

I already did that thrice. What I've done now is deleted the last few block files from bitcoin core corresponding to about where that recurring 99%-ish point would be(going by the logs), and restarted it with -reindex. Once it's back up to sync I will -AGAIN- rebuild the armory DB.

Another hour spent fruitlessly trying to scan the transaction history for a wallet, at 99% and 28 seconds left admorydb.exe quits and armoryQt says nothing about even a connection loss, it just sits there. I only found in armorycpplog.txt "ERROR - 1486672480: (SwigClient.cpp:61) POLLERR error in readAndWrite", that is just the Qt losing connection to ADB but again - Qt said nothing about it. It will display tray messages about connection to bitcoind being lost but not ADB, which coupled with the ADB's lack of relevant reports, conspires to make these crashes as silent and obscure as possible. Even moreso, when I relaunch everything the history is rescanned from scratch.

dbLog.txt last states "-INFO  - 20:33:49.875: (..\BlockchainScanner.cpp:852) scanned from block #498700 to #499207", whatever it was doing at the time before it dropped and how far it got, and after that nothing. I don't think I have anything more to give.

Created myself a new wallet and after scanning transaction history, armoryDB.exe always silently exits at around 99%. I already deleted the entire ADB twice. I've had issues with scanning transaction history in times past and what frustrates me the most - then and now - is how it just silently exits without any application error window or writing anything in the logs about it. Are there exception handlers missing somewhere? What should I do next?

Thanks for that. I'm going to create a new wallet then.

Sadly I'm not all that clear in the head and I'd be making assumptions based off that and need a more layman-friendly answer... would one private key of one address, and a bunch of public addresses jeopardize the entire wallet's private keys?

ALSO, if that key was P2PKH and I only use P2SH-P2WPKH keys, does it extend to them, or would it only compromise that one branch?