also further to this current talk in here lol the /0 command sets to the bear min of the share diff on the miner as per the node diff so if the diff is 5mil for example it set the diff to 5mil if it 7mil it sets to 7mil....
But on saying this that /0 command can be used to set a diff higher than the min diff only for example if the diff was 5mil you can set ya rig to a diff via the / number command to say 7.5 mil eg /7500000 if this set under the current share diff on the nodes it defaults to the min diff on the node eg if you set it for 2.5 mil for example and the current diff was 5mil for a share it would default to the min diff of 5mil as that 2.5mil setting is below the current diff of 5mil
Show me the proof in the code that it does so. I have linked multiple places in the code that completely contradict this statement. All I've gotten back so far is, "based on my personal experience" and other anecdotal evidence. As is the saying, "Show me the money!" Someone show me where setting the address to /0 sets share difficulty to p2pool minimum share difficulty by quoting the actual CODE from p2pool (and not some modified version of the code like the vardiff patch or some scrypt coin) from forrestv github. As I wrote a number of times a few pages back, manually setting the share difficulty only makes sense if you're mining on a node where there is a very large discrepancy between your hash rate and the total hash rate of the node. For example, if you were to bring a 180GH/s miner to a node with 10TH/s, set that S1s difficulty manually. The same holds true going the other way. If you're bringing 10TH/s to a node with 1TH/s, set your share difficulty HIGHER than the default p2pool share value. I even provided a way for you to calculate what you should set it to to get an average of 1 share an hour. Regarding your comments on the minimum requirements to join p2pool, you've hit it pretty much dead on accurate. If you want to ensure you've got a good chance of having a share on the chain for every block found, that means you're going to need enough hardware to find a share every 12 hours or so. Currently the share difficulty is 6.5M. So, to find 2 shares a day, you'd need just about 650GH/s. Your statement about the hardware to bring to the party is incorrect, though. It's not like a dragon or an S2 is somehow better at finding shares than an S1 is. Hash rate is hash rate, no matter how you get there. Dude that easy to see 1st hand lol that /0 is a manual diff setting override try this and watch what happens on ya miner diff.... 1st set to 7500000 watch ya miner diff rise above the node diff and set at 7.5mil.... Then set any number under the current node diff eg 4mil it will default to the min node diff as it will NOT allow you to set a diff under the current min diff of the node share rate so basically a 0 setting or a 4mil or 5 mil setting is going to gave a min diff or the node at 6.5 ..... Show me the code. Don't tell me, "dude that easy to see 1st hand lol...". Here's my proof. First, the reading of manually set difficulty: desired_pseudoshare_target = None
desired_share_target = None
for symbol, parameter in zip(contents2[::2], contents2[1::2]):
if symbol == '+':
try:
desired_pseudoshare_target = bitcoin_data.difficulty_to_target(float(parameter))
except:
if p2pool.DEBUG:
log.err()
elif symbol == '/':
try:
desired_share_target = bitcoin_data.difficulty_to_target(float(parameter))
except:
if p2pool.DEBUG:
log.err()
if random.uniform(0, 100) < self.worker_fee:
pubkey_hash = self.my_pubkey_hash
else:
try:
pubkey_hash = bitcoin_data.address_to_pubkey_hash(user, self.node.net.PARENT)
except: # XXX blah
pubkey_hash = self.my_pubkey_hash
return user, pubkey_hash, desired_share_target, desired_pseudoshare_target
Now, here's the difficulty_to_target definition: def difficulty_to_target(difficulty):
assert difficulty >= 0
if difficulty == 0: return 2**256-1
return min(int((0xffff0000 * 2**(256-64) + 1)/difficulty - 1 + 0.5), 2**256-1)
This CLEARLY sets the difficulty to 2**256-1 if you set /0. Using python and printing what 2**256-1 resolves to: Python 2.7.8 (default, Jul 3 2014, 06:13:58)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x=2**256-1
>>> print x
115792089237316195423570985008687907853269984665640564039457584007913129639935
>>> exit()
Now, here's where the comparison between YOUR set value and the value p2pool determines happens: if desired_share_target is None:
desired_share_target = 2**256-1
local_hash_rate = self._estimate_local_hash_rate()
if local_hash_rate is not None:
desired_share_target = min(desired_share_target,
bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.0167)) # limit to 1.67% of pool shares by modulating share difficulty
local_addr_rates = self.get_local_addr_rates()
lookbehind = 3600//self.node.net.SHARE_PERIOD
block_subsidy = self.node.bitcoind_work.value['subsidy']
if previous_share is not None and self.node.tracker.get_height(previous_share.hash) > lookbehind:
expected_payout_per_block = local_addr_rates.get(pubkey_hash, 0)/p2pool_data.get_pool_attempts_per_second(self.node.tracker, self.node.best_share_var.value, lookbehind) \
* block_subsidy*(1-self.donation_percentage/100) # XXX doesn't use global stale rate to compute pool hash
if expected_payout_per_block < self.node.net.PARENT.DUST_THRESHOLD:
desired_share_target = min(desired_share_target,
bitcoin_data.average_attempts_to_target((bitcoin_data.target_to_average_attempts(self.node.bitcoind_work.value['bits'].target)*self.node.net.SPREAD)*self.node.net.PARENT.DUST_THRESHOLD/block_subsidy)
)
This block is NEVER reached. Why? Because the value of "desired_share_target" at this point is not None. It is 2**256-1. Therefore, your desired target difficulty remains at 2**256-1 when you set it to "0" manually by using /0. Now that I've shown my proof why you're wrong, show me why you're right. |
|
|
|
|
I like to have control over my mining experience. I own and maintain the hardware. I operate a p2pool node. I like the idea behind p2pool as a vast network of individual nodes that ultimately make up a single entity trying to solve blocks. I get to determine if I want to donate to the author. I get to determine if I want to charge people fees for mining on my node. I get newly-minted coins when blocks are found.
With all of its benefits, p2pool has a pretty significant flaw, that is becoming more and more apparent. The flaw is that the bigger the pool gets, the more variance the individual miner experiences. This is completely the opposite of how things work in other pools. Why? Because of the share chain that is the core of p2pool. Just like the Bitcoin block chain, the share chain has a mechanism to keep the average share time to a given value. Bitcoin is 10 minutes. The share chain is 30 seconds. And just like Bitcoin, as you increase hash rate, you increase the difficulty to keep that value. Consequently, as that difficulty increases, your hardware has less and less of a chance of getting a share onto the chain, so you have less and less of a chance to get any payout when a block is solved.
So, what would make me switch? Provide me with the same level of control as I get with p2pool, keep the decentralized nature of the pool, but solve the variance problem.
|
|
|
|
also further to this current talk in here lol the /0 command sets to the bear min of the share diff on the miner as per the node diff so if the diff is 5mil for example it set the diff to 5mil if it 7mil it sets to 7mil....
But on saying this that /0 command can be used to set a diff higher than the min diff only for example if the diff was 5mil you can set ya rig to a diff via the / number command to say 7.5 mil eg /7500000 if this set under the current share diff on the nodes it defaults to the min diff on the node eg if you set it for 2.5 mil for example and the current diff was 5mil for a share it would default to the min diff of 5mil as that 2.5mil setting is below the current diff of 5mil
Show me the proof in the code that it does so. I have linked multiple places in the code that completely contradict this statement. All I've gotten back so far is, "based on my personal experience" and other anecdotal evidence. As is the saying, "Show me the money!" Someone show me where setting the address to /0 sets share difficulty to p2pool minimum share difficulty by quoting the actual CODE from p2pool (and not some modified version of the code like the vardiff patch or some scrypt coin) from forrestv github. As I wrote a number of times a few pages back, manually setting the share difficulty only makes sense if you're mining on a node where there is a very large discrepancy between your hash rate and the total hash rate of the node. For example, if you were to bring a 180GH/s miner to a node with 10TH/s, set that S1s difficulty manually. The same holds true going the other way. If you're bringing 10TH/s to a node with 1TH/s, set your share difficulty HIGHER than the default p2pool share value. I even provided a way for you to calculate what you should set it to to get an average of 1 share an hour. Regarding your comments on the minimum requirements to join p2pool, you've hit it pretty much dead on accurate. If you want to ensure you've got a good chance of having a share on the chain for every block found, that means you're going to need enough hardware to find a share every 12 hours or so. Currently the share difficulty is 6.5M. So, to find 2 shares a day, you'd need just about 650GH/s. Your statement about the hardware to bring to the party is incorrect, though. It's not like a dragon or an S2 is somehow better at finding shares than an S1 is. Hash rate is hash rate, no matter how you get there. |
|
|
|
Because there are variables, there is a formula. As always with these things. The formula for BTC per GH/s is
difficulty * 2^32 / hashrate
In order to get the money out of this you just convert the BTC to whatever currency it is
(difficulty * 2^32 / hashrate) / (BTC / currency )
Not quite... difficulty * 2^32 / hashrate will give you how many seconds you would expect it to take to find a block. The if you took 25 and divided by that number, you'd get how much BTC you'd expect to earn a second. So, to calculate expected earnings per GH/s, this is the correct formula: 25 / (18736441558 * 2^32 / 1000000000) = 0.00000000031067
Therefore, at current difficulty, 1GH/s = 0.00000000031067 BTC/s. This, however, is not what the OP asked. The original question was how to figure out a system's dollar per GH/s, which is simply the cost of the system divided by the hash rate of that system in GH/s. So, if you paid $1000 for a 1TH/s miner, it's $1 per GH/s. If you want to figure out operating costs, that's easy, too. Just take the rated power consumption of the miner, translate into kw and multiply by the cost of your electricity per kWh like this: So, at 10 cents per kWh, a 340 watt miner will cost $0.034 an hour to run, or $0.816 a day. Now to figure out your expected earnings after you've factored in power, you simply take the first number 0.00000000031067 and multiply by 86400 (seconds in a day) to get 0.000026841888 (which is how much BTC 1GH/s expects to earn in a day). Now, convert that to your fiat (I'll use a conversion ratio of 1 BTC -> $590 USD) which is $0.01583671392 per day. So, now that you know how much each GH/s will earn you in a day in USD, multiply the value by the GH/s of the miner and subtract out the daily power costs. Of course, you could just use the formula I posted and give the appropriate hash rate there (instead of just calculating earnings for 1GH/s) like this (I'm using the Antminer S3 as an example): 25 / (18736441558 * 2^32 / 440000000000 / 86400) = 0.011810256
0.011810256 * 590 = 6.96805104
6.96805104 - (0.34 * 24 * .10) = 6.15205104
Therefore, right now an Antminer S3 expects to make you $6.15 a day assuming $590 per BTC and $0.10 per kWh power costs. |
|
|
|
Also, have u tried to get stock 440 on those S3's ?
my batch 4 s-3's run well at freq 218 = 440gh freq 225 = 460gh freq 237 = 478gh my batch 1 s-3's only do well at 212 How do you have yours powered ? Like one PSU two two units etc. I use evga 1300 psu's they are running 2 s-3's each. I plan to see if they will run 3 each as i will order 2 more s-3's in a day or 2. The EVGA 1300 G2 runs 3 S3s no problem at all. |
|
|
|
Now that's a pallet of fun  |
|
|
|
I think Ant S2 1MHs about 1500$ can help you.
I'm also student and I'm raising money to buy it.
Good luck
Save for something else. $1500 is too much to pay for 1TH/s, especially since you can get 3 Antminer S3s for 1.98 BTC (less than $1200) and an EVGA 1300 G2 PSU for $175 that will power all 3 of those S3s. 3 S3s will get you 1.32TH/s and only use 1020W. |
|
|
|
It means "multiply by two to the 32nd power" which means "multiply by 4,294,967,296. Sorry about the shorthand How do I enter that into an excel formula. Can you copy and paste the formula from excel on your PC? When I am entering it excel is changing it and breaking it. Thanks. [/quote] =power(2,32) In cell A1 you put 25 In cell A2 you put 18736441558 In cell A3 you put =power(2,32) In cell A4 you put 29650000000000 In cell A5 you put 86400 In cell A6 you put: =A1 / (A2 * A3 / A4 / A5) |
|
|
|
slush, hopes i got it right but im sure you knew what i meant.
thanks
Well if I knew I wouldn't have asked . I don't have enough experience on slush's pool to compare. I know the payout schemes are different... Sorry I can't help you more. Bitsaurus brings up a good point. BTCGuild has publicly stated they would close up shop if certain regulations come into play. |
|
|
|
248 is 281474976710656, and not 248.
I edited. It still looks wrong :/ The stats i'm working with are as follows. Could someone help me incorporate these stats into a working formula that results in an BTC per day estimation. Current Difficulty : 18736441558 Current Network Hash Rate TH/s : 138086.19 Coin Reward Per Block : 25 Block Frequency mins : 10 BitCoin Value £ : 344.52 Your Current Speed GH/s : 29650 Your % total of Network Hash Rate : 0.000214721 (calculated by spreadsheet from tats in putted above) Total BTC Released Per Day : 3600 (calculated by spreadsheet from tats in putted above) I'm anticipate a result between 0.77299547 / 0.79585047BTC Per day Thanks guys. 25 / (18736441558 * 2**32 / 29650000000000 / 86400) = 0.79585047[btc] per day
Your percentage of the total hash rate, total BTC released per day and value in Pounds is not necessary to figure out your expected earnings. Just change the difficulty and/or hash rate (which is hashes per second - not GH/s, TH/s or anything else... HASHES per second) as necessary. When I use this exact formula Excel changes it as follows =25/(18736441558*2E+32/29650000000000/86400) It gives the result 1.70908E-23 What does "* 2**32" mean in this formula? I think this may be where its going wrong :/ It means "multiply by two to the 32nd power" which means "multiply by 4,294,967,296. Sorry about the shorthand |
|
|
|
248 is 281474976710656, and not 248.
I edited. It still looks wrong :/ The stats i'm working with are as follows. Could someone help me incorporate these stats into a working formula that results in an BTC per day estimation. Current Difficulty : 18736441558 Current Network Hash Rate TH/s : 138086.19 Coin Reward Per Block : 25 Block Frequency mins : 10 BitCoin Value £ : 344.52 Your Current Speed GH/s : 29650 Your % total of Network Hash Rate : 0.000214721 (calculated by spreadsheet from tats in putted above) Total BTC Released Per Day : 3600 (calculated by spreadsheet from tats in putted above) I'm anticipate a result between 0.77299547 / 0.79585047BTC Per day Thanks guys. 25 / (18736441558 * 2**32 / 29650000000000 / 86400) = 0.79585047[btc] per day
Your percentage of the total hash rate, total BTC released per day and value in Pounds is not necessary to figure out your expected earnings. Just change the difficulty and/or hash rate (which is hashes per second - not GH/s, TH/s or anything else... HASHES per second) as necessary. |
|
|
|
LOL... I've got to assume OP means GHash vs BTCGuild. Given those two options only, I pick BTCGuild any day of the week. Why? Eluthria has been very active on the boards, he's up front about the way his pool works and he's taken actual steps to ensure his pool doesn't get to 51% of the network's hashing power. The other guys have done pretty much the opposite. They have admittedly done a 51% attack in the past. They have approached and surpassed 51% again since then, and their only action is to send out random tweets/posts asking miners to please move their hardware someplace else.
meant slash, ok im sticking to btcguild thanks What is "slash" pool then? The big pools are GHash.io, BTCGuild, Discus Fish, Eligius, Slush. First you asked about shash and now slash... |
|
|
|
and once again op has touched the weakness of BTC. So here goes.
Software does exist that will not report a block. Not a rumor not fake it is as real as mining itself.
It was created by accident and truly hurt BTC Guild before it was discovered. Most likley cost me around .2-.3btc personally as I was underpaid due to the accidental with holding. Along with many other btcguild miners.
The pools have not resolved this issue no solve has been found. The only solve is solo mine since the only person hurt by with holding is the one that found the block.
Here is the simple math a big pool with deep pockets that has that software can attack a small pool and hurt its luck.
Most likely this will kill bit coin in the long run.
So to the op this could be simple bad luck/variance or this could be a deep pockets pool attacking a weaker small pool.
Your only prevention is to solo mine or don't mine. Or do what I do put mining power in five pools.
While block withholding attacks are indeed real, they don't account for the swings in reported hash rate. If as you say large pools have it in for the little guys, then you wouldn't see the sizable swings in hash rate of 40PH/s either way. Yes, there would be some impact, but that impact would be a negative swing in the rate since the larger pool would have dedicated a portion of its own hash rate to perform the attack. This falls under the category of conspiracy theory. Did it happen in the past? It did indeed, on both BTCGuild and Eligius (at least those are the only pools to have documented it having occurred). It was one particular miner using an incorrectly written custom version of mining software that did not submit shares that would solve blocks. Stating that a block withholding attack will be the demise of bitcoin is, while possible, not a very likely scenario in even the most conspiratorial camp. Remember, the attack has to come from the MINER not the pool in general. It's not like GHash.io could suddenly take their entire 50PH/s (or whatever they have mining there now) and decide to perform the attack on Slush, for example. They could potentially take their OWN hardware and alter it in such a way. However, this brings up the next question: why would they? Performing such an attack undercuts their own bottom line at the same time it tries to undermine the luck of another pool. It's just plain stupidity to purposefully execute this kind of attack. All you gain by it is the *hope* that people mining on the other pool will jump ship. That's it. Your last sentence is great advice: spread out your hashes. Put some on multiple pools. It should help decrease the variance for you as a miner. |
|
|
|
Thanks Guys,
I am working out bills for us and the best way to optimise our power usage.
It is actually to aid my father and make a bullet proof calculator that given the correct variables can provide accurate data on power usage, electricity cost, BTC earned per day, value of BTC earned in £ and so on all in one form.
It’s optimised for the information he cares most about.
Once I have the formula updated, Ill post a copy on here so you can see where I’m at and provide any input / advice on modifications I should make to increase accuracy.
Thanks again.
Be sure to explain to your father that there is no "bullet proof" calculator because there are too many changing variables. Even the formula I posted provides nothing more than "expected" earnings per day in an ideal world under perfect circumstances. It does not take into account pool luck, transaction fees associated to blocks, etc. Everything is luck, and as such the best we can provide are probabilistic calculations. The calculations become less and less accurate over time because they take more and more guesses. For example, nobody can tell you what the next difficultly will be. You can guess that it will increase 5% or 10% or 20%. Do you keep that same increase for every jump from now until the last block is mined? Do you put in variable jumps? Whatever you do, you're just making a guess What about BTC->fiat? That changes every second. Electricity rates are variable. Power usage depends on the efficiency of the power supply, the power delivery, the miners themselves. All variables. TLDR: it's guess work. Make sure dad gets that. |
|
|
|
|
2 x Antminer S1 - purchased in April, sold last week
1 x SP10 - purchased in May, sold Monday
5 x Antminer U2 - purchased in March, still trying to win the lottery (running in a powered USB hub with an rPi controller)
8 x Antminer S3 - purchased 2 in batch 1, 3 in batch 4 and 3 in batch 5.
The S3s are finicky and nowhere near as reliable as my S1s or my SP10. Those were set it and forget it. These require you to babysit them until you find the hash rate that makes them the happiest, and each unit is different. Once you find that happy place, they're good to go.
S3_1 - 475GH/s (237.5 clock)
S3_2 - 473GH/s (237.5 clock)
S3_3 - 453GH/s (225 clock)
S3_4 - 441GH/s (218.75 clock)
S3_5 - 429GH/s (212.5 clock)
S3_6 - 454GH/s (225 clock)
S3_7 - 469GH/s (237.5 clock)
S3_8 - 452GH/s (225 clock)
I'm running those S3s on 2 EVGA 1300 G2 PSUs (3 S3s per PSU) and 1 Corsair HX1050 (2 S3s per PSU). I run them in my home.
|
|
|
|
As described, antminers will be the better deal.
Most S3 do 475GH easily, and many 500Gh. (and every unit does at least 450GH)
The A1 miner should also be much louder (if that is of concern to you).
Dont forget to buy a suitable power supply for the ordered antminers though.
Just a small correction... most S3s do 440, some are lucky and will do 450, 475 or 500. Others are not so lucky and will get anywhere between 400 and 430. Unfortunately, the hash rate on the S3 is a bit more hit and miss than Bitmain's previous products. Hasn't stopped me from purchasing them, though... they're a nice little unit. |
|
|
|
The formula is very simple: BTC earned per day = Block Reward / (Difficulty * 2**32 / hash rate / seconds in a day)
So, if in Excel, just put each value in a cell: 25 is block reward 18,736,441,558 is difficulty 2**32 is constant your hash rate (or whatever hash rate you want) 86400 % increase in difficulty days between increases total days to consider As has been pointed out, you can fetch the difficulty from calls to blockchain.info, or you can just change it manually for when you want to do the calculation. Then, you'd just run the formula over and over again having it change the difficulty and recalculating earnings per day for the time period you specified. There are any number of calculators online that already provide this level of information. For example, bitcoinwisdom.com has a mining calculator to show ROI with any number of editable inputs, including conversion from BTC->USD, pool fees, power costs, etc. Not sure why you're looking to reinvent the wheel, but given the formula above and the values for the cells, you certainly can. |
|
|
|
|
LOL... I've got to assume OP means GHash vs BTCGuild. Given those two options only, I pick BTCGuild any day of the week. Why? Eluthria has been very active on the boards, he's up front about the way his pool works and he's taken actual steps to ensure his pool doesn't get to 51% of the network's hashing power. The other guys have done pretty much the opposite. They have admittedly done a 51% attack in the past. They have approached and surpassed 51% again since then, and their only action is to send out random tweets/posts asking miners to please move their hardware someplace else.
|
|
|
|
Obviously there is new equipment added and old equipment removed, which has an effect on the total network hashing rate, but the swings of 40PH/s aren't caused by this. Nobody, contrary to what the conspiracy theorists would have you believe, decides to turn on a bunch of hardware to then just turn it back off. There is a very key statement that needs to be understood: the bitcoin protocol has no idea whatsoever the hash rate of the network. It calculates an approximate hash rate based upon target difficulty and solved block time. The formula is: Difficulty * 2**32 / hashes per second = time in seconds to solve a block
Since we know the difficulty and the time, we can solve for the hashes per second. As you can see, as time goes up and down, hash rate must also go up and down since the difficulty remains constant, at least until the adjustment at the 2016th block when the difficulty adjusts itself to make time equal to 600 seconds. I'm quoting myself here because apparently people who continue to claim crazy theories don't read the few posts above theirs. The answer is not the boogeyman, mysterious manufacturers powering up new hardware then turning it off again, aliens or anything other than VARIANCE. Read my answer quoted above. Then read it again if you are still asking yourself why the hash rate swings like it does. |
|
|
|
/#+# should only be needed if your running on a node that has other miners on it that are not yours. Otherwise it may be best to let it autoadjust...i.e. don't use it.
As this is what I have read.... so I tried to test things out because as everyone has noticed its getting much more difficult to find the shares. BUT I am on my own and no one else is hashing on my node but me. I think from what I have seen in the past 3 months hashing only p2pool that its best for me to leave it alone and let it auto adjust. I am running s-1's. OK at least a few blocks to make it worth our time!!!! OK 1 last thing, If you were to jump around a bit (node to node) and or reset your own pool (it will reset all the shares and stuff back to 0 and start fresh for you) BUT if you go here and find your addresss it will keep all your stats for you http://p2pool.info/Your local p2pool node does not persist your found/orphaned/dead shares across node restarts. However, all of your active shares do indeed remain on the share chain - which is precisely why you can move from node to node without consequence. p2pool.info seems to have some incorrect information, especially number of miners. At this point I'm far more trusting of windpath's numbers on http://minefast.coincadence.com since he's been very active in the development of the front end and has spent time on this forum explaining how he makes his calculations and soliciting feedback from us on how to make things better or more accurate. I'm really looking forward to hearing back from somebody regarding setting share difficulty to /0. Everything I've seen in the code states that if you set it to 0, p2pool then sets it to 2**256-1. There's nothing else there indicating that setting it to /0 will then set your difficulty to the p2pool minimum value. I'm going to see if setting the pool to run in debug mode will offer any more insight to the effect of /0, and maybe lead me to a place in the code that I've missed thus far. |
|
|
|
|
Show Posts
