Looks like the "DDoS" on the network might be submitting blocks to the network that appear to be ~1 minute in the future, causing clients at the correct time to believe they have a block with an invalid time for a while. Not sure if this would prevent them from submitting a block if they found it, but certainly interesting.

The only thing we lost when that server went down was the calculatordemo. All of the Curecoin 2.0 code, whitepaper, SigmaX, etc. is all backed up in multiple locations (although the whitepaper will be massively overhauled before launch).

Of course! Although as usual, no promises (especially since I'm incredibly busy on my own projects, and I'm traveling next Sunday to Money 20/20), but I don't envision the OpenCL implementation being too difficult.

Oh, the nodes themselves aren't identified by the miner name, only the block. You can't tell the difference between the miner him/herself, or just a legitimate node relaying their block. DDoS traffic wouldn't be 'tainted' in any way that anyone could correlate with a miner identity.

Yeah, this is the part that a lot of people don't realize. There surely are people who make fantastic profits in crypto, but they also take on significant risk, and devote significant time/talent. And in the end, large farms increase the hashrate, help the security of networks, and cause the token to become more scarce, making the token more valuable and validating the network's goals by putting time, effort, and capital behind investing in it.

At the same time, it's always unnerving when one party is known to control the majority of a network's hashrate.

People who talk about ways to "block" (ha) certain individuals from participating are looking for short-term, hackish solutions. Playing whack-a-mole with actors on the network only adds centralization and forces those actors underground. If we had a way to reject blocks labeled by "ocminer*"... who makes that decision? How is that enforced? Is it a client update? That'll cause a hard-fork because it changes the consensus rules the network is enforcing (clients who don't update will accept ocminer* blocks, clients who update won't accept them, so the clients who accept the update will be on a different blockchain). If clients are already built to allow enforcement of these rules, then someone has to have the authority to "tell" the network to do this. Is it the developer, who sends a signed message to the network which says "block blocks from ocminer*"? Is it distributed voting (which would be near-useless if a party controls the majority of the network's consensus anyhow)?

And even assuming we could enforce a rule like this without issue, the individual or group making the ocminer* blocks would just switch to another name. Or more likely, they would switch to several, apparently-unconnected names to evade detection.

Here is a grossly-incomplete list of design considerations of a permissionless, decentralized, distributed, trustless blockchain:
1. There is no reliable way to determine whether an individual or party is or is not active on the network at any particular time (other individuals could be working on their behalf to perform a proof-of-liveliness, etc.)
2. There is no reliable way to determine whether multiple nodes are controlled by a single individual
3. There is no reliable way for the network to block IPs, geographical areas, OSes, etc.
4. There is no reliable way to limit an individual or party to only one node
5. There is no reliable way to limit an individual or party to only one network identity (like an address)
6. There is no reliable way to limit an individual or party to a certain hashrate
7. There is no reliable way to determine whether a particular network identity is owned by the same individual or party as another particular network identity

Note that all of the above are possible if you're willing to sacrifice decentralization, trustlessness, permissionless, etc.

Also, that doesn't mean that there aren't ways to encourage certain behavior, just no way to require/enforce it. In general, it's much easier to encourage a party *to* do something than to *not* do it.

Yeah there certainly aren't 300+ ocminers, unless he/she's using the same name on multiple rigs.

I'm seeing:
ocminer101
ocminer102
ocminer104
ocminer105

ocminer122

ocminer131
ocminer132
ocminer133

ocminer201
ocminer202
ocminer205

ocminer261
ocminer262

ocminer281
ocminer282
ocminer283
ocminer284

ocminer339

And some others, but notice the clustering? They probably have several rigs, and they just name each GPU in the rig sequentially (so ocminer281, 282, 283, and 284 are likely all cards on a 4-GPU box, etc). Obviously just speculation, and people are free to name their miners whatever they want so this isn't necessarily the case. But there's not 300+ ocminers, the names are quite spread-out in that range.

Due to a lack of time, it'll probably end up being the same method as the NVidia cards, but I'll also write a super-simple Java proxy that connects to the 1.0.7 RPC and creates the mining files that the file-based miners need, and then ferries the results back to PascalCoin's RPC.

So it'll work with 1.0.7, but you'll need to run a Java intermediary. It'll probably work like this: make your miner name 8 characters long in the PascalCoin wallet (reserving the last two characters for miner numbers), then connect the Java client, tell it how many GPUs you want to support, and it'll make the appropriate number of mining files. The miners will then be given a gpu number argument, and they'll use that to determine which files they mine with (so the Java proxy would write files like headerout0.txt and datain0.txt, headerout1.txt and datain1.txt, etc. (0 to (n-1), where n is the number of GPUs you want to mine with), and a miner running on device 0 would read from headerout0.txt and write to datain0.txt, etc. The proxy would detect changes in the datain files, and submit those to the PascalCoin wallet.

Hashrate's going up pretty fast!

I ordered an RX 480, and hopefully next weekend I can get around to making a (fairly unoptimized) public OpenCL miner. Ballpark estimates, AMD cards will probably pull 3-4x the performance per dollar of NVidia cards.

