Author

Topic: [ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000 - page 591. (Read 2171061 times)

legendary
Activity: 1022
Merit: 1000

So my rig is almost ready..

I just need to know how I plot on multiple harddrives.

I have 6 1TB disks in my computer that is ready for mining, but I have no idea on how to get started with plotting each of them.

Can someone help???
Quote
If you're on Windows, download Janror's cpu plotter. Choose plots ranges so they don't overlap.
Choose stagger depending on available memory, the higher the better.
For example, having 16 gb memory I've plotted 1 tb hdd with the following params:
plot size 400000 (100 gb per file), stagger 40000 (10 gb per chunk)   - this requires ~10 gb ram during plotting

file #1: start nonce 0, plot size 400000, stagger 40000
file #2: start nonce 400000, plot size 400000, stagger 40000
file #3: start nonce 800000, plot size 400000, stagger 40000
and so on
file #9: start nonce 3200000, plot size 400000, stagger 40000
and to fill the remaining 50 gb:
file #10: start nonce 3600000, plot size 200000, stagger 40000

Next HDD will start from nonce 3800000.

Size may vary a bit depending on HDD manufacturer. You might need to adjust the last file size.

Plot size must be a multiple of stagger.

There's also plot file optimizer which can make the stagger equal file size after plotting.
If you use closed-source tools make sure to send the coins often to another wallet which you never store on the PC where you've runned these tools.

Is it possible for anyone to jump on skype and help me out? Maybe even Teamviewer.

Because all of this is a bit hard to understand.
hero member
Activity: 527
Merit: 500
If I see it right, burst.ga is down again Sad
hero member
Activity: 588
Merit: 500
http://www.newegg.com/Product/Product.aspx?Item=N82E16856119098

How about that for mining on USB 3.0? U;tra low power, and up to 8gb RAM

Hehe, just came across it and want to give it a test some time, just for fun Smiley I mean, they HDD's will be wwaayy bigger than the actual PC!!!

EDIT: 4 USB 3.0 ports + 1 sata III http://www.newegg.com/Product/Product.aspx?Item=N82E16856173102

Limit i guess is the CPU for reading all those plots Sad
newbie
Activity: 44
Merit: 0
Anyone figure out what happened with all those people getting hacked?  Anyone figure out what happened?

No ideas. Sad

So my rig is almost ready..

I just need to know how I plot on multiple harddrives.

I have 6 1TB disks in my computer that is ready for mining, but I have no idea on how to get started with plotting each of them.

Can someone help???

If you're on Windows, download Janror's cpu plotter. Choose plots ranges so they don't overlap.
Choose stagger depending on available memory, the higher the better.
For example, having 16 gb memory I've plotted 1 tb hdd with the following params:
plot size 400000 (100 gb per file), stagger 40000 (10 gb per chunk)   - this requires ~10 gb ram during plotting

file #1: start nonce 0, plot size 400000, stagger 40000
file #2: start nonce 400000, plot size 400000, stagger 40000
file #3: start nonce 800000, plot size 400000, stagger 40000
and so on
file #9: start nonce 3200000, plot size 400000, stagger 40000
and to fill the remaining 50 gb:
file #10: start nonce 3600000, plot size 200000, stagger 40000

Next HDD will start from nonce 3800000.

Size may vary a bit depending on HDD manufacturer. You might need to adjust the last file size.

Plot size must be a multiple of stagger.

There's also plot file optimizer which can make the stagger equal file size after plotting.
If you use closed-source tools make sure to send the coins often to another wallet which you never store on the PC where you've runned these tools.
member
Activity: 108
Merit: 10
I am looking for someone who can help me with setting up my PC/Miner so I can start mining.'

Windows 7 is installed and 6x 1 TB HDDs ready.

How does plotting work?
How do I do that?

check this guide from crowetic
https://docs.google.com/document/d/1Bc1LIG0vOYYW6FxgBHhQGjKqm0aWoSClkqaNJx17wWk/edit?pli=1
Check this out Hamuki, just make sure you use the latest wallet version
legendary
Activity: 1022
Merit: 1000
So my rig is almost ready..

I just need to know how I plot on multiple harddrives.

I have 6 1TB disks in my computer that is ready for mining, but I have no idea on how to get started with plotting each of them.

Can someone help???
hero member
Activity: 527
Merit: 503
Anyone figure out what happened with all those people getting hacked?  Anyone figure out what happened?

We're not going to end up with an exchange losing a whole bunch of coins and someone flooding the market, are we?
sr. member
Activity: 416
Merit: 250
Blago/anyone - I am using your latest miner.  The older miner used to tell me how many seconds it took to read a folder of plots, but now it does not.  Am I missing a setting in order to get this information? thx

set  "Debug": true,
member
Activity: 111
Merit: 10
Blago/anyone - I am using your latest miner.  The older miner used to tell me how many seconds it took to read a folder of plots, but now it does not.  Am I missing a setting in order to get this information? thx
sr. member
Activity: 280
Merit: 250
My password is a random string of numbers and letters, caps and no caps, 30 symbols long. So weak password is not an issue.

It's unlikely that the password was bruteforced, but I think 30 symbols doesn't provide maximum security.
Please correct me if I'm wrong: 256 bits are used in the hash, that's 32 bytes. But we aren't using the full 0-255 character range in passwords, so they should be much much longer. 26 (a-z) + 26 (A-Z) + 10 (numbers) = only 62 chars subset is used for passwords. Using words instead of random letters raises bruteforcing chances even more. The passwords need to be 4.2 times longer: at least 134 symbols!


You're on the right track, but your math is not quite right. If you choose a password from a set of 62 characters, then each character is providing 5.95 bits of entropy (ln(62) / ln(2)). So, if you want to achieve 256 bits of entropy, your password should be at least 43 characters long.
i have'nt looked into the code on how the pk is used to sign transactions but i think it is ecdh based.
doing a google search for the included java code from nxt to do the signing brought up a site stating the sign function is not as secure as the original code where it was ported from to java. this is because java uses different size integers and a c big int variable has only the maximum size of an unsigned int in java (https://gist.github.com/doctorevil/9521116).
someone with java knowledge maybe can verify that the described flaw applies or hopefully does'nt apply to the code in src/java/nxt/crypto/Curve25519.java file or finds out this whole function is only included due to forking reasons.

this in combination with the wallet which offers 12 words OUT OF 1626 by default (html/ui/js/crypto/passphrasegenerator.js) makes it in my opinion attackable.
within an bruteforce attack this is less than 11 bit for each word which sums up to about 105 bits of combinations.
if the ecdh implementation shows the mentioned flaw it cuts internal 256 bit variables at 64 bit.
without further analysis this provides a option to bruteforce wallet generated keys by software designed to utilize this flaw by testing less than 32 bit of combinations. i am no crypto specialist and if someone with knowledge about all this could take a look into it would be great. i think as long as someone uses custom generated private keys even if the flaw exists in the code the required energy to break 105 bits is much more than what you get for the coins in the wallets. on the other hand it may be possible to bruteforce all known wallet addresses in one run without much more costs...

i currently do not understand why someone did'nt empty the whole account and only took 40k.
i dont want to make people panic sell and drive the price down but if you hold a certain amount of coins within one wallet think about all this if you used the wallet to generate your private key.

The signing issue isn't due to integer size differences, but due to java's lack of unsigned integer types. The proposed patch on the page you linked has been applied to the Curve25519.java file, so this hasn't been an issue for quite a while.

Regarding the passphrase generator, I don't know where the cut-off would be for considering it bruteforceable, however 105 bits does seem very low compared to what you would get from the recommended 35+ characters alphanumeric with symbols.

I think you're looking at the wrong account. Stacy's account had all 9.8k transfered, however they didn't continue to transfer new coins that came in from mining.
sr. member
Activity: 462
Merit: 250
i have'nt looked into the code on how the pk is used to sign transactions but i think it is ecdh based.
doing a google search for the included java code from nxt to do the signing brought up a site stating the sign function is not as secure as the original code where it was ported from to java. this is because java uses different size integers and a c big int variable has only the maximum size of an unsigned int in java (https://gist.github.com/doctorevil/9521116).
someone with java knowledge maybe can verify that the described flaw applies or hopefully does'nt apply to the code in src/java/nxt/crypto/Curve25519.java file or finds out this whole function is only included due to forking reasons.

this in combination with the wallet which offers 12 words OUT OF 1626 by default (html/ui/js/crypto/passphrasegenerator.js) makes it in my opinion attackable.
within an bruteforce attack this is less than 11 bit for each word which sums up to about 105 bits of combinations.
if the ecdh implementation shows the mentioned flaw it cuts internal 256 bit variables at 64 bit.
without further analysis this provides a option to bruteforce wallet generated keys by software designed to utilize this flaw by testing less than 32 bit of combinations. i am no crypto specialist and if someone with knowledge about all this could take a look into it would be great. i think as long as someone uses custom generated private keys even if the flaw exists in the code the required energy to break 105 bits is much more than what you get for the coins in the wallets. on the other hand it may be possible to bruteforce all known wallet addresses in one run without much more costs...

I think this is the relevant patch.

Code:
commit 56e44b38e524ea52a7b2f5a7e25d126c929ece72
Author: Jean-Luc Picard
Date:   Sat Mar 15 06:05:36 2014 +0100

    applied Curve25519 patch from DoctorEvil

Come-From-Beyond claims that there were a number of deliberately-introduced vulnerabilities in the original NXT source code, to deter NXT clones.  It sounds like an incredibly irresponsible thing to do, but there it is.  Supposedly they're all patched, now.  Someone here probably knows the date of the last such patch... the NXT source should be checked for  patches to any vulnerabilities reported prior to that.

i currently do not understand why someone did'nt empty the whole account and only took 40k.
i dont want to make people panic sell and drive the price down but if you hold a certain amount of coins within one wallet think about all this if you used the wallet to generate your private key.

People should panic-sell.  Just let me in on the bargain-basement prices. :-)
legendary
Activity: 2282
Merit: 1072
https://crowetic.com | https://qortal.org
Any reason for why burstforum is down cant access.

no news from admin... I don't have any other forms of contact for him either.
newbie
Activity: 20
Merit: 0
looking in the wallet, list of found blocks has changed sorting order(low->high vs. descending previously) and it is not possible to see a list of all mined blocks now with this update?

Burst 1.1.5

Download: https://mega.co.nz/#!r9RywR4b!e0MqN4kXx1uiW5th8PBxiwjOfdNhjxjS52UqXwihGW8
sha256: 5b8a5e9d2ebcc35052a885b299764ed257346f3c849e92768bd5b725ad685ac7
Or github: https://github.com/BurstProject/burstcoin

Update is required for all users.
Hard fork will be triggered at least 4-5 days from now, depends on how fast people update.
If using an existing copy of the blockchain, first startup will take several minutes.

Short summary:
Updated to latest Nxt(1.3.2)
Added subscriptions(reoccurring payments)(more details will be given when enabled)
Escrow updated to use result transactions instead of just adding to balance.

Longer story:
This release took far longer than I intended it to. Subscriptions turned out to be more of a challenge than expected, and about when I had a first release candidate, nxt 1.3.0 was released. Nxt 1.3.0 was a massive restructuring which I considered a necessary update since it was to fix scalability issues I already knew would need to be addressed at some point, however it broke compatibility with a lot of my code. Rather than debugging subscriptions, then updating, and debugging it again, I went straight to updating to Nxt 1.3.0, which required me to re-write most of the subscription, escrow, and reward recipient assignment code. Nxt 1.3.1 and 1.3.2 were also released fairly shortly after, and their updates went a lot more smoothly. Re-testing everything took some time, and I ended up re-factoring subscriptions a few times to ensure everything was done consistently.

Next plans:
I'm going to be postponing the last part of advanced transactions for now, and starting on BurstID(more details will be given later), and maybe some of the DHT code.



I also would like to request if there could be some way to return the "Blocks" section of the wallet back to the old style where newest blocks found were displayed first as it did in pre-1.1.5

I had relied on this more than I thought to see my mined blocks now that its reversed order.
member
Activity: 108
Merit: 10
Any reason for why burstforum is down cant access.

It is down since this morning (GMT)... still no news
sr. member
Activity: 435
Merit: 250
java.net.SocketException: Unresolved address

no, its new config file. i have changed only allowedBotHosts and apiServerHost to the same values as in 1.1.3.

Double-check the address you're connecting to.
legendary
Activity: 1820
Merit: 1001
Any reason for why burstforum is down cant access.
full member
Activity: 158
Merit: 100
Code:
Caused by: java.nio.channels.UnresolvedAddressException
at sun.nio.ch.Net.checkAddress(Unknown Source)
at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
... 9 more
2014-11-05 22:25:58 INFO: Started peer networking server at 0.0.0.0:8123
2014-11-05 22:25:58 SEVERE: Errors running startup tasks:
java.net.SocketException: Unresolved address

java.lang.RuntimeException: Errors running startup tasks:
java.net.SocketException: Unresolved address

at nxt.util.ThreadPool.runAll(ThreadPool.java:133)
at nxt.util.ThreadPool.start(ThreadPool.java:62)
at nxt.Nxt$Init.(Nxt.java:189)
at nxt.Nxt.init(Nxt.java:149)
at nxt.Nxt.main(Nxt.java:140)
2014-11-05 22:25:58 INFO: Shutting down...
2014-11-05 22:25:58 INFO: Database shutdown completed
2014-11-05 22:25:58 INFO: Burst server 1.1.5 stopped.
why error? 1.1.3 work fine

did you use your old config? with the old config, the server crashes at startup, so you need to use the config that comes with 1.1.5 and modify it according to your needs.

problem was with config, defautl launches successfully

sr. member
Activity: 256
Merit: 250
My password is a random string of numbers and letters, caps and no caps, 30 symbols long. So weak password is not an issue.

It's unlikely that the password was bruteforced, but I think 30 symbols doesn't provide maximum security.
Please correct me if I'm wrong: 256 bits are used in the hash, that's 32 bytes. But we aren't using the full 0-255 character range in passwords, so they should be much much longer. 26 (a-z) + 26 (A-Z) + 10 (numbers) = only 62 chars subset is used for passwords. Using words instead of random letters raises bruteforcing chances even more. The passwords need to be 4.2 times longer: at least 134 symbols!


You're on the right track, but your math is not quite right. If you choose a password from a set of 62 characters, then each character is providing 5.95 bits of entropy (ln(62) / ln(2)). So, if you want to achieve 256 bits of entropy, your password should be at least 43 characters long.
i have'nt looked into the code on how the pk is used to sign transactions but i think it is ecdh based.
doing a google search for the included java code from nxt to do the signing brought up a site stating the sign function is not as secure as the original code where it was ported from to java. this is because java uses different size integers and a c big int variable has only the maximum size of an unsigned int in java (https://gist.github.com/doctorevil/9521116).
someone with java knowledge maybe can verify that the described flaw applies or hopefully does'nt apply to the code in src/java/nxt/crypto/Curve25519.java file or finds out this whole function is only included due to forking reasons.

this in combination with the wallet which offers 12 words OUT OF 1626 by default (html/ui/js/crypto/passphrasegenerator.js) makes it in my opinion attackable.
within an bruteforce attack this is less than 11 bit for each word which sums up to about 105 bits of combinations.
if the ecdh implementation shows the mentioned flaw it cuts internal 256 bit variables at 64 bit.
without further analysis this provides a option to bruteforce wallet generated keys by software designed to utilize this flaw by testing less than 32 bit of combinations. i am no crypto specialist and if someone with knowledge about all this could take a look into it would be great. i think as long as someone uses custom generated private keys even if the flaw exists in the code the required energy to break 105 bits is much more than what you get for the coins in the wallets. on the other hand it may be possible to bruteforce all known wallet addresses in one run without much more costs...

i currently do not understand why someone did'nt empty the whole account and only took 40k.
i dont want to make people panic sell and drive the price down but if you hold a certain amount of coins within one wallet think about all this if you used the wallet to generate your private key.
sr. member
Activity: 462
Merit: 250
My password is a random string of numbers and letters, caps and no caps, 30 symbols long. So weak password is not an issue.

By random, do you mean randomly machine generated, or chosen manually by you?

OS is Windows 8.1, so it stores the password in an unencrypted text file :/

https://www.virustotal.com/en/file/d3992c3d8be28d99b4f58b17a1d7eccbb04ba18e6471bcc3321a82b8011e0475/analysis/1413153796/

Either a false positive or  a very obscure trojan. After initial scam, this is hard to swallow and keep faith. Any insight into why this has shown up Dev?

no threat found on my end. false positive, its common with windows-qt and that particular antivirus


its scanned with 53 virus protectors and only 1/53 come up with a false positive
Alright, just thought I would check, have recently had some malware problems on the machine that hosts my wallets.

It looks like you have recently had security issues.  What steps have you taken to mitigate them?
Jump to: