Java tools should work out of the box. I've also hacked dcct-tools to work on Mac (contains much faster plotter):
https://github.com/r-majere/mjminer.git

Also working on my own miner rewritten from scratch which will support Mac, but it's a few weeks until completion.

I browsed the source code, but did not find where the file is preallocated. Wouldn't it introduce a huge fragmentation? Could anyone compare with a file plotted sequentially?
For ext4 filesystem:

e4defrag -c filename
shows real & ideal fragmentation values,

xfs_io -f -c "fiemap -v" filename
shows where exactly blocks are located.

Btw, from my experiments with dcct's plotter, calling fallocate or posix_allocate before writing to file sequentially produces worse results than simply writing to file given that the disk was initially empty...
Moving the file to another disk and back fixes the fragmentation.

ps. I'm using Ubuntu 14 LTS.

How is the window size (2000) calculated on dev2 pool? I couldn't find any info about this.

That is correct. It needs all deadlines below target deadline.

Could you try dev2 pool for completeness?

A password consisting only of words can be bruteforced by dictionary attack. It's better to add some random characters to these words. It should be very long as well (36+ chars, maybe a few times longer as it's not ideally random).

Storing coins on exchange is bad bad bad idea. It's better to store them on a separate dedicated wallet (make sure it's secured by making at least one outgoing transaction).

Passphrase is not needed for mining on pool. Also, a special version of miner is needed. Delete the file containing passphrase from miner's folder, it's not needed. I assume you've set the pool's address in solo miner's settings and the passhprase was sent to the pool. If that's the case, the passphrase is now compromised.

Alas, some miners don't escape the passhprase properly when solo-mining. I've runned into this when my passphrase contained some garbage chars. This can be easily patched though.

Btw, until at least one outgoing transaction is made, wallet is mineable! Don't send money to newly created wallet.
What was your previous passphrase btw?

It's less secure than using a local wallet, even if you trust website owner and SSL is setup properly etc. The website can be hacked, and it's more likely to become a target of hackers once becoming popular. If you only want to check the balance, this can be done without submitting the passphrase.

It doesn't matter where the files are stored if they can be read fast enough. For 4 tb you'll need to read approximately 1 gb per block.
If read speed is 10 mb/s, files will be read in ~100 s. As many blocks are found faster than that, miner will be able to use only part of plotted space on these short blocks.

Could you check if passphrase is giving the same BURST-... id you used on faucet & exchange?

Are you sure? I thought that the account is protected only by a 64-bit hash and is mineable until first outgoing transaction is made / public key appears on the network, like in NXT. Then it will become 256-bit hash which cannot be bruteforced in reasonable time. Setting reward recipient is also outgoing transaction btw. AFAIK this was made on purpose to allow retrieving early accounts in NXT. Probably not needed in Burst, but Burst inherited this. So, coins transferred to account without a public key should arrive, but the account should be secured as soon as possible.

This is how I understand it, is it correct?

Seems so, search the same address with NXT- prefix. A lot more transactions.

Not only burstcoin, he copy-pasted the same message in other coin thread. Just trolling I guess.

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.

It affects the amount of seeking = HDD lifetime.
Also, lots of seeking leads to slower reading of files, may miss shorter blocks with small stagger.
Treat stagger as "how many subfiles this file consists of".
10 files with ideal stagger (file size==stagger size) roughly equals 1 file with stagger 1/10 of filesize.

It doesn't matter, but it's easier to count this way.

Plot from nonce 800000, not 800001. That would create a 1-nonce gap. 800000 is nonce count, not end nonce.
Also, I suggest using a higher stagger, 1000 will result in a lot of seeking.

UPD:
didn't notice start nonce is 1. I'd use something like:

XXX_0_800000_40000
XXX_800000_800000_40000
XXX_1600000_800000_40000
etc

There's a link at the bottom of page, or simply specify that you're returning user and enter another passphrase.
Do not use these pre-generated words.

Googled it up and this account was already active on Aug 26. Could be a trojan in one of the first third-party binaries.
Which software were you using?

No, password cannot be changed. You'll have to create a new wallet and replot.

No ideas.


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.