@Marc exactly.
jant90
@jant90
Posts made by jant90
-
RE: Cause of the botnet ( in response to " pajeet " exploit )posted in General Discussion
@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?
-
RE: Cause of the botnet ( in response to " pajeet " exploit )posted in General Discussion
@haitch said in Cause of the botnet ( in response to " pajeet " exploit ):
@Marc That plotter would be useful to a botnet, but not for a dedicated miner. See above for why.
@Evo A scoop is a scoop is a scoop. Each nonce is a hash of the previous nonce. The hashes in the scoop number are then combined with the previous blocks gensig, and hashed again, then computed against the block target height. A scoop at the beginning of the file is just as likely to win as the last scoop.
So the assumption of the author of SPlotter is incorrect and smaller plot files shouldn't lead to lower deadlines at all? I don't understand the math/algorithm behind mining at all but I do think the author realizes that nonces are nonces and scoops are scoops. The way I read it is that for the miner (that calculates the deadline right?) it matters what the relative position of the nonce within the plot is and by generating many small plots these positions are different I guess?
His "evidence" (the screenshot he posted) sure looks convincing.
-
RE: burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms)posted in Miner
I made the request to support the splitting of plot files into 4096 individual scoop files (explained in detail here).
I really hope a developer will pick my request up because I (and I hope more people like me) could benefit from it greatly, but of course a splitted plot files are only useful if mining tools can work with them and mine from them just like from large plot files.
As I really like jminer (thanks luxe!) I hope it can support these splitted plot files I proposed, is that something you could add (hopefully without too much effort)?
Thank you for reading :).
-
RE: XPlotter for optimized plots (CPU)posted in Plotter
I made the request to support the splitting of plot files into 4096 individual scoop files (explained in detail here).
As XPlotter is my preferred plotter and it does optimized plots I was hoping this feature could be added to XPlotter so it could be configured to plot 4096 individual scoop files instead of one big plot file. Just like XPlotter improved the plotting process by reduced plotting and optimizing to directly writing an optimized plot I hope it can do the same for directly writing splitted plots (which would be called a splitted optimized plot I guess).
Thank you Blago for XPlotter and thanks for reading!
-
Feature/tool request: split optimized plot files in to 4096 scoop filesposted in Mining & Plotting
Dear Burst developers,
Proposal
Based on my understanding of plotting and mining it should technically be possible to split optimized plot files into 4096 individual scoop files and mine from them without any decrease in performance.Benefits
This would greatly improve portability and make it possible to move a 3TB plot to a 2TB and 1TB HDD for example. Also more file systems could be used (like FAT32 with a file size limit of 4GB). When moving plots between storage locations (for whatever reason) a failed transfer is pretty much disastrous and can cost you a lot of time (to transfer the whole plot file again) but if a single scoop file fails you can just continue where you left of without too much hassle. For me (and I hope for other users as well) this type of portability would be very useful. Lastly, it would be possible to temporarily make space on a HDD if needed (e.g. by moving a few scoop files to a USB drive) without having to delete the entire plot file. I think you could even improve performance if you have a bunch of smaller plot files by distributing scoop files evenly across hard drives for example.Disadvantages
When used properly just splitting the plot file into individual scoop files there should be no decrease in (mining) performance at all so I can't see any disadvantages but if there are any I would like to hear them (just make sure you don't put the same scoop number from different plot files on the same drive).Details of proposal
Proposed file naming (add scoop number to the end of the plot filename):
12345678901234567890_0_11403264_11403264_0001
12345678901234567890_0_11403264_11403264_0002
...
12345678901234567890_0_11403264_11403264_4096I guess the splitting itself would be quite easy for anyone with basic programming knowledge (so not for me unfortunately) as optimized plot files can literally be split into 4096 equally sized files if I understand it right so I really hope Burst developers can see the added value of these split plot files. Of course there are tools (such as HJ-Split) that can already do this but as file naming is important with plots a dedicated tool would be better I think.
Features that would be nice to see in a "plot to scoop splitter" tool would be:
- Extract individual scoops based on number or range (e.g. just extract scoop 2834 or first extract scoops 1-1024 from a 4TB plot to fill a 1TB drive, then extract 1025-4096 to fill a 3TB drive).
- Quick split plot to same drive even when drive is full, so without rewriting all data. Maybe by rewriting the file index while leaving file data untouched so the single plot file shows up as 4096 individual scoop files (not sure if this is technically possible though).
Thank you for your time and I would love to hear your thoughts!
