Hummm, the purpose of the rehashing is to get a target a hash that is equal or less to the real input hash so with that example aren't we going to get anything above the hash (if true )
real input hash is irrelevant here, the "hashed" version of the input is what matters to solve a block, let me try to simplify the subject as much as I can, when you start hashing a new block you would take the previous blockhash and let that be "1" and the current target is a number that starts with one zero "0" target and difficulty are basically the same thing represented in an inversed way to explain the same thing, but let's just say it's a number that starts with a single zero. Now go to a SHA256 hash tool like https://emn178.github.io/online-tools/sha256.html and input the previous block hash which is "1" No matter how many times you try to hash that blockheader, you are always going to get 6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b But what you need is a hash that starts with 0, so now you add a nonce to it in order to produce a hash that has a single leading zero, so let's try to add 1 and hash 11 (first 1 is the prev blockhash, second one is our nonce) result = 4fc82b26aecb47d2868c4efbe3581732a3e7cbcc6c2efb32062c08170a05eeb8 = no block let's try 111 f6e0a1e2ac41945a9aa7ff8a8aaa0cebc12a3bcc981a929ad5cf810a090e11ae keep trying randomly, I got mine at 156 so nonce 56 got me a valid block. 0fecf9247f3ddc84db8a804fa3065c013baf6b7c2458c2ba2bf56c2e1d42ddd4 Now let's assume difficulty has increased, which means the hash needs to start with 00 not just 0 so you take my first block hash which is 0fecf9247f3ddc84db8a804fa3065c013baf6b7c2458c2ba2bf56c2e1d42ddd4 and add a nonce to it, hash them together, to get 00xxxxxxxxx, I was actually very lucky with this random nonce "3010023340584300011" hash > 0fecf9247f3ddc84db8a804fa3065c013baf6b7c2458c2ba2bf56c2e1d42ddd4430100233405843 00011 = 00c0a543e028d4e08d8b6e81cf3a5e1f43b57b20723d1c6625e09e788a69e3ce which is a valid block. Obviously, since Nonce is pretty small (~ 4 billion value range) it's exhausted in no time by all ASIC miners, the average miner today can do 100TH/s, which is 100 trillion double sha hashes per second, so changing Nonce alone isn't practical and there needs to be something else to reset it. The good thing about hashing is that any little change you make to the input would generate a completely different output, miners would use Extra Nonce and nTime, as ranochigo explained above if you have [nVersion, PrevHash, 28 bytes of merkle root] + [4 bytes of merkleroot, timestamp, difficulty, nonce and padding]
In your input, anything you change there would mean a new set of possibilities, of course, there are things that miners today can't change (given how mining pools operate) but then mining pools would give a different block template to every single miner and the miner would never run out or rehash the same inputs. To give you another "real example" let's just hash the text I quoted above and start with 1111 once [nVersion, PrevHash, 28 bytes of merkle root] + [4 bytes of merkleroot, timestamp, difficulty, 1111 and padding] let's assume the max nonce I can use is 9999, so I did try up to 9999 but couldn't find a hash that has two leading zeros, what can I do now? I will change a tiny bit of the timestamp chunk and make it timestamp1, even without changing the 1111 once I still get a new different hash which is b80e254e1edba8fbc10ab93ceab7eec458ea949b947ce8506b0f543418c29add Think of Nonce in colors, you paint a picture and somebody is waiting to see a certain final mixed color, your base color can be changed but the colors you add are pretty limited(green and yellow), so you created your base color by mixing blue+red, you added green, it didn't work, you added yellow -- didn't work, you added 0.3 yellow and 0.7 blue it didn't work, you run out of mixing options and the desired color is not there yet, you go back to your base color and add some orange color, now that 0.3 - 0.7 mix would result in a new different final color, hope that makes sense. Obviously, the actual mining process and the blocktemplete are a lot more complicated than my explanation above, but essentially, it is how it works.
|
|
|
could be correct. but I do like that we are around -3%
We sure are getting what you hoped for phill, it's 2011 blocks already so only 5 blocks to go (50 minutes give or take for difficulty adjustment) and the current pace is Current Pace: 96.9336% (2011 / 2074.62 expected, 63.62 behind)
So 3%~ is guaranteed at this stage, with the current BTC price of $61,447 this is going to be a good epoch for miners, not as great as when fees skyrocketed a while ago, but certainly better than the start of the current epoch.
|
|
|
it if it is supposed to be 400 volts and the power company feeds it 380 volts due to hot weather etc. and it may do more with 420 volts feeding it.
They are going to feed it with 20KV, and then there is a tap changer on the transformer which the electric company will play with to maintain the desired output according to the country code -- since it's impossible to get 20KV across the whole 20KV line, transformer taps can be changed. So given that his transformer states 20KV high-side and 400V low-side, it simply means if you feed it 20KV it would output 400V if the tap changer is set at default which is usually no.3, now say you are the first transformer on the line, you will get more than 20KV (it needs to be so that the last person can still get 20KV or close), so if yours gets 21KV the electric company would reduce the tap to say no.2 (not randomly -- it's all on the transformed plate), on the other hand, if you are somewhere at the end of the line and getting only 19KV, they would increase the tap to maybe 4, or 5. The standard where my farm is is 220V, the guys who installed the transformer insisted that I need to keep it at 2 so that my low side voltage is 220V, but I insisted on wanting 230-240, so after back and forth with them they set put it at 3 at my own risk and call them if i changed my mind -- now my low side voltage is at 239v without load, and 235-236v on up to 1MW load, I like these numbers so I never called them back to come change it. BTW, I wonder what country that is that has 20KV lines, here we don't have that, it's 66kv > 33kv > 11kv is the last HV that feeds the consumer transformer.
|
|
|
250kVa cooling type: ONAN freq: 50hz rated voltage: 20.000/400
How many 1phase , 220v , 3500 watt cryptocurrency servers can i run simultaneously without damaging the transformer ?
*In on other words, how many amps can each phase withstand , by approaching the limit but without damaging the transformer ?*
It should be stated on the transformer itself, but the formula is I= (KVA*1000 ) / (V * square root of 3) I = 250*1000/400 * 1.732 = 360.8A but that is for 400V, which isn't all that important to your case, so you need to figure out the 230-240V (should also be on the transformer plate) but you can use the same formula without the square root of 3 I = 250*1000/240 = 1041A But you won't be able to pull 1041 of a single phase, each phase would be maxed out by 1041/3 = 347A or 83KW 83/3.5 = 23 miner on each phase or a total of 69 miners, but that would be pushing the transformer at 100%, stick to NotFuzzyWarm's adive of at least 20% off, and that would give you 55.2 miners total, but you can't do that so 18 miners on each phase with a total of 54 miners (I rounded the numbers which is why I got you 3 miners less lol). Obviously, you need to account for cooling, and safely put 10% of the load for that, so cut another 10% from the 54 miners and you get 48 miners only.
|
|
|
I think you can try to use other Braiins pool servers they have other pool servers and only choose a server near your country or a country where you live.
I highly doubt that would change anything, this doesn't seem like a connectivity issue but rather a compatibility issue, it's pool-firmware related and there is probably nothing he can do about it except changing the firmware or the pool, obviously, it depends on his preference, personally, I would change the pool, if that is not an option (which I can't see how) then another firmware would fix it, try the latest S17+ firmware or contact Braiins pool team.
|
|
|
To me it seems that a reduction of -2% more normal, than 5 or 6, after such a big rise in the previous cycle.
I believe I did make this claim a while ago that anything above 3% increase in any epoch is not realistic, assuming the current hashrate is 560 then every 1% is going to take 5.6EH, but even a while ago when 1% was 5exahash we are talking about 5,000,000TH, if you assume it's all brand new latest gen 200th~ gears, then that's 25,000 gears, so 3 times that would give you 75,000. Convert that to money and you get 75,000*$ 5000 = $375,000,000 (not counting tax, transport and all the other stuff) Convert that to electricity and you get 75,000*MW0.0035 = 262MW jump to 4% and you get 500M dollars and 350MW which is 100k gears. I can't be convinced that there is any solid possibility that suggests the world is able to sustain such an increase in two weeks, 100k top-of-the-line mining gears is just not possible, there will always be a bottleneck somewhere, be it in the manufacturing of these gears, transporting them, the cost, the power, the time, the delivery, the paperwork, it just doesn't matter, I just don't think it's doable. Now going back to the 8% 'fluke', we could to some degree assume that 3% was real, and 5% was variance, this means if we have a real 3% increase this epoch as well and 0% variance we should drop by 2%. This epoch won't be variance free, we may have a 1% variance and end with -1% or -3%, but if we assume not much variance then anything around -2% is very realistic and suggests a massive increase of hashrate by nearly half a billion dollar worth.
|
|
|
KYC is not the only reason why to avoid antpool, there fee structure is scammy at best, while their FPPS fee is normal (4% which is the norm today), their PPLNS fee is sold as "free" when in fact, they keep 100% of the fee rewards, so in most cases, you end up paying a lot more fees than mining on another PPLNS pool, so be careful when you chose your payout method, never do PPLNS with Antpool.
|
|
|
Mike plug in 2% and that is more like a 1 in 4 shot. then back to back 1 in 16 shot. which is around 1 time every 64 weeks
2% variance in a whole epoch has a chance of 18.42%, mind that given the K (the shape parameter) is constant the variance in either direction would yield the same result, although in my previous code the code would get the wrong result if you enter -2 instead of 2 in the percent parameter given this line formatted_result = "{:.2f}%".format((1 - cdf) * 100) removing the 1 - and changing the line to formatted_result = "{:.2f}%".format(( cdf) * 100) Would work fine for negative % but obviously not for positive, I could add a simple function to check the value and format the result accordingly, but I don't think it's needed. So I lean to back to back 2% 1 of 16 shot. (mike can plug this in for exact number) Using your logic 2% is 1 in 5.426, so two consecutive events would be 1 in 30.72, that is 3.25% in percentage terms. But then, this is based on the assumption that in the second epoch (the current one for our case) is indeed affected by 2% or more variance, but if we assume that the previous epoch had a 2% luck, then his epoch would end up with -2% change while having 0% variance because the expect variance is 0%. if we do indeed end up with a -4% which is 2% variance then that's 3.25%, however, we have no way of knowing what the heck is going on, 2016 blocks make a very small sample, if Satoshi made the difficult adjustment twice a year, we would have enough blocks to guess with. With the size of 6 months' worth of blocks, the probability would be 1>% = 5.2% 2>% = 0.06% 3>% =0.00007% (almost never) VS 2 weeks' worth of blocks 1>% = 32.4% 2>% = 18.4% 3>% = 9% With the 2 weeks epochs, you can't be too sure that this epoch isn't having a 3% variance since 9% is relatively a huge figure, if we have diff adjustments only twice a year, then you could almost always assume that variance is never above 2%, in fact anything above 1.5% drops to below 0.7% so ya, assuming no epoch has a 1.5% variance would be a safe thing to do and you would really tell how much hashpower was added or left, but with two weeks worth of blocks even 5% variance has a good 1.3% chance of happening, so there is nothing you can do to safely eliminate a 5% variance, let alone 2% that happens nearly 20% of the time.
|
|
|
But, having a combination of luck during an entire cycle? Well, it really takes a lot of luck.
3% or more luck variance happens in 9% of epochs, that is a high probability, 4% variance happens in almost 4% of cycles which is still high. Basically, nearly 1 in 10 epochs is subject to a 3% or more luck, nothing out of the ordinary here, run the code i posted above and you will understand how small of a sample is 2016 blocks with mean of 10 minutes.
|
|
|
I side more against variance for this drop and more for retooling.
With last jump being overclock the fuck out of the older s19 pros before you take them off line to sell.
He sides more with luck altering the numbers.
Not that I don't want to take sides here, but I am guessing both theories are valid, and I would side with stompy a bit, not fully discarding the abuse-before-you-sell approach which is probably true for many farms (I have traded thousands of used gears and I know a thing or two about the subject), but I think it's more of a variance than the other option, maybe 70%-30% or 60%-40%, but noway it was all just overclocking before you they could sell. My reasoning behind that is if there was room for 50EH to come online from a sustained overclocking it would have been the case long before, if you can safely abuse these gears for 2 weeks and have enough cooling not to kill them right away, why wait till now? also, usually, and from my own experience, most large sales are done in test and pick-up rather than ship away, someone who wants to buy 10M$ worth of gear would come to inspect the miners, see them run, then by them, those ready to ship are usually small in size. So, is it possible that 5EH or so was the result of overclocking either for abuse or stress test for clients? yup it is, is a 50EH overclocking sustained for a whole epoch? probably not, so ya I'd guess it's likely a combination of both things with luck having the bigger impact. I think we will find out soon tho, don't you think? that missing 50EH would come online soon, accompanied with the new gears replacing them, we should then see at least 15-20% increase in difficulty in a month or so time, which I don't think is going to happen, obviously, I could be wrong. Sorry to hear that, but you could take Phil's approach and have a dinner tin german restaurant , some greasy bratwurst mit sauerkraut would either make your write that in 2 seconds or quit doing anything for the weekend. Food makes me feel sleepy, especially if it has red meat in it, I sure won't be able to write shit lol, but ya I just had my dinner at 2 AM, going to be my last reply for the night. But seriously, if you're not feeling well take care, with all the shit in this world you don't know what a headache might be caused by.
Luckily, I know what's causing this one, terrible weather and a lot of real-life work, too much thinking, and lack of sleep. I'm saving all the popcorn for the halvening, these few adjustments are like the commercials before the movie, once that kicks in I'm going to watch the diff block by block, hutting all the press releases and hoping it will finally bring some sense in the market. The halving is going to be frustrating to all miners that's for sure, I would hate to see it happen with a price below 60-70k at least, just imagine the price drops to 30-40k right before the halving, that's going to take a lot of popcorn dipped in a chocolate fudge to digest.
|
|
|
We're discussing and speculating each giving some arguments and not getting convinced by the other's.
I tried to figure out what the exact argument is about but I am not feeling too well, took me like 30 mins to write a 10 mins code, so is it true that you think this is all just luck while phill thinks the 50EH or so was actually present in the previous epoch and vanished today? would appreciate a TL;DR summary of what are you debating so that I don't take sides blindly, although, as usual, if it's a guessing game I rather be on the other side that you are debating given your track record of terrible speculation.
|
|
|
the formula assumes perfectly equal hash . ie 1th anywhere is completely equal.
Correct, it assumes no change in the actual factor that directly impacts the frequency of the events, which is why you just can't tell, looking at the previous epoch which had an 8.24% increase, assuming there was no change in the hashrate in either direction, the chance of that happening would be 0.016% which is pretty damn low, but if we were to assume half of that increase was actually caused by gears combining online and only the 4% was the result of luck, the chance of that happening increasing dramatically to 3.9%, if we assume it's 5% actually gears then that 3% is 9.3% chance. The same would apply to the 288 blocks, if half of that assumed 25% is the result of gears combining online, and we talking only 12.5%, then that's a 2.27% chance, if we apply the same logic to 5% vs 3% and say roughly 17% was actual gears and 8% was luck than that's roughly 10% chance. So ya, there isn't much you can takeaway from all of these guessing, except having a nice conversation with fine gentlemen like yourself and stompy. edit: in the above, I used Poisson distribution function which is mainly "discrete probability distribution that models the number of events occurring in a fixed interval of time or space", I changed my code to use Erlang distribution which is " a continuous probability distribution that models the time between events in a Poisson process", while both have nearly similar results there is a slight difference, and I believe for the case in hand, using Erlang is more accurate. Here is the code I wrote, which is pretty straight forward and would get 100% accurate result. from scipy.stats import erlang
# Define the mean (expected events 2016 for a whole epoch, 144 for 1 day worth of blocks) mean = 144 # Define the percentage change you want to evaluate percent = 5
# Calculate the threshold (don't change) threshold = (1 + percent / 100)
# Calculate the CDF for Erlang distribution (don't change) cdf = erlang.cdf(threshold * mean, mean, scale=1)
# Format the output to 2 dec points (don't change) formatted_result = "{:.2f}%".format((1 - cdf) * 100)
print("Probability of having {}% or more additional events in {} blocks is: {}".format(percent, mean, formatted_result))
You can copy and paste this code to any online python compiler like this one https://www.onlinegdb.com/online_python_compiler if you want to run your own numbers, all you need to change would be the mean and the percent, the code I pasted above uses 5% or more blocks in a single day (144) blocks, if you want a whole epoch and 2% you would change the 144 to 2016 and the 5 to 2, let me know if you have any troubles running the code.
|
|
|
If you have a 25% variable in 48 hours why is 8% instead of 4% so impossible in 13 days?
Not sure what are you guys trying to reach to, but there is a 0.0048% chance you get 25% or more variance in 288 blocks vs a 0.0245% chance of getting 8% or more variance in 2016 blocks, so the latter is more likely to happen based on my simple code which uses pyton erlang.cdf function.
|
|
|
Using a network cable, your router needs to have DHCP enabled and so is your miner (the default settings).
If you buy a used miner then chances are it has a static ip address that might be on a different subnet than yours and you won't find the miner.
|
|
|
Username: Mikeywith BTC Segwit Address: bc1qqegdapz86ug30wkwru6fmumy9w36qtq5pruqfy
|
|
|
Willi, for those who don't you, I would vouch for you, a trustworthy person who always paid out the rewards for all wining rounds.
Keep up the great work my friend.
|
|
|
I hear your points , both of you, both make sense and unfortunately probability is not math, you can't be too sure of what caused an event to happen when you have no control over it, it's likely a combination of both theories with different ratio, there has to be luck involved for that 8% figure to happen, I simply don't believe there was an addition of nearly 50EH in a single epoch, but I also know giving the halving is just around the corner -- many gear switching is probably taking place, gear prices are falling down rapidly especially the used once.
|
|
|
The current pace is 94.7%, it is extremely unlikely that we had the a 6.3% drop in hashrate given the price, so this makes me believe (even more) that the previous epoch was very lucky and that the 8.2% increase was more so 2-3% and the rest was luck.
|
|
|
I think these for-profit solo pool operators are incentivized to spread FUD about competitors. Fine, whatever — all the source is out there for you to verify.
hmm, the person in question wrote a truckload of code for the community including Cgminer, you probably use/used some of his work before, he is not spreading fud, and he has a valid reason to deny firmware/hardware that was not proven to solve blocks, as that would have a negative effect on the other PPLNS pool participants, obviously, he seem to be the only person doing so because almost every other pool I tried had no issue with anything that found shares that meet the pool difficulty. But ya, hopefully, soon somebody will post some screenshots of a block they found using one of these little toys, good luck Skot.
|
|
|
1 million bitaxe is over a 0.5 EH/s. If they’re solo mining (to a decentralized node, as they should be) then a Bitaxe will solve a block every 7 days, on average. We’ll get there, I have no doubts. Home mining unlocks _a lot_ of potential miners that would never touch a 3kW Antminer.
So it is within your vision that these miners would only be used for solo mining? Not that it affects their chances of hitting a block but is it how you imagine them to be treated? You can see in this very thread that my view on them is the same, they are too small for regular PPLNS or PPS, but good for the individuals who want to take a gamble on hitting a full block. My questions however, (which have been addressed here but you may have not read them) is the cost of these miners if done at large scale, or at least the consumer price. Also, have these miners found any blocks yet? Doing so on the testnet isn't quite all convincing to some people,and that includes one of the solo pools operators in this forum. Nonetheless, you doing a great work.
|
|
|
|