Cause of the botnet ( in response to " pajeet " exploit )
-
@falconCoin the network difficulty ........ efectivly based on how fast the last few blocks have been found and the difficulty seting they was found at the network has estimated there are aprox 84k peta on the network and raised the mining difficulty to adjust........ basicly any pool or miner will see diff stat or a netdiff stat ....... simply that how the network auto adjust the diff to aim for a 4 min block find time based on aprox amount of mining power on the network.......... the last 4 weeks it has shoot throu the roof...............
4 weeks ago the Netdiff was siting around 22k , it has goten vary hard to mine burst in the last 4 weeks ....... anyone with less than 10TB has to be hating life as they have seen the effects first im sure
-
@haitch i was looking at the pools here http://blocks.burstxd.com/
and you can see a lot less blocks hit than in the past few days for sure...
and yep @Gibsalot i have noticed i only have 6.5 mining right now
-
@falconCoin said in Cause of the botnet ( in response to " pajeet " exploit ):
@haitch i was looking at the pools here http://blocks.burstxd.com/
and you can see a lot less blocks hit than in the past few days for sure...
Yeah, I think this due to really short DL's (the Botnet ?), causing the wallet to over estimate
-
@haitch said in Cause of the botnet ( in response to " pajeet " exploit ):
@jant90 It's complete and utter BS.
I have Burst account X, I plot a single 500GB plot of nonces 0...Y. I also plot 100 5GB files for nonces 0...Y.
A nonce is computationally derived from your ID, the last scoop number, the value of scoop(4096). So both the single 500GB file and the 100 x 5GB files will have exactly the same data in them.
Which plot do you think will be more efficiently and quickly mined?
Like I mentioned (and the SPlotter author as well), it's not about the plots, nonces or scoops at all. Yes, the plots contain exactly the same data, there's no discussion about that.
It's about the algorithm that calculates the deadline from these nonces (= just the mining part). And yes it's also agreed that scanning the hard drive takes longer with smaller plots so scanning the plots is less efficient BUT the theory is that you will receive lower deadlines because of the relative position of the nonce within the plot files.
I haven't seen any admin or developer here or on Burstnation address that theory at all. Even Blago fully ignored the issues raised by the SPlotter developer and instead stated the same you did just now (plot data is the same / scanning takes longer etc.).
Maybe a miner dev can shed some light on this? They should know how the deadlines are calculated during the mining process I guess?
-
@jant90 It all Comes down to question whether the author of splotter is right with his assuming that the concrete Position of the nonce within the Plot gives you better Deadlines when they are more at the end of a plot than in the middle - or if there is no difference at all.
He has posted a pic over there here:
(first page, one of the plots is not like the others). I really would like to see comments on that and on the question if or if not this way of plotting give you ~5times better dl, thus 5times more coins - for the Price of having to replot your HDs and ruining them quicker by putting more load on them.
-
When you want blago's opinion on that you need to tag him ( @Blago ) !
From the first glance it looks like this guy made the old wplotgenerator out of the XPlotter. Wplotgenerator used the Stagger, which were simplified like sequential chunks of plots.
It just doesn't make any sense why this should be better or give better results.
-
@Marc exactly.
-
@jant90 said in Cause of the botnet ( in response to " pajeet " exploit ):
BUT the theory is that you will receive lower deadlines because of the relative position of the nonce within the plot files.
And that's the part that is complete and utter BS. The miner doesn't care where abouts in a file a scoop came from; the scoop is going to have the same content, and the miner is going to do exactly the same calculations if it's the last scoop in a 1GB file or buried somewhere in a multi terabyte file. The scoop has a value, that is mathematically processed to create a DL with no regard to file position. Scoop Y in Nonce X is always going to be Scoop Y in Nonce X and will always have the same DL.
-
-
@Blago LOL - quoting me at BN could get you banned ..... ;-)
-
@Blago @haitch But they are saying that nonces with index over 9,223,372,036,854,775,807 hit more blocks?
Or are they starting to count down from 9,223,372,036,854,775,807 ?
I didn't get it...
-
@gpedro it's complete and utter BS. SnakeOil.A scam. Mathematically impossible. The people spouting this crap are doing so from the place where crap comes from .....
-
@Blago Have you looked at the code? It's possible that it may be infected too? you know as trojan horse or something?
@haitch I think so too but I wanted to try and understand what they are saying...
-
The code looks fine, but the exe he's distributing as a release could be malware.
-
@gpedro i'd check the code - he add only 2 strings - loop, using "goto" https://github.com/SamuelNZ/SPlotter/blob/master/SPlotter.cpp#L312
(scool-boy programming style)
-
@Blago what about the actual exe? Did you check that? I can stand up a vm to profile the exe in an isoled environment, I guess.
-
@illuminatus virustotal - exe clear
-
@illuminatus That would be cool...
@Blago I guessed so too xD
-
@Blago right - but a virus scanner ( I assume you used that) would rely on a known signature of the file(s) - how do we know that running it doesn't install something else?
-
@illuminatus same way you know there is not a mugger down the alley in front of you. Little bit of faith and a little bit of caution...
Blago said the code was clean just added two lines if you don't trust the exe the author built you can build your own off the source. But IMHO if the author's exe was infected with a botnet spreading virus or trojan then his github account would get reported and dropped or flagged.


