Posts made by guytp

Are the plot files optimized? I saw a speed difference of 20 to 95MBps with creep on optimized vs unoptimized.

There's a calculator over at http://burstcoin.biz/calculator - but take 20% off in my experience - so you can expect around 3500-4000/day with that amount. If you did manage to get 56 drives for 10k ($22/TB is pretty good) then forgetting any other cost you could return investment on just disk cost within 6 months. I'd guess within 9 months to cover everything.

Difficulty has gone up significantly recently so as always take with a pinch of salt. If you can buy disks at $22/TB though I expect you'd recoup a lot selling the drives afterwards if everything didn't work out.

Shameless cross-post but I only noticed this thread existed after I created another one. I've just created a new cross-platform miner that I intended to use on my Pi. Performance isn't fantastic as it's a PI and I definitely think the Nuc is a better option but it does work so if anybody wants to take a look check out the thread at https://forums.burst-team.us/topic/6627/rpi-arm-cross-platform-architecture-miner-anybody-interested

Hi,

I've been looking into use of RPis recently and there are a number of issues with this and your setup. Will it work? Yes - but it will be super slow and won't generate you many Burst from 160GB being processed really slowly.

Can you connect 10x16GB USB sticks - yes. There are a couple of issues here though worth noting:

• It won't be fast to process per-plot. The RPi only has USB2 and you'll be sharing a single USB2 port for all of those devices being scanned plus the zero hasn't got much CPU power. Combine both of these and realistically you'll probably get a read rate of around 5MBps at the top end across the entire device with a Zero's resources
• This isn't much plot space to start with - expect to only generate around 30 Burst per month. At current rates that's going to be over a year to ROI on the hardware if you're buying it fresh.

