 Show Posts
|
|
Pages: [1] 2 3 »
|
Another example of a fastblock being eaten by the same person in a couple seconds...  Am I the only one that thinks this is weird? Double check in the blockchain. It's not by the same address, it's an bug in the miner and/or wallet. |
|
|
|
It's more about the fact that he has the same exact deadline as the last block AND it happened within the first 5s of the new block.
I investigated a bit, because I saw the same thing with block 77885 and 77886. It turns out that Blagos miner is showing some false information, because the blockchain does not show that those blocks was mined by the same address. I don't where the bug is, it could be that the info server has not updated, so the miner is reading the old information. I have set the info server to be the same address as the wallet, so the miner will read the information from the same place - that should take care of this. |
|
|
|
you can only announce a nonce for a account id. all wallets then verify the received nonce by calculating the deadline for it.
the only way to "play" with the blockchain is to ddos the miner wallets by massive nonce submission to the blockchain.
the result of this may be that many mining wallets simply freeze up and the tb mining with it wont get fresh blocks.
i am not aware how the automatic ddos protection works and how fast bad ips would get blacklisted.
this attack vector may have happened before (sorry i cannot proof) because after not finding a block for several hours i directly found blocks as usual after a wallet restart and fresh peers. i have'nt traced this down to its origin but the watched effect looked suspicious.
lately the diff went too high to see this effect directly anymore so i stoped a further investigation.
to be able to premine blocks you require to know the blockheight and the resulting gensig of the winner.
simply said the gensig is based on who found the block combined with the height. therefore there is no way to optimize stored plots for certain gensigs because they alter even for the same miner for a different blockheight.
the only statistically based optimization i could imagine would be to only store nonces which do not contain all scoops.
statistically if you would store nonces containing only 12 scoops your plots may be used for 1 block a day (statistically).
for this one block a day each tb plotted this way equals 360tb. the tricky part starts when you think of load distribution. but maybe this attempt may be used for vps approaches or third generation pools.
It's simpler than that. If I get a block of say < 500s, then I can assume that it's going to win, and see what my next deadline would be. It's probably not going to be anything useful, but if it is, say a sub 20s block, announcing it fast is key. If the miner is still scanning and it see an accepted deadline it will just move on, even though you might have a better deadline somewhere you haven't read yet. |
|
|
|
Something else I've noticed guys. When fast blocks happen, they're won almost always with a sub 100 deadline, which doesn't make sense considering people usually don't have time to scan all their plots. Maybe it's just coincidence? I've only been watching since Blago added the winner stamp to the miner. Also interesting, in this specific example, the same person won the block before with the same EXACT deadline. This should be extraordinarily rare to the point where it doesn't happen unless fast blocks are special?  My theory is, that some people out there, with a rather large farm, use a custom miner that will assume that the deadline will win and scan for the next block. This allows them to announce low deadline immediately after their previous deadline was accepted. |
|
|
|
There is definitely some optimizations that could benefit Blagos miner. My experience is that I need to use a lower cache size than what ought to be optimal. Optimally, the miner should read all the data it needs from a file in one go, and do it's thing. That would limit the IO seeks to 2 per plotfile. But if I set the cache size such that it should be able to read everything the CPU will visually idle while it's trying to find the best offset. However if I lower it to 131072, it seems to keep the CPU at 100% utilization. That said, I still have great success with optimizing. My 16TB took ~110s unoptimized, and are now running in ~80s, great improvement. So after playing around and comparing Optimized Vs Non-optimized plots with the J6 optimizer, it appears as though non-optimized plots are faster. They however consume more memory when being mined (optimized plots have almost no memory usage). The speed difference is negligible, optimized is 10~ seconds slower, seemingly regardless of the number of drives I have attached.
I'm not exactly certain why this is, especially when everyone is saying they're faster. I even used a faster processor and Blagos miner was not operating at 100% usage. To that end, it appears that Blagos can only split threads down so much and it was effectively limited by one logical processor... at which point it would be faster if I had a higher frequency processor (single threaded performance becomes a bottleneck).
These are 4.54TB plots on 5TB 5,900RPM drives with 8192 stagger. They're hooked up via SATA 3 and I'm running W8.1 x64. The fastest I could hash one 5TB drive was 47s, it was non-optimized. A optimized one took 51s.
I really don't know why you'd want to optimize, unless you have extremely slow drives or almost no memory. Even on my pokey 5,900RPM drives, the bottleneck is definitely the processor (which makes a GPU assisted miner all the more desirable). The amount of time it takes to optimize and risk breaking your plots doesn't seem worth it.
Although I haven't played around with it, I would theorize a higher stagger size would actually make mining faster (if you have 16, 32, or 64GB of memory). These results may be because of how large my plots are comparatively to other people who are using much smaller drives.
I've been testing this over the last week or so and this has been tested across multiple systems. A A4-4000, G3220, and a AMD x4 640 (which is what I'm currently using). I tested in single drive configurations and multiple drive configurations (up to five drives). The results have been retested too, at no point in time were the drives actually the bottleneck in any of my tests. Maybe I just don't have a fast enough processor and after a certain threshold a non-optimized drive becomes worse then a optimized one.
In order to surpass a certain threshold it seems as though you need an extremely fast single threaded processor for best case mining. A i7, overclocked is better. Hyperthreading will help when you have more then four drives, although I also suspect a eight core FX would perform well when you have more then eight drives as AMD modules work quite well in multithreaded workloads.
|
|
|
|
That comes with a question on too big to download for average user. Burst investor will eventually come from all around the world. Not every country have fiber broadband internet connection and it might deter some investor from getting into the coin. I guess one solution could be a trusted online wallet for burst , it will make using burst a whole lot easier. 500 gb database will come eventually and we better be ready before that happens
i think a good solution it is to include the blockchain folder on each new relase zip. so, the user will need to sync just the latest few block.... so we avoid to have fork with every new version release. i hope burst dev, repute this a valid option !!! I'm not exactly sure what you're suggesting. But in any case, a central authority should not be distributing the blockchain, nor introduce checkpoints. The history of the blockchain requires the entire blockchain to verify. It should be possible reduce the size by giving up on some history, but I do not know enough about this particular blockchain to claim it is. In any case, introducing checkpoints or the blockchain within the download, is very much against the decentralized nature of the blockchain, by giving a central authority the ability to dictate what chain is the right one. |
|
|
|
Going back in time and try to overwrite the current chain is actually an interesting attack. On my machine I can get get scanning down to 3s/tb, that is 1TiB and an entire machine (but still something we should protect against if possible). That said, you still need significantly more than 50% of the network capacity for this attack to be exploitable at will, so I really do not see this as a problem. Question remains, what is the probability of a successful attack of this kind for 20%-80% of the network capacity, and for 1-100 blocks - that should give us a very good idea of what a "safe" number of confirmations would be.
Where does your "significantly more than 50%" figure come from? If anything I would think it could lower the amount slightly for small forks(2-3 block attacks), since 51% is a statistical expectation, not an absolute, and if the cost to attempt the attack is low enough, an attacker can more easily try more times, allowing more chances for variance to help out enough to make it work. For longer forks, I would still expect it >51% to be needed. Note that I said "at will", which I said to mean that you decide that now you are going to do something that you will "undo" after 10 confirmations, e.g. transfer coins to an exchange and sell it off - once the BTC is on it's way out you want to undo the initial transaction. If you only hold 51% the statistical probability isn't high, though eventually you are likely to succeed. What I propose, but lack the theoretical knowledge to calculate (well, I learned it during my statistical math classes, but it's long forgotten): * assume that calculating an n-block long private chain is instant * calculate the probability to successfully fork the last n blocks, where n is 1-100, with p 10..99 % of the network capacity. I assume that finding deadlines is instant, such that any advance in technology will not render the result invalid, because it is now faster. |
|
|
|
Also, how much does Burst have to worry about 'Nothing at Stake'? Basically you can try to mine on every fork you see? If someone gets over 50% of the storage, then he can create a separate fork with very little effort that looks correct? There is one way to sort of get around this but it can't be used to prevent new miners joining the network from joining the wrong fork. So, theoretically, given what is currently implemented.
It is no different than any other algorithm that has 50% value to determine the correct fork. If you own >50% of the Network power (or storage here), you can mine your own fork and publish it once it's ahead of the other fork. Nothing can prevent this in a decentralized system of this kind where the "majority" is right. The issue is let's say someone started working on a Proof of Work fork. If they wanted to fake a fork that was 100 blocks long, they would have to remove 50% of the mining power from the main chain to create this fork, this would take 100 blocks to complete however.. by which point in time the network would be 100 blocks into the future, so they'd constantly be playing catch up. The question is, can you occasionally say fake a fork like this in say 5 minutes with a large enough percentage of network resources that the network accepts and uses to overwrite the 10 confirmations of a blockchain which cheats the system and overrides that calculation? You are correct, a fake fork could be constructed in less time catching up to the current time starting from a block farther back than mining the real one took Considering the reading time for many user's plot files, you could probably construct the fake one in about 1.5 minutes/block. In order to achieve at least the same cumulative difficulty without running into the future(which would cause the chain to get rejected), the fake chain would still have to have a higher hashrate than the real one. In the case of semi-honest miners on both chains, catching up would probably be slower, as miners would be reading different data for each chain, so 3 minutes/block for creating a fake chain would be more likely, making catchup still faster, but not by as much. Thanks for mentioning this, I'll certainly be keeping it in mind. Going back in time and try to overwrite the current chain is actually an interesting attack. On my machine I can get get scanning down to 3s/tb, that is 1TiB and an entire machine (but still something we should protect against if possible). That said, you still need significantly more than 50% of the network capacity for this attack to be exploitable at will, so I really do not see this as a problem. Question remains, what is the probability of a successful attack of this kind for 20%-80% of the network capacity, and for 1-100 blocks - that should give us a very good idea of what a "safe" number of confirmations would be. |
|
|
|
How large are plots? I thought the idea was they were hundreds of GB large.. but first post seems to indicate 262144 bytes? I was thinking plots were something like 200 GB.. large plots would be good for ASIC resistance.. and could probably be used to lure over some litecoiners who recently lose that advantage. I would target devs or various coins and people who have made a difference first instead of just announcing it to the community as a whole though.
Plot is 256kb. Every block a random portion of plot (1/4096) is used for mining (I'm simplifying things a bit). The more plots you have the more chances of finding the best deadline. Generating plots 'on the fly' is very CPU-intensive, so the coin is ASIC-resistant. Interesting... thanks. Also, how much does Burst have to worry about 'Nothing at Stake'? Basically you can try to mine on every fork you see? If someone gets over 50% of the storage, then he can create a separate fork with very little effort that looks correct? There is one way to sort of get around this but it can't be used to prevent new miners joining the network from joining the wrong fork. So, theoretically, given what is currently implemented. It is no different than any other algorithm that has 50% value to determine the correct fork. If you own >50% of the Network power (or storage here), you can mine your own fork and publish it once it's ahead of the other fork. Nothing can prevent this in a decentralized system of this kind where the "majority" is right. |
|
|
|
I am using windows 7, and while it actually works now for me, it is obvious that windows simply cannot cope with the tech requirements. I even have a growing list of applications that are no-go if my burst mining has to run at 100%. Anyone planning to mine more than 10 TB on one computer should seriously consider using linux to avoid the problems related to the windows paging and virtual memory system forcing processes to crash, when you start reading serious amounts of data. I have a Windows box mining 20TB, and no problem using it at the same time for my day job as a developer. No idea what you have tweaked to make performance subpar. Another windows (out of the box) problem is that time might drift - the standard windows way of keeping time synced with the internet does not work well,unless perhaps if you have a domain server that itself have commercial stuff on it to keep internet time correctly.
Windows by default sync time every 5 days, can be changed if your clock drift too much. Again, not a problem, particularly considering that you have to install NTP and enable it on Linux to have the functionallity at all. If you dig in deeper with burst, it is also a hassle to compile on a non-modified windows, and the list goes on.
It's a hassle to install VS or GCC for C/C++, or JDK for Java and compile it? It's not any different from Linux except dependencies, and that really isn't a problem. Besides, JDK is much more of a hassle on Linux than it is on Windows. |
|
|
|
i think it is a bit optimistic... with 12Tb it say 7000 coins/ day.... i'm doing 5000/6000 day... It uses a 50 block average for difficulty, that's less than 3½ hours, and depending on when you take the average it will vary from 2M to 4M. 24 hour average would probably be a lot better. |
|
|
|
If you have a fast ssd, is mining faster? or is it the same speed?
Same speed, you will be CPU bound calculating the deadlines every time a new round starts. Same, but there is a difference if the ssd is 20tb or something!!! No there isn't. Even my i7 4790K is cpu bound when calculating deadlines with a single 4tb disk. There is simple no way a SSD is useful unless you're too lazy to optimize your plot files. |
|
|
|
If you have a fast ssd, is mining faster? or is it the same speed?
Same speed, you will be CPU bound calculating the deadlines every time a new round starts. |
|
|
|
I am having difficulty woth speed even with SATA3 drives, lots of things that seens "could work" simply don't.
By my experience I would stay away of USB 2.0 drives.
I can't read plots of 32Tb in less than 2 minutes. All on Sata3.
That is a matter of CPU bottleneck, and not reading speed. Go ahead and open a process monitor on your system. When a new block starts you will see your CPU at 100% (and if not, you need a better miner). I spent some bucks on best A10 cpu that is available to the market, and guess what? Nothing changes. On reading plots all cores also get to 100% and time is not significaly reduced (few seconds on 180 sec is not noticable really). so, CPU really does not matter... not a lot. Maybe for 40 hdd cluster or so... What makes you say that you're not CPU bound, if it's running at 100%? That's the definition of CPU bound. I just tried to disable half of my cores, and processing time was almost perfectly doubled. |
|
|
|
I am having difficulty woth speed even with SATA3 drives, lots of things that seens "could work" simply don't.
By my experience I would stay away of USB 2.0 drives.
I can't read plots of 32Tb in less than 2 minutes. All on Sata3.
That is a matter of CPU bottleneck, and not reading speed. Go ahead and open a process monitor on your system. When a new block starts you will see your CPU at 100% (and if not, you need a better miner). |
|
|
|
USB2 - ~40 mb/s, too slow for large HDDs. Works well for ~1-1.5Tb
That simply isn't true. USB 2.0 is theoretical 35MiB/s, but more realistically 30MiB/s. How fast is that i terms of Burst? We need to read 1/4096 of the plotfile, so with 1TB (~954000MiB) it takes ~7,76 seconds to read a plot. So if you want to stay below 30 seconds to play it safe, you can have 3.86TB, or just round up to 4TB in 31 seconds. Note that some ports share bandwidth, so you can only have 4TB on those ports in total. In other words, USB 2.0 is fine as long as you make sure you aren't using ports that share bandwidth. |
|
|
|
The fact that the rate of new posts in this forum has slowed significantly is proof positive that this crapcoin is so OVER with.
It's both hilarious and kinda sad that you continue to post in this forum. How about you just move on? |
|
|
|
I'm using quite large stagger size files, 1048576 to be specific, setting CacheSize to a value lower than that actually result in much faster processing (51s vs 40s).
If you set CacheSize - 1048576 , miner's thread finding 1 best deadline in 1 file and put it's to Sender. If you set CacheSize - 131072, miner's thread finding 8 best deadlines in 1 file and put it's to Sender, Sender sends first best deadline to server, waiting response too much time, after sending second deadline, waiting again Setting the stagger size to 131072 is actually faster. Only takes 41-43 seconds to process all the plots, setting it to 1048576 it takes at least 53 seconds and the CPU utilization is not 100%, so bigger is not better in this case for some reason. |
|
|
|
New update Miner-BURST-1.141014 * rewrote the sorting code + added output messages of checks + added rainbow and fun + added debug parameter ! during the tests was not found differences in deadlines ! better use "CacheSize" => your max stagger limits: 1000 files in 1 path (folder) max paths = 24 Sender's array of best deadlines = 2400000 https://www.dropbox.com/s/9so0bo71wg6nf3k/miner-burst-1.141014.zip?dl=0I'm using quite large stagger size files, 1048576 to be specific, setting CacheSize to a value lower than that actually result in much faster processing (51s vs 40s). |
|
|
|
|
