|
Is there a public branch containing the AT code developed so far?
|
|
|
|
|
What version of burst are you running? I've seen the wallet get stuck like that when the blockchain passes some protocol-change milestone, like the recent addition of escrow transactions. The solution has been to upgrade my wallet.
|
|
|
|
|
It's probably already affecting the price.
It's very interesting. I wonder whether it will lead them to try to shut down Tor access too.
|
|
|
|
The rub is that this software would require the approval of government regulators. |
|
|
|
It's obvious from the page you linked that the vast majority of those attacks were due to execution of untrusted code via a browser, not really applicable to BURST or NXT's usage. Aside from just not using or disabling Java, which isn't always an option for enterprise users, Gundert has a few suggestions. At the top of the list is a need for some form of behavior detection that monitors a user's chain of events before they land on an exploit.
"For example, is a user requesting a Web page that included obfuscated JavaScript, and is the user being redirected?" Gundert asked.
Most legitimate Websites will not use hidden or obfuscated JavaScript, and few will redirect users without authorization, he explained. There is much more reasonable and relevant consideration of the question here: Ultimately, the question of which language is best – or riskiest – is just a distraction. To understand and manage risk, you need to ensure that your developers understand the intricacies of their tools, that you have a solid plan for attacking the challenges presented by your application, and that you have sufficient internal controls to recognize when you are off course. i know it is complex to design and code a library which "speaks burst" because many java dependencies and object methods do not exist or cannot simply be ported.
however, only if the java dependency for burst is removed burst can grow really big.
i dont want to say it cannot grow because of java but it can grow really huge without it.
if there is a 0-day java exploit some day (which happens almost annually) the whole burst ecosystem could collapse due to java.
depending on the integration and dependencies in c there is also a risk involved but this is much smaller than offering an attacker the largest plattform (java) which exists as target.
Until some reasonable and articulable problem with the java implementation develops, rewriting just to have it in a more investor-appealing programming language sounds like a massive waste of effort which could go (and is going) to developing features which will actually make BURST useful. |
|
|
|
@Alex Coventry I've looked at your code. I think that the N CPU buffers are really bottleneck as it will require a lot of RAM to plot N disks at the same time, or will force the user to reduce its <staggerSize> value, thus increasing disk-stress when mining. Maybe a limted amount of rotating buffers would be enough and more RAM efficient. Maybe a stagger-less version (staggerSize = fileSize / PLOT_SIZE) of the plotter could solve this RAM issue (need some tests as it will increase IO operations).
Anyhow I will work on that part with the already implemented multi-GPU support, begining with the ideas behind your version.
What do you mean by "much faster"? Do you speak about a performance difference between the 3.0.0 and the 2.1.1 or between the 2.1.1 and your modded one?
Yes, there is a lot of room for improvement. I only took it as far as I needed for my purposes. You only need as many rotating buffers as it takes to max out transfer bandwidth. By much faster, I mean faster than the same code without asynchronous writes. Thanks for publishing your revision history. |
|
|
|
this one is really favorable if you have 4096 disks, just fill each drive with one kind of scoop, so only 1 drive is working every 4096x4 minutes = 11 days , thats for the extreme, it can be applicable too if you have 2 disks for one account, just split it by scoop number instead of nonce number
4096 tape drives! |
|
|
|
I have no idea. I'm trying to learn why the system isn't vulnerable to a potential fake nonce-spam-attack of this nature. I wouldn't want to bring down a pool--yours or anyone else's-- but I would want to call attention to a vulnerability so the dev and capable members of the community could address it.
The scoops on the disk represent a partial calculation for the given nonces. This means that the calculation using a large plot can be many, many times faster than calculating from scratch, as the burst client does when you submit a nonce as uray demonstrated. See the diagram and associated commentary about the mining algorithm in the OP |
|
|
|
Would it somehow be possible to trick/hack/fake out the PoCminer so it takes the scoop from the same location every time?
Like, let's say you have a 4tb drive, and you create a script that rewrites enough of that 4tb that when PoCminer takes a new scoop from it, it thinks that 4tb is 1/4096th of a 16.38pb (4096 x 4tb) plot that doesn't really exist beyond the 4tb from which the scoop keeps being taken?
What exactly is the reason this can't happen, plot sizes can't be spoofed, etc.? Absent a serious flaw in the mining algorithm, you can no more do this than you can persuade the BTC network that your 2 MHz 6502 CPU is a mining farm with 5000 SHA ASICs. Mining is a Chinese lottery just like in bitcoin, except that the more valid scoops you try, the better your chance of winning the lottery. With 4 TB, you have 1/4000th of the valid scoops you have with 16 PB. |
|
|
|
What kind of read speeds are people getting on large plots? It's taking me around 2.5 minutes to read 32TB across 10 drives connected via USB 3.0, 4 in a 4-port hub, the rest in a 9-port hub. Stagger is 7500, not great but not terribly low... and I don't know that stagger is the main issue, because a modified dcct miner reports initially covering plots at about 480 GB/s, but that drops to about 50 GB/s by the end. I'm not sure what could cause this. Here is the output, one line every 10s. The relevant number is the "n GB total" in the middle. Take the difference between these numbers and divide by 10 to get the rate at which it's going through the plots. Tue Sep 30 01:46:27 EDT 2014 New block 17778, basetarget 5081194
Tue Sep 30 01:46:27 EDT 2014 0 MB read/0 GB total/no deadline
Tue Sep 30 01:46:37 EDT 2014 1214 MB read/4857 GB total/deadline 53967s (53957s left)
Tue Sep 30 01:46:47 EDT 2014 2296 MB read/9185 GB total/deadline 19237s (19217s left)
Tue Sep 30 01:46:57 EDT 2014 3141 MB read/12565 GB total/deadline 19237s (19207s left)
Tue Sep 30 01:47:07 EDT 2014 3885 MB read/15543 GB total/deadline 19237s (19197s left)
Tue Sep 30 01:47:17 EDT 2014 4463 MB read/17852 GB total/deadline 19237s (19187s left)
Tue Sep 30 01:47:27 EDT 2014 5081 MB read/20325 GB total/deadline 16960s (16900s left)
Tue Sep 30 01:47:37 EDT 2014 5728 MB read/22913 GB total/deadline 16960s (16890s left)
Tue Sep 30 01:47:47 EDT 2014 6311 MB read/25246 GB total/deadline 16960s (16880s left)
Tue Sep 30 01:47:57 EDT 2014 6891 MB read/27564 GB total/deadline 16960s (16870s left)
Tue Sep 30 01:48:07 EDT 2014 7503 MB read/30012 GB total/deadline 16960s (16860s left)
Tue Sep 30 01:48:17 EDT 2014 7857 MB read/31429 GB total/deadline 16960s (16850s left)
Tue Sep 30 01:48:27 EDT 2014 7975 MB read/31900 GB total/deadline 16960s (16840s left)
Tue Sep 30 01:48:37 EDT 2014 8012 MB read/32048 GB total/deadline 16960s (16830s left)
I just noticed that on this block, it stays steadily over 500 GB/s until the block is finished, but this is rare. Tue Sep 30 01:53:37 EDT 2014 New block 17782, basetarget 4479105
Tue Sep 30 01:53:37 EDT 2014 0 MB read/0 GB total/no deadline
Tue Sep 30 01:53:47 EDT 2014 1581 MB read/6327 GB total/deadline 284980s (284970s left)
Tue Sep 30 01:53:57 EDT 2014 3052 MB read/12210 GB total/deadline 105624s (105604s left)
Tue Sep 30 01:54:07 EDT 2014 4349 MB read/17397 GB total/deadline 105624s (105594s left)
Tue Sep 30 01:54:17 EDT 2014 5604 MB read/22416 GB total/deadline 105624s (105584s left)
|
|
|
|
I've watched the videos and have found him creepy as fuck. His voice, his looks... I'm sure I'm not the only one who thinks this, but most people are too polite and too PC to actually say it.
Are you trying to say that ethereum is suspect because one of the developers looks gay? |
|
|
|
|
Has anything interesting happened in this story recently?
|
|
|
|
Wow, so where do you stand? That does [not] give much detail of your opinion!!! BTW, I actually do want to hear it  It's a winning attitude over the long term, and I have committed a lot of resources to mining and buying burst because of it. |
|
|
|
Scanning this thread all i see is miners talking to each other. Theres no discussion about selling, price, or
PR for the coin etc. Am I missing something with this coin?
There is more of a focus on building something to sell, than on selling something to build. |
|
|
|
|
Timk, please go tell everyone on the bittrex trollbox about your terrible experiences with burst. If you can get it below 100s in the next week, I'll give you 10k more burst.
|
|
|
|
|
Has anything interesting happened in this story over the past 24 hours?
|
|
|
|
> re-illiterate
ladygoingwut.jpeg
Self-referentiality has a storied history in computer science. |
|
|
|
|
The list in the OP seems very limited. I am surprised that burst and truthcoin didn't make it.
|
|
|
|
this coin is amazing!
from 130 to 240 in last couple of days but you guys hardly mention it and still talk about mining it! this is great sucess and a good sign. Cryptocurrency is like an OTC penny stock. If you get excited about a mere 80% price fluctuation on limited volume, you may have the wrong temperament for trading it.  |
|
|
|
A picture tells a thousand words. Possible to create an inforgraphics that explain how it works ? Try the section "Multisignature storage" here. It gives an animation of how it works in one simple application, securing an account so that it would normally require the signature of both the owner and a third party to execute a transaction from it, making it much harder to steal funds because now you have to steal two keys, and one of those keys is in the hands of an entity for whom security is a professional concern. The explanation is for bitcoin, but the same principles almost certainly apply here (I haven't looked at the new client, yet.) |
|
|
|
|
Show Posts