The speed issues for 160GB may not be a big issue. Each round you only read 1/4096th of your data so 40MB here which will only take a few seconds. The biggest issue is the lack of plot size. If you were to get more data then with a Zero I suspect 2-3TB is most you could have before the mining speed ended up being slower than the round speed (meaning you'd never get to finish scanning your data in most cases). A RPi 3 could probably double this (as a frough guess).

Plotter - if you have Windows somewhere I'd recommend using xplotter in Windows to start with. The Pi has such low compute power that plotting is going to be incredibly slow. Generating a plot is so much more intensive than mining it (literally thousands of times more so) and the device has such low memory that I'd try and stay clear of it.

Miner - I just wrote one that will work on the Pi (see https://forums.burst-team.us/topic/6627/rpi-arm-cross-platform-architecture-miner-anybody-interested) there is also this thread (https://forums.burst-team.us/topic/786/raspberry-pi-miner) discussing it.

Blockchain is gigabytes - so it will take a while to download. The wallet can operate in two modes - local (where you have the blockchain) and remote. I suspect Linux one is just running remote. You don't need the wallet or blockchain installed on your miners to mine and you don't need it to plot. You don't actually need it at all.

Copying plots - think of each plot as a lottery ticket. If you photocopy it you still only have one set of numbers. Same is true with plots - you cannot copy them as you just have same data twice. You need to perform a second set of plots with a different start nonce (the start nonce is in effect the set of lottery numbers being written to your ticket). Deadlines are calculated by doing some maths based on current block and the details in your plot (which is ultimately based off a number and your account ID). This maths just gives a number which is then a number of seconds that defines your deadline.

If you to spend money on a low-cost and low-power box dedicated to this a low-end Intel Nuc would probably be a much better bet at around $100 but with USB3. I'm currently building a J1900 4-core celeron (10watt TDP) to see how that performs. That's a factor of 30 less than my desktop but still more than a Pi.

Hope that's some help!

Guy

For anybody that's interested I've just created the readme detailing current state of the project and installation instructions over at GitHub and a first release of the miner.

GitHub Readme: https://github.com/guytp/burst-sharp

Miner v0.1.597: https://github.com/guytp/burst-sharp/releases/tag/v0.1.597.0

There are a couple of issues here. First may be simply that G: doesn't exist in an admin command prompt (Windows context differs between admin and non-admin users). If "dir G:" (without quotes) doesn't work in admin command prompt do "net use G: \ComputerName\Share" to map the drive for admin. I still don't think this will fix it though - I believe with xplotter it tries to expand the file first for much quicker writing. This doesn't work across a file share though as you can only do this command (in Windows itself - not an issue with xplotter) for local disks.

To use xplotter you'd have to run it not as administrator - this means it would go back to older way of creating the file but this is really slow. To give you an indication I tested this recently plotting a 4TB disk. I got through 30% of a plot locally versus 2% across a network in the same time.

That being said there's nothing inherently wrong with plotting across the network - it just means you'll have trouble creating fully optimized plots in a single hit to start with. If you do want to plot across network you'd be better off trying some different plotting software as xplotter seemed incredibly slow for me. Not sure on recommendations for Windows but I used mdctt on Linux to do some network plotting and was able to get good write speeds (12K nonces/min with 10GB RAM in use and 10GB files - buffering whole lot seemed best for me but obviously didn't leave fully optimised plot files at the end of it).

In terms of mining it should be fine if your network and disk are up to spec. You can pull ~100MBps over gigabit networking assuming you aren't using WiFi. I'd definitely recommend having fully optimized plots though as otherwise the latency of network will make the speed seem apparently much worse than unoptimized plots on a local disk in the tests I've done. That being said I've been able with unoptimized plots across a few different NAS hosts to read 16TB of data in < 2 minutes - not amazing but enough for all but the fastest rounds and better than not using the storage at all.

Hope that helps a bit!

I found this really difficult when I was try trying to look into it. There is a flowchart about half way down here which explains it pretty well - https://www.burst-team.us/index.php/about/ - from memory I believe some of the things which are defined as 32-bytes are actually 64 in the current implementation. I had to take a look at source to confirm a couple of things.

In essence:

• A plot file contains a number of nonces
• Each nonce has 4096 scoops in it - this is just 64 bytes of data within it
• When a mining round starts various information (the block height and previous block) determine which scoop we look at
• Consequence of this is we only ever mine 1/4096th of total plot space
• Each nonce in each plot looks at just that specific scoop
• For each scoop examined the data is combined with a hash of previous block and then hashed. This hash is then divided by a "base target" that also comes in with the block headers from the network. This gives a deadline in seconds.

So huge amount of upfront work generates some bytes on disk then 1/4096th of them are then hashed each round with current round information and divided by a network-calculated number to give a deadline in seconds. So your same block/scoop will give a different deadline each round - there's no benefit to having a particular account #, nonce or scoop # other than in that very round.

Benefit of having lowest deadline? Simply you win - it's a bit like a lottery ticket valid for a single use but with added benefit that there are a large amount of winners and only the person that hands it in first can win - so if you have a low deadline you hope you get yours submitted first.

Benefit to network? Not sure deadlines themselves offer a particular benefit (or at least I've not seen anything about it) but it is a way to "prove" capacity and to give different miners different results. If this step didn't occur how would you decide who had won? It's this step that, in effect, adds the random-winning potential to your generated data.

Hi folks,

New to forums and I've been looking at Burst for the last month and have been having a play around with it. I thought best way to get stuck in would be to dive into the deep end and write some plotting and mining software mainly for fun. I know there's already tonnes out there and this may not bring a lot to the table but I thought I'd share it.

What I've ended up with from a mining perspective seems to work fine. I've designed it so it can relatively easily run on a whole selection of hardware - not just x64 PCs. Specifically I've tested this on Windows/Linux PC builds as well as a Raspberry Pi running Linux. It should also run on any ARM-based CPU that can run either Windows ARM (8+) or Linux (Ubuntu easiest for sorting out dependencies).

I haven't packaged this as binaries yet or with installers as I'm not sure if it's even of interest to anyone considering the selection of software that's out there already. I'd like to get an idea of whether anyone is actually interested in using this. If people are I'm happy to put the time in to keep it maintained and also pick up work around a plotter for this as well.

Feel free to check the code out for now at Github: https://github.com/guytp/burst-sharp - it requires Dotnet core to be installed to run it (I did a recent YouTube video on this with supporting instructions at https://guyrobottv.wordpress.com/2017/06/23/installing-net-core-2-on-a-raspberry-pi/). If anybody wants a pre-built DLL for this now to have a play with I can put one together.

If anyone is interested let me know. As an indication RPi mining (over a network share) was ~5MBps on some unoptimised plots that accessing same share/plots via a PC running Creep was pulling 20MBps. Haven't done any direct USB tests yet. Whilst I'm not sure the Pi is the solution some of the Octa-core ARM boards with USB3/gigabit ethernet could well be an incredibly low-powered way to run mining farms which is what got me thinking.

Thanks,

Guy

BURST-DXGM-62RW-X8G6-A493G