The real question would be if the capacity being offered was pre-plotted under one accid and you were purchasing a % of the entire capacity, or if it was plotted on demand with individual accid's. My thoughts would be that a % of a pre-plotted capacity would yield more winning blocks than plotted on demand, as it would have a bigger chance per block of finding a winning d/l

It would all hang on the length of the rental period. In a years time from now, the block reward will be about 55% of what it is now, on a one off payment it would be option 10, but on a monthly fee i would choose option 5 or 6 unless the price of burst hit a sustainably higher price. If the price dropped, i would have to reconsider

I did however forget to ask how long the rental period was, as if it is for the next 10 blocks only, it would have to be option 5, otherwise it would increase depending on the rental length

@rds i find myself agreeing with @kingcajun on this. The more possible deadlines available to be found would easily outweigh the speed to scan the files as block times can vary greatly and some are sub one minute, whilst others take well over 10 minutes

@vaxman thank you, i was just curious on this point rather than it being a life or death question, as optimizing plots gives a lot of scope for miscalculation in size. Blago reports my meagre plot size in GB, not TB, and it was more a conversion calculation between the two sizes purely for optimizing, so perhaps i should have said burst pools instead of burst

@gpedro though that was the case, but now onto the next question......

How does burst measure the plotted capacity?

Hdd manufacturers measure capacity differently to software, so you end up with a discrepancy between the physical size of a drive, and the reported size.

Which one of the two would you need to use for plot optimization as there can be a huge difference between the two (e.g. My 8tb drive has just over 8000000000000 bytes, but is only 7.27tb)?

Thanks 😀

Hypothetically, if i was to run 2 identical mining rigs for two separate accounts, if i plotted nonces 0 to 200,000,000 on each of them, would they generate the same d/l's on each block, or is the contents of the plot file affected by the accid used to generate the file?

I ask as lots of miners will have nonces 0 to X as people generally start at 0 and work upwards, but can't figure out whether if 2 people submit the same fastest d/l for that block, the person with the oldest accid wins, or the first to submit.

I have a feeling that the plot file contents is affected by the accid (meaning each nonce between 0 to X is different depending on what accid is plotted for and the size plotted), rather than multiple people submitting the same winning d/l and it being down to a second roll of the dice as to whether they win the block or not

The other wallet/db running issue, you just need to select the option to run the new one rather than the one running. Make sure you have created an exemption for the whole qbundle wallet in defender as well. Ensure you have upgraded the whole qbundle application, but delete the blago folder before doing this.

May work, may not, but worth a try

@mrwho i just uploaded it. What do i need to install and run to get the the process to start and get it to use the ejs files?

@mrwho So, I have made a little progress, followed by a major problem....

I had a look at the faucet you mentioned, and then set about trying to replicate its features

Created the subdomain - faucet.bluebookinvestments.com, created a custom folder for the subdomain and extracted the download into it

It looks like this -

I updated the relevant files with API keys, burst wallet etc etc, and this seems to have gone through without a problem

So far so good....

However, on accessing the domain, I get a list of the files in the subdomain folder, rather than the verification page.

If I copy the contents of the client folder into the root for the subdomain, I get the chance to verify (indicating that I have got the API Keys correct), but upon doing so, it just asks me to verify again and again (etc etc) and never goes any further

Accessing via subdomain/client allows the verification to process, however once verified, it takes me to the subdomain and displays the following

The faucetConfig.js file looks like this...
which I believe is acceptable for it to work correctly

Now, I am possibly missing some vital piece of information, but I cannot see what, and a pointer in the right direction would be greatly appreciated