Lol for anyone wondering, the results are calculated based on the shares, so the first few rounds can create numbers way higher (or lower) than the actual card's performance. Put it this way: 'x' shares per minute is 'y' speed. By luck, your miner finds 'x' shares in 10 seconds by chance, and that's the only data the miner has to go off of, so it thinks you are performing at 6y until it gets another data point It isn't actually measuring the number of hashes done, but rather the expected number of hashes required to produce the number of shares you've produced.

Also for people wondering about negative hashrates: this miner is quite the hackjob, and the timing function with a granularity of ms that I built basically only uses the current hour, minute, second, and millisecond to produce a number. So when you wrap around from hour 23 to hour 0, the miner thinks you went back in time, and through the magic of negative time thinks you also did negative work.

It is currently, because the code doesn't yet support linux, and there is no RPC for coins, so you can't tell the wallet over a network "send x coins to y" or "have you received any coins on address z yet?" which are both features the dev is working on. Give the project some time--once the codebase matures, it'll be a lot easier for exchanges to work with.

Oh my bad, the new miner takes an argument like "d0" for device 0, rather than just 0. Prepending it with a 'd' is preparing it to be able to accept multiple arguments (host, port, minername, etc.) in the future for the 1.0.7-compatible version.

Someone pointed out that the unneutered miner somehow lost the device parameter. Looks like when I reverted to the unneutered code, I reverted back too far and lost the argument. Anyhow, here's a new version of the unneutered miner which adds back in the device argument:

https://github.com/Vorksholk/PascalCoin-CUDA/releases/download/v1.01/CUDA_Pascal_v1.01.zip

You can just copy-paste the .exe file you want back to where your old .exe file was, and use it instead.

It certainly could be, and I hope it is just a false positive. What makes me suspicious though is that the original PascalCoin wallet compiled by the developer is 100% clean, but when I upload my copy of PascalCoinWallet.exe that I compiled, I get issues. Could be a different library version, some included dll that Delphi threw in, etc., but it does seem pretty odd. Usually when cryptocurrency-related software gets picked up though, it's because sometime like it has been embedded in a real malware's payload to mine on systems that a virus infects. This is a bit different in that it's not the usual false-positives, and it's not the mining software being picked up. All of my CUDA miner binaries appear absolutely clean, and those are the usual suspects for false positives for "unwanted mining software" or the like.

Ran a malware bytes scan on the VM that I built that PascalCoin wallet on, and it didn't find anything interesting. When I get home later, I'll build a completely fresh VM and compile it again--see if the issue goes away.

If you downloaded any version of my PascalCoin.exe wallet, you should probably run a virus scan, and if you want to be extra safe, change important passwords on an unrelated device.

This is embarassing, I didn't even think to run a virus scan on a file I compiled myself. The only thing I can imagine happening is someone using a browser exploit against my VM while I was on somewhat-sketchy sites trying to find a way to get an older version of Delphi, and then installing some program that automatically infects EXE files I compile?

Ew, that's really weird! Looks like it's picking up something from the PascalCoinWallet.exe file? The original PascalCoin wallet doesn't seem to have any issues, and my version is compiled straight from the source code, using a legitimate copy of RAD Studio. I'll do a virus scan on my system, for the meantime DON'T DOWNLOAD THIS FILE. I'll post this notice in the original post too. I compiled it in a VM, maybe I got a virus trying to download an older version of Berlin? :/

Did you make sure your miner name is exactly 10 characters, and is the miner running directly from the same folder as the custom PascalCoin wallet? If so, you're probably good to go!

Also, source code for anyone who wants it: https://github.com/Vorksholk/PascalCoin-CUDA/blob/master/kernel.cu

And if people just want to download the new miner binaries without grabbing the whole PascalCoin package from filedropper: https://github.com/Vorksholk/PascalCoin-CUDA/releases/download/v1.00/CUDA_Pascal_v1.00.zip

Actually totally spaced this, here's an unneutered version with the memory leak fix: http://www.filedropper.com/pascalcudav4

To answer a few questions about the GPU miner I've seen pop up:

Is the GPU miner compatible with 1.0.7?
Not currently, although I plan to make a GPU miner for 1.0.7 sometime soon (this weekend?).

Is there a memory leak in the current GPU miner?
Yup, leaks about a megabyte-ish a minute. I'm pretty sure I found the problem, testing the new version now to make sure it still performs as expected.

Do I need to use different users in Windows to mine with multiple GPUs?
Probably--each GPU will be essentially duplicating the work of the other GPUs if they're fed the same mining data, since they run deterministically (no 'random' nonce generation, though the number of threads running on the GPU do affect the nonce range explored).

Can the different GPU miners all run from the same folder?
No, you need to run a separate instance of PascalCoin from a separate folder for each GPU on the same machine.

Why do I need to use different users for multiple GPUs?
You need to run multiple instances of PascalCoin either with a different public key you mine with, or with a different miner name in order to make sure the GPUs aren't duplicating each other's work.

Will I be able to mine with multiple GPUs to a single wallet in the future?
Yes. The version that supports 1.0.7 and it's RPC functionality will allow you to specify a different miner name for each GPU. As long as you let each GPU use a different miner name, they won't duplicate any work between them (because the miner name is part of what gets hashed when producing a block).

Does it still make sense to CPU mine?
If you have free electric or just want to play around, sure. Unless you have free electric, it isn't going to be profitable.

Watched the miner a bit, certainly seems to slowly absorb memory over time... I probably missed something to dealloc.