Topic: Mining Simulator with Lua scripting support (Read 2792 times)

down, yet.

The simulator is down, is that on purpose?

I just got back from out of town and was checking in on a few things, if you are working on it then best of luck and I'll wait patiently.

Nice feature list, looks like my wish list pretty much.

The TH value troubles me because you are locking in the difficulty in the parameters, but then the network size is being coded in instead of derived from the difficulty or retrieved from a current data source. It's an inconsistency that bugs me, I guess.

Thanks for the update!

I've had some ideas and I'll work on them this weekend - hopefully.
- getExchangeRate(time) -fiat/BTC rate, so you can assume bitcoin doubles in value by 2014 or whatever.
- hardware will be priced in fiat and upon purchase BTC will be deducted as per exchange rate.
- power cost will be priced in fiat, BTC balance will be deducted as per exchange rate.
- hardware presets so you can just do addHardware(bASIC_72)
- start using POST so script limit is no longer an issue
- for the above reason I'll need an option to store settings and generate a link to load them up for sharing simulations.
- dump results out in a HTML table
- option to dump as CSV for excel import

I guess I could add a function to grab estimated hashrate from somewhere, but you'll be extrapolating this figure anyway which will introduce far more error than an invalid starting hashrate would.

If you have any ideas throw them my way so I can hopefully work on them soon.

more feedback...

I like the new chart, except that the balance field is wrapping for me. can you make the window wider, or variable width so I can see the rows without wrapping? I'd rather NOT have a horizontal scroll bar on the window, if we need on it should be on the page IMHO.

numbers are coming out better, matching up with a similar sheet I have in excel, no more 2Bn difficulty issues.


I noticed that the TH value is still hard coded in the script, any chance of pulling that from somewhere? I'm also commenting out your drop prediction since I'm seeing an increase rather than a decrease.

The big issue I ran into was when I started working on a more complex model. If you have too many lines of script it does not take it due to the URL being too long. Are there other options besides embedding the whole script?

Keep it coming, I like this thing.

That's part of it, I expect a couple price drops and capacity improved models to show up during the year. the 3x model is one with lots of worst cases in it, but if I can make a profit there...

$:BTC Ratio
BFL Chip Numbers
BFL Planned Upgrades

The biggest factor I included that Ploo didn't is the BTC:$ ratio. I'm assuming that BTC value at the end of 2013 will be at least $25-50, and might be as high as 100. The $100 scenario is the one that drives that model, so 2.4PH is possible. BFL alone is planning on selling a MINIMUM of 750TH this coming year from their first chip run alone, if they rev later in the year the total number of chips shipped by them could exceed 150k for at least 1.5PH of just for BFL. I'm guessing Tom will also have a second hardware generation and will ship 300-500TH, similar for Avalon and ASICMINER, 1/4 as much for DeepBit. This is mostly a supply-side model based on preorder numbers, announcements and estimates.

If the BTC value does not go up much, then it will be much less (like 1/10 to 1/3 of my worst case model) because we will be constrained on the demand side (like your model), but I don't see BTC NOT going up from here.

I've actually been revising my models today in light of the bASIC delay and a few other items, and I'm down to Difficulty 250M, Hashrate 1.8PH by 12/31/2013 now, but that kind of movement is typical that far out, the error bars are huge.

That's bASIC pricing though and they're extremely unlikely to be able to produce that much hardware. Everyone else is much more expensive. Still I think the assumptions of difficulty increase are entirely too high. Miners will not simply act like lemmings and mortgage everything to pay for more and more hardware that just loses money for them(well some might), but most will notice they're not moving forward.

Hmm wow. I checked his forecast

So you're predicting a difficulty of 108,013,368 x3; or ~300Million by the end of 2013? Or something along the lines of 2400THash? Holy smokes. At the current Pricing of ~$15/GHash that would be $36.6Million in hardware, or 1/3 the total bitcoin econ. I'm curious what makes you expect that.

Glad you appreciate the feedback, I understand completely on the mining forecast parameters, I just wanted to check since you used a brand name instead of a generic term for the variable. I have been forecasting about 3x the difficulty at the end of 2013 that you have right now, but that is pretty close given the limited data we have to work from.

I see that the first few fields have been updated to not allow changes, I like the approach of graying them out.

Could you add a rounding function to the report output on the "your rate" field down to 4-5 decimals max? I really don't need this much precision, and it messes up the formatting. (sample: 0.27630000000000005 (0.86%) I have no idea where the 5 at the end came from, my values are .0003 and .276 at this stage.) I also think that making this into 2 fields (TH, %) would be cleaner and allow easier import into Excel, etc.

An "Earn/Day" number would be nice in addition to the balance, I can do the math, but it's nice to have a direct comparison to other calculators.

Difficulty is still capping out at ~2Bn, not sure if you have tackled that yet.

Another item you might want to consider would be a streamlined input panel for the addition of hardware. Adding multi-line table with a calendar picker and drop downs or something would make it more usable for the non-geek bitcoin finance type guy.

I'm PM-ing you my current long term script, but I'd rather not publish the whole thing.

