One interesting transfer was to this address:
https://www.blockchain.com/btc/address/bc1qm34lsc65zpw79lxes69zkqmk6ee3ewf0j77s3h it holds 35016.15030071 BTC

If it only targets eth then eth could change their algo.

I's hard to say how much is bluster. Nvidia's claims seem exagerated to please gamers.
I'm sure hackers are already reverse engineering the limiter.

How are they going to force miners to update to the newest driver? Without such mechanism, this isn't really a solution. Also, miners could just try to create their own drivers in the future. And the worst, if their algorithms would detect false-positives during gaming, it could create very annoying frame drops that would ruin the experience for people who just bought a top GPU for games.

IMO Nvidia should create ASICS based on their GPU technology that will far outperform their GPU in mining, to solve the problem once and for all. Releasing dedicated mining GPU is not enough, miners actually seek gaming GPUs because they have higher resale value once the bull run is over.

HOLY SMOKES. 44MH/s on a single P104-100?

I kind of doubt it based on his tenative ETA, but maybe. Reason being, he says he's already gotta update the framework to the same one he uses for his other miners, which I'm guessing isn't a super simple task given how long this miner has been unchanged (during which time he's released quite a few updated to his other miners.) Adding support for Vega that is presentable isn't super simple, either, as optimizations for new ISA extensions do take a bit. This might be made simpler if he leverages some of the more advanced features of the new LLVM/Clang toolchain used for ROCm, though.

Additionally, even if he wanted to rush out a basic implementation of Vega support, he also is at least somewhat mindful of protecting his intellectual property: he won't be able to embed his kernels for Vega like he has done for some of the others (as AMD IL), simply because Vega only works with the new ROCm stack, and there IS no AMD IL used anymore. Since there's really only one GCN version which MUST be used with ROCm, though, I suppose he could simply embed it as ISA like he's done with some others. Plus, then, he has to thwart the common debugging/analysis angles that he's already covered for the old, Catalyst based shit (such as GPU_DUMP_DEVICE_KERNEL, or AMD_OCL_BUILD_OPTIONS_APPEND environment variables.)

So, for him, it's not likely to be a simple and straightforward implement and then run the executable through his packer of choice (I believe this is VMProtect for his Windows based ones, his Linux based ones he uses a stub which loads one of the bin files in the current directory, transforms it using appears to be a custom permutation, and then executes it - this new binary is packed with UPX (I forget which version it is now; also, see footnote.))

Footnote: Claymore, you don't have to respond - in fact, I'm fairly sure you won't - but please, for the Linux miners... at least clobber the UPX signature on the decoded Data3.bin. That really was a glaring inattention to detail, IMO.

There appears to be two versions of Polaris Bios Editor V1.6 ?
The one from https://github.com/jaschaknack/PolarisBiosEditor has the "One Click Timing Patch" option and the other has the option "Apply Ubermix 3.1 Samsung Timings" - both say they they are version 1.6.
I've been using the "Ubermix" version with no problems - can't remember where I downloaded it from.

Does anynoe know what the difference between the 'One Click' and the 'Ubermix' timing are ?
I'll have a go myself and see if I can spot anything - I may be some time figuring this out.