e1ghtSpace, this bot has some bug, as I already said it doesn't work for me on win nor on linux. Maybe it worked for its creator by accident because of undefined behaviour.
I ran it "as is" for quite awhile and never hit a block. I also re-merged portions of it into my testnet bots, with some modification, and it did eventually find a block. I certainly wouldn't expect a non-developer to be able to make it productive.
Quote
HunterMinerCrafter, I looked at your patch, hard to say how good it is.
Yes, I've been running experiments with it under a local testnet with (somewhat heavily) modified rules. The loss of precision in the compact representation is actually a little noticeable, so I may want to improve that. However, from a "securing the network from time warp type attacks" perspective it does seem to do the job.
Quote
As I understand it will not affect current bots because they generate 10 seconds replays in 40 seconds so there is no deficit, right?
This is ostensibly correct. It is important to remember that the actual intent of this patch has nothing to do with "beating bots" and everything to do with securing the network so that it can scale safely. However, even without warp occuring there will be a very minor impact on the bots in two ways. First, once the extra target does kick in (setting the secondary target to the max 1-bit collision value) it will require a trivial minimum sha512 hashing (2-4 rounds of sha for each map) in any case, which will have a very slight impact on map iteration time, and thus hash rates. Second, it will create direct motivation for botters to not "naturally warp" the chain creating a deficit for the next round, so rational bot operators will likely modify their bots to not submit any blocks before they age to TT, which will also lower their efficiency. (I do not expect all bot operators to be entirely rational, however. Some will be aggressive/greedy with their bots, speculating on a higher future price, and will not ever block withhold even when given such incentive as less future work.)
The network is in an "unexpected" state right now, where human mining margin has increased on its own, but overall coin production is lower. I suspect that this is a sort of natural correction phase, possibly related to the recent market activities, and possibly created out of a side effect of the established bot miners preparing for the impending competition. The miners (and market speculators as well?) are probably still feeling out how to best handle this new mining scenario. (There are really a lot more chain factors to consider than with most any other alt, including HUC!)
I've run some tests on overall impedance to bots. In an experiment today I gave half of the network the ability to "instantly" generate a bike solution once the work deficit challenge rounds were paid, and had the other half of the network playing solutions constrained to "human speed." So, basically, this simulated what would happen under the circumstance where the bike challenge was "fully broken" with some ideal solver. In the worst case, the subsidy collected by "humans" was about 22% compared to without the patch in the same scenario where it became virtually impossible for a human to ever grab a coin at all. (Even if one did somehow the bot side could have ofc just arbitrarily forked their coin base out of existence, since they could instantly rewrite the chain via warp without the patch in place, heh.)
Also it has occurred to me today that if we ignore my earlier Median fix patch for now, we can launch the secondary target patch without requiring a hard fork on the network itself! Old clients will run into issues with the game/replays and will need to be updated to human mine with, so we may want to consider a version increment in the headers to prompt user updates, but otherwise as long as the majority hashing strength switches over within the same round we should not need to hard-code a fork point, I think!