The hashrate function is purely my personal speculation. It's based off that I personally believe bASIC will be the first to ship, near the beginning of December and we're told it'll be 900 units. The remaining bajillion TH that are introduced over 2013 is just a guess and should not concern any particular ASIC boards, just more hashes every second. The scripting is there so you can feed it your own calculations.

Although an idea I had is to have preset hardware with the appropriate names so you can just do addHardware(bASIC_72) and it'll adjust the simulation appropriately from a preconfigured dataset. In all honesty a user could do this themselves.

For obvious reason last retarget has to be a date in the past (with respect to simulation start), and realistically in the past. If anything is off it'll give misleading results. For example if you were to mistakenly give last retarget as four months ago even though it was 13 days ago the next difficulty adjustment will double the difficulty even though the actual hashrate shouldn't dictate so. And then the next adjustment will try to correct this. I'm considering completely ditching simulation start/difficulty/last retarget/block and have these values be automatically grabbed and used. I've given some thought to this and I can't really see why the option to set custom start parameters is at all necessary. What do you think?

I'll make the difficulty field a long.

I don't know how helpful the lua api I'm using is about any syntax errors but if there's anything I can feed through I'll do that.

Thanks for the quality feedback.

OK, this is interesting.

My biggest question is where the entries for BFL, AVALON, etc are on this, I only see bASIC contributing to the future network.

I've played with it enough to get the hang of what is going on. A few comments would go a long way to help.

There are some weird bugs I've seen when trying to change the "Last Retarget Date" to a value in the future, negative difficulties and stuff. Should this say "previous" or something or add some validation?

There is also a limit of 2 billion (and change) on the difficulty, can we get a bigger data type there?

There is also no help at all if you screw up your script syntax, in fact when I was adding another year of ASIC's for a long forecast and forgot a "+" it gave me a "Server Error" page and I had to hit back and fix the script. (luckily that worked) Maybe you can put an error checking wrapper around the user script that at least does not refuse to submit?

Nice idea, looks like a useful tool as it evolves.

Updated default script - now assumes 40% of the hashrate drops out on block halving day.
Added a onDay hook and addHardware(price, hashrate, powerdraw) funtion. Allows you to add more hashrate to your simulation on a particular date.

Hmm, well it does seem to spit out more than a month at a time now, so I can't recreate that aspect. So ignore me there

If you let simulation start date remain you don't run into any issues apart from the fact that it won't let you run for longer than a month? Anyway, there shouldn't be issues with running it for longer, maybe you're entering the dates wrong?
Try this:
http://goo.gl/lhKPR

Does it spit out a whole year of simulation?

Well it happens regardless of the date, but sure.

If I leave the page at default and simply change:


the output becomes:


I don't have your code, but I believe that it uses the "Last re-target" entered in settings as the starting point, so that if you enter a later date into the simulation it assumes no retargets since that point (in this case, from 11-12-12 to 12-22-12 no retargets occur, when suddenly 72.6TH/sec comes online, rips through the remaining 400?-600? blocks, and calculates the retarget for 48 days of hashing time, lowering diff to 1.1M, which is then ripped through by 72.6TH/sec in about 30 hours, raising diff to 10Mil).
Which is why I said that I would need to calculate the last re-target manually (and potentially what block we would be on) to use this.

I don't want to burden the page with output, but any start/end date > 30 days apart will only output 30 days of simulation.

That's probably a bug. Can you give me the exact settings you used to get that issue?

Seems like it could be useful.

I find it a little bit obnoxious that I can only output 1 month at a time though, and if I want to look into the future I have to calculate for myself what the difficulty and retargets would be at that time, and enter it manually, or else the defaults give me things like:

Date      Network (Th/s)      Block      Own Rate (Th/s) (%)   Balance
2013-01-12   95.35         209553      1.5 (1.57%)      441.54
   Difficulty re-target: 758324 (2013-01-13 04:38:23)
   Difficulty re-target: 13770736 (2013-01-13 23:08:33)
2013-01-13   97.32         211685      1.5 (1.54%)      1,437.59

Other than that, perhaps take into account the loss of GPU miners at halving + ASICs coming online? (When 48THash comes on and 25coin blocks are here, a large chunk of GPU miners are going to go dark).

This afternoon I worked on a little mining sim sorta deal that's a bit better than what's available currently. It was mainly an excuse to get familiar with AppEngine and then implementing Lua for a bit of fun.

http://bitcoineering.appspot.com/simulator

- Left column concerns the network situation. The last retarget field atm is hardcoded and won't update dynamically - couldn't find a good source on that.
- Right column concerns your own mining efforts and finances involved.
- Logs the status after simulating each day so you can see exactly what's happening day by day.
- Simulates difficulty adjustments.
- 25 BTC reward upon block #210,000 onwards.

The script area allows you to use Lua to write your own functions to be used in the simulation. So far only a hashrate prediction function works. The function takes a parameter of time which is a UNIX timestamp in milliseconds. The Lua environment also has some helper functions for interpolating between dates and the likes.

I'd appreciate if the mining savvy ran some checks on my calculations. I did and it all seems to check out but you never know.