I use stratum+tcp://stratum.mining.eligius.st:3334 and it seems to work.
Get some states on the pool site so it must work
That's not elizium, that's Eligius - a completely different pool. Elizium is just one of countless p2pool nodes available. Eligius is a pool run by wizkid. If you're going to mine on p2pool, make sure you find a node that's close to you. Ideally you'd like to run your own node; however, that isn't always a possibility, so mining on a public node that is close to you is the next best thing. |
|
|
|
Hey thanks for the info.. So currently I'm showing 5202394.44 share diff on the pool. I should try something like /5203000 and just keep an eye on the current diff for adjustment? So address/40000. I need to go back and read up. How often would you adjust that number and do you base that off the current share diff on P2Pool? I need to try this. Pardon my dumb, but how are you setting this diff Fire000? example please?
One miner on my pool always seems to get about twice the payout of everyone else with a similar hash rate. Lucky as hell or something else.
via the manual override command example server -u JSnJaDXZMtNRvdSSrLQXhc9bJsthKF3zn2/40000 -p x do not worry about the address bit as that a non btc address the part after it the /40000 that is a diff setting you can apply a diff to you miner over the normal share value..... Now if you hit at the high diff you have set it will carry more weight that the lower default diff.... As can be seen over on the pool I have a miner sitting on atm the /# needs to be above the current diff on the node for the share.... So for example if the current diff is say 5500000 a share that setting needs to above that number so for example that /# would need to be set at /5500001 <<<< or higher the higher that number the more value the share will carry.... There's really no need. In a nutshell, here's the deal: Setting your share difficulty to anything LESS than the p2pool minimum is pointless. You can't submit a share to the chain that does not meet the minimum difficulty requirement. Setting your share difficulty to anything MORE than the p2pool minimum will mean you expect to find fewer shares, but when you do the share is weighted more (i.e. it's worth more). |
|
|
|
I have started a 440 GH/S 12 mth cloud contract with https://www.nimbusmining.com/ since july 2014 for the purpose of manufactured spending on my credit card. They allow you to switch to different pools, and I am currently pointing the hash power to Slush pool So far so good, Slush pool reported the actual hash power in their pool (actually at or around 440 GH/S most of the time) and I got my payout to my wallet. So I believe they are actually operating but even at the rate of their gold contract you will never achieve ROI unless you buy in extremely huge quantity with additional discount. So there actually is a cloud mining provider that allows you to use whatever pool you want. Their recommendation of using eclipse is just awful, though. They state, "a reasonable 5% fee". Who are they kidding? 5%? Thanks, but no. Also, the prices they are charging guarantee you'll never see profit. 5TH/s is $27,650. Yikes. That's just plain highway robbery and further proves my point that cloud mining exists to make the service provider the profit, not you. What were you thinking paying that kind of price (500GH/s for $2750)  One single Antminer S3 can get your 500GH/s and costs you about $400. Add in a PSU for another $100. Unless you're paying $0.75 per kWh there's no way you're spending $2250 a year in electricity costs to make up the difference this company is charging. |
|
|
|
I'll explain it for you. Every share you find gets added to the share chain. Each share is valued a certain amount of BTC. You mined for 6 hours and found 3 shares. Since then, p2pool found 4 blocks, so each time a block was found, you were paid for the shares you had on the chain.
How long do I continue to get paid with those shares? Fixed amount of time or nobody knows in advance? Each payout transaction takes 8640 shares and pays them. Basically it's about 3 days worth. |
|
|
|
I have 3+THs BTC mining power and tried out a P2POOL node yesterday for about 6 hours. For some reason all P2POOL sites I visited to not really explain well how the whole payout system works.
Anyway, after 6 hours I stopped mining and had 3 'shares' and it said I would get 0.009 BTC if a share was found now. Thats all, nothing else. Fast forward to this morning...I have a total of 4 deposits of 0.09 from mining that are taking forever to get confirmed. Why does it take so long in this case and why can't the P2POOL sites better let miners know how much is headed their way?
I'll explain it for you. Every share you find gets added to the share chain. Each share is valued a certain amount of BTC. You mined for 6 hours and found 3 shares. Since then, p2pool found 4 blocks, so each time a block was found, you were paid for the shares you had on the chain. The mined coins come from the generation transaction - so you have to wait 101 blocks for them to become available. That's the way it is for every pool that pays in generated (i.e. newly minted) coins. You picked a fantastic time to try p2pool since we've found 5 blocks in the past 24 hours. |
|
|
|
hopefully a few are watching that node I am on for this test as I am now earning twice as much as the guy on the same size rig by having the manual diff set to the block so the shares going in are blocks which with the manual diff set to the block value the p2 HAS to pay to the value of 16 coins in this case spread over the ppnls hence why I am killing this guy without the manual diff set and only running at the default share rate
You're killing him because you're getting block rewards for finding those blocks, whereas the other miner is not. It not only the block finder reward at play here as it treating me as it I am solo mining atm in terms of the reward based on a ppnls payout system over a number of rds <<<< so it paying the 16 coins over a few rds I edited my post... I'm keeping an eye on your experiment. It will be quite interesting to see how it plays out over time. Each share miner 1 is adding to the chain is also a block finder. Very interesting indeed... |
|
|
|
hopefully a few are watching that node I am on for this test as I am now earning twice as much as the guy on the same size rig by having the manual diff set to the block so the shares going in are blocks which with the manual diff set to the block value the p2 HAS to pay to the value of 16 coins in this case spread over the ppnls hence why I am killing this guy without the manual diff set and only running at the default share rate
You're killing him because you're getting block rewards for finding those blocks, whereas the other miner is not. EDIT: I am watching, and the experiment you're running is quite interesting, especially looking at the predicted payouts for each miner. Last I saw, miner 1 has a payout over 11, and miner 2 has a payout about 4.5. |
|
|
|
i keep going from one to the other, cant seem to find the best home
im running 2th/s 5 s3's, can someone give me some input of your pooling system you use and why
Have you considered other pools? I named a few in my previous posts, but left out the one on which I mine: p2pool. It works a bit differently than traditional pools like BTCGuild, Slush, GHash.io, etc. There is no central pool on which you must register. You can either run a node yourself, or find a node close to you and mine there. Your user name is a wallet address to which you want coins paid. As you find shares, each gets added to the share chain, and when somebody finds a block, you get brand new minted coins direct from the generation transaction based upon how many shares you've got on the chain. Like I wrote, it's different from your other pools. Primarily, share difficulty is pretty high, so variance plays a larger role. In a "regular" pool, you submit lots of shares and get lots of small payouts. There's a great comparison thread showing the payouts received from p2pool vs Eligius vs BTCGuild here: https://bitcointalk.org/index.php?topic=416933.0. Check it out. Also, check out the official p2pool thread here: https://bitcointalk.org/index.php?topic=18313.0. |
|
|
|
https://ozcoin.net is running campaign atm.. 3rd Anniversary of Ozcoin Bitcoin mining, to celebrate:
Blockfinders bonus reward 0.5BTC per block for the next 9 block solves
1 random share per round will be awarded 0.1BTC for the next 9 rounds always nice to receive rewards for finding blocks  QG That's a pretty nice little promotion. Congrats to the Ozcoin guys for 3 years running! Shameless p2pool plug here: block finders in p2pool are always rewarded with 1/200 of the BTC reward (currently, that's 0.125 BTC). |
|
|
|
think ya missed the point above will try this a different way.... Lets look at the current hash on the pool http://p2pool.info/and lets say the top 10-15 users were set all to the current BTC block as their diff which via the manual override would they not control the share diff on P2 as they would hitting most of the blocks and grabbing all the shares due to the diff setting on their miners of the btc block? ? And the higher the diff was set the higher the p2 diff would become ? OK. Provide me a proof and I'll take your concerns seriously. It a bit hard to gave proof without a farm lol..... But if that manual diff override is able to be set at the current block diff eg 19.7g and a user hit at that diff they in theory would be the only share for that block as the system would have to credit them all the shares to gave them the full pay out right ? So that would mean their hit all 3000 odd shares at once YES? ? Now if this was applied to all these 10 -15 miners which would be hitting a high number of the blocks they would send the diff flying due to rapid hitting of them shares As the higher you lift that manual diff above the min share value the higher your payout is per share as it worth more than the min share eg lets say the min diff share is atm 6mil and worth .010 to the miner<<<< a share that was set at 12mil via the manual diff would be worth twice more than a 6mil share to a miner so their share would be .020 as they have hit x 2 min shares so they basically put 2 shares in at once which in theory effects diff straight up as the p2 would have to adjust for them 2 shares at once rather than 1 Short answer is your theory is incorrect. Even if a miner sets their share difficulty to 19.7G other miners are still finding shares and adding them to the chain. When any miner finds a block... Either the miner who set his difficulty to 19.7G or one who hasn't, the block finder gets 0.125 BTC for that share. But what about the share value the user has set a 19.7 g share is worth more than a 6mil one in terms of payout.... If a user was to set at 19.7 g They would have to be credited all shares for the round to match the shares worth ?? eg the same as the example above re the 6mil to 12 mil share They wouldn't. The miner who sets his share difficulty to 19.7G will only have a single share on the chain - the one that found the block of BTC. That share is paid out at 1/200 of the block reward (1/200 of 25 BTC is 0.125 BTC). The remaining shares on the chain are given the other 199/200 of the reward. Here's the payout code that proves this: weights, total_weight, donation_weight = tracker.get_cumulative_weights(previous_share.share_data['previous_share_hash'] if previous_share is not None else None,
max(0, min(height, net.REAL_CHAIN_LENGTH) - 1),
65535*net.SPREAD*bitcoin_data.target_to_average_attempts(block_target),
)
assert total_weight == sum(weights.itervalues()) + donation_weight, (total_weight, sum(weights.itervalues()) + donation_weight)
amounts = dict((script, share_data['subsidy']*(199*weight)//(200*total_weight)) for script, weight in weights.iteritems()) # 99.5% goes according to weights prior to this share
this_script = bitcoin_data.pubkey_hash_to_script2(share_data['pubkey_hash'])
amounts[this_script] = amounts.get(this_script, 0) + share_data['subsidy']//200 # 0.5% goes to block finder
amounts[DONATION_SCRIPT] = amounts.get(DONATION_SCRIPT, 0) + share_data['subsidy'] - sum(amounts.itervalues()) # all that's left over is the donation weight and some extra satoshis due to rounding
if sum(amounts.itervalues()) != share_data['subsidy'] or any(x < 0 for x in amounts.itervalues()):
raise ValueError()
dests = sorted(amounts.iterkeys(), key=lambda script: (script == DONATION_SCRIPT, amounts[script], script))[-4000:] # block length limit, unlikely to ever be hit
So it the above is true THAT /# command it a waste of time even set above the current share value as it will not PAY higher than the current min share off this theory ?? going to test something on an alt coin to see what happens when the manual diff is set to the block brb Setting /# has value, but that value is of diminishing returns. Let's say we want to find a share every hour. To do so, we can easily figure out what to set our difficulty to with the following formula: Difficulty * 2**32 / hashrate = 3600
As you can see, as your hash rate goes up, your difficulty must correspondingly go up to maintain the 3600 second share time. You can also see that if I maintain a steady hash rate, but keep increasing my difficulty, the time to find a share is also increased. Let's see a couple of examples. Right now, p2pool's minimum share difficulty is 5738910.21. Let's assume I've got 10TH/s. Plugging those numbers in to the formula, I find it would take me 0.685 hours to find a share. Now, let's say I increase my share difficulty to 10,000,000. It would take me 1.193 hours to find a share. Increase that share difficulty to 10,000,000,000 and it will take me 1193.046 hours (49.71 days). |
|
|
|
think ya missed the point above will try this a different way.... Lets look at the current hash on the pool http://p2pool.info/and lets say the top 10-15 users were set all to the current BTC block as their diff which via the manual override would they not control the share diff on P2 as they would hitting most of the blocks and grabbing all the shares due to the diff setting on their miners of the btc block? ? And the higher the diff was set the higher the p2 diff would become ? OK. Provide me a proof and I'll take your concerns seriously. It a bit hard to gave proof without a farm lol..... But if that manual diff override is able to be set at the current block diff eg 19.7g and a user hit at that diff they in theory would be the only share for that block as the system would have to credit them all the shares to gave them the full pay out right ? So that would mean their hit all 3000 odd shares at once YES? ? Now if this was applied to all these 10 -15 miners which would be hitting a high number of the blocks they would send the diff flying due to rapid hitting of them shares As the higher you lift that manual diff above the min share value the higher your payout is per share as it worth more than the min share eg lets say the min diff share is atm 6mil and worth .010 to the miner<<<< a share that was set at 12mil via the manual diff would be worth twice more than a 6mil share to a miner so their share would be .020 as they have hit x 2 min shares so they basically put 2 shares in at once which in theory effects diff straight up as the p2 would have to adjust for them 2 shares at once rather than 1 Short answer is your theory is incorrect. Even if a miner sets their share difficulty to 19.7G other miners are still finding shares and adding them to the chain. When any miner finds a block... Either the miner who set his difficulty to 19.7G or one who hasn't, the block finder gets 0.125 BTC for that share. But what about the share value the user has set a 19.7 g share is worth more than a 6mil one in terms of payout.... If a user was to set at 19.7 g They would have to be credited all shares for the round to match the shares worth ?? eg the same as the example above re the 6mil to 12 mil share They wouldn't. The miner who sets his share difficulty to 19.7G will only have a single share on the chain - the one that found the block of BTC. That share is paid out at 1/200 of the block reward (1/200 of 25 BTC is 0.125 BTC). The remaining shares on the chain are given the other 199/200 of the reward. Here's the payout code that proves this: weights, total_weight, donation_weight = tracker.get_cumulative_weights(previous_share.share_data['previous_share_hash'] if previous_share is not None else None,
max(0, min(height, net.REAL_CHAIN_LENGTH) - 1),
65535*net.SPREAD*bitcoin_data.target_to_average_attempts(block_target),
)
assert total_weight == sum(weights.itervalues()) + donation_weight, (total_weight, sum(weights.itervalues()) + donation_weight)
amounts = dict((script, share_data['subsidy']*(199*weight)//(200*total_weight)) for script, weight in weights.iteritems()) # 99.5% goes according to weights prior to this share
this_script = bitcoin_data.pubkey_hash_to_script2(share_data['pubkey_hash'])
amounts[this_script] = amounts.get(this_script, 0) + share_data['subsidy']//200 # 0.5% goes to block finder
amounts[DONATION_SCRIPT] = amounts.get(DONATION_SCRIPT, 0) + share_data['subsidy'] - sum(amounts.itervalues()) # all that's left over is the donation weight and some extra satoshis due to rounding
if sum(amounts.itervalues()) != share_data['subsidy'] or any(x < 0 for x in amounts.itervalues()):
raise ValueError()
dests = sorted(amounts.iterkeys(), key=lambda script: (script == DONATION_SCRIPT, amounts[script], script))[-4000:] # block length limit, unlikely to ever be hit
|
|
|
|
think ya missed the point above will try this a different way.... Lets look at the current hash on the pool http://p2pool.info/and lets say the top 10-15 users were set all to the current BTC block as their diff which via the manual override would they not control the share diff on P2 as they would hitting most of the blocks and grabbing all the shares due to the diff setting on their miners of the btc block? ? And the higher the diff was set the higher the p2 diff would become ? OK. Provide me a proof and I'll take your concerns seriously. It a bit hard to gave proof without a farm lol..... But if that manual diff override is able to be set at the current block diff eg 19.7g and a user hit at that diff they in theory would be the only share for that block as the system would have to credit them all the shares to gave them the full pay out right ? So that would mean their hit all 3000 odd shares at once YES? ? Now if this was applied to all these 10 -15 miners which would be hitting a high number of the blocks they would send the diff flying due to rapid hitting of them shares As the higher you lift that manual diff above the min share value the higher your payout is per share as it worth more than the min share eg lets say the min diff share is atm 6mil and worth .010 to the miner<<<< a share that was set at 12mil via the manual diff would be worth twice more than a 6mil share to a miner so their share would be .020 as they have hit x 2 min shares so they basically put 2 shares in at once which in theory effects diff straight up as the p2 would have to adjust for them 2 shares at once rather than 1 Short answer is your theory is incorrect. Even if a miner sets their share difficulty to 19.7G other miners are still finding shares and adding them to the chain. When any miner finds a block... Either the miner who set his difficulty to 19.7G or one who hasn't, the block finder gets 0.125 BTC for that share. |
|
|
|
It's all good man...were all here to help and support each other  You want to know when if finally clicked? When I was evaluating that method. I coded my own version and just printed results. As expected, when I passed "0" to it, it gave me back the 2**256-1. However, when I passed "1" to it, it then gave me some very large number as well. When I saw that result, at first I didn't believe it, so I looked at it again, and like that proverbial lightbulb going on, I said to myself, "you freaking idiot, the larger the number the easier the share." |
|
|
|
I think that is when everyone goes to the bathroom during the movie.
I'm pretty sure it has nothing to do with Bitcoin.
Intermission emissions? |
|
|
|
I've done precisely that on my own node. Which is why I started this whole thing to begin with... I want somebody to show me where in the code this happens. Setting difficulty to /0: 2014-08-08 14:20:45.767005 New work for worker! Difficulty: 565.596240 Share difficulty: 5424434.245682 Total block value: 25.242381 BTC including 1461 transactions Setting difficulty to /10000000: 2014-08-08 14:22:44.088361 New work for worker! Difficulty: 506.191697 Share difficulty: 10000044.116454 Total block value: 25.008233 BTC including 73 transactions As you can see, it is obviously treating /0 the same as /1, /2, /256, /anything_under_p2pool_minimum. So... now that I've spent freaking hours looking at this and arguing that it behaves differently, it has finally dawned on me why. I'm thinking in terms of the RAW number value that is set. Yes, the number is indeed set to 2**256-1 if you set your difficulty as /0. However, that 2**256-1 means it's the EASIEST share, not the hardest. Hopefully this answers it once and for all for everyone (ok, well it clears it up for me anyway), and I'm sorry I spent pages of this thread figuring that out. |
|
|
|
so basically as said miles back in this whole topic lol 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 /0 behaves differently than /1. That's what the code says, and what I'm stating. By setting it to /0, the CODE translates that to 2**256-1. If you set it to /1, the code sets the difficulty to min(int((0xffff0000 * 2**(256-64) + 1)/difficulty - 1 + 0.5), 2**256-1). See the difference? 0 means 2**256-1. 1 means evaluate the minimum of int((0xffff0000 * 2**(256-64) + 1)/difficulty - 1 + 0.5) and 2**256-1. Look at both statements if you just isolate this part of the code and execute it. Let me explain it line by line: 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)
Line 1 - defines the difficulty_to_target function. It takes a single parameter - the difficulty Line 2 - makes sure the difficulty passed is 0 or larger Line 3 - if the difficulty equals 0, return a value of 2**256-1Line 4 - if the difficulty equals ANY OTHER NUMBER, return the value that is the minimum of the two numbers. Pay very close attention to the bolded part. Therefore, if you set your miner like this: ADDRESS/0 When that function is called, difficulty equals 0. Therefore, it returns 2**256-1. If you set your miner like this: ADDRESS/1 When that function is called, difficulty equals 1. Therefore, it returns the minimum of int((0xffff0000 * 2**(256-64) + 1)/difficulty - 1 + 0.5) and 2**256-1. Do you understand this? |
|
|
|
Lmao how hard is it to understand that /0 is a manual override code for diff.... It can only be set above the current diff to have any effect eg if the current diff is say 6 mil a share it need to be set above this to see any effect on diff..... If it is set under this value of 6 mil it defaults to the current share diff ........ Weather you set it at 5 mil 4 mil 3.5 mil or 0 as the value is less than the min current diff in this case of 6 mil it not rocket science and the proof is ya only got to test it and take note of the diff your miner is set at to see it in effect 1st hand DO I HAVE TO SCREEN SHOT IT to highlight it too you that the / number if less than the current share diff it will default to the current min share diff of the node as ya do not know where to find the diff reading on ya miner ?? Ps does not need to look at code etc to know you can not set a diff under the current share diff if you do it will default to current share diff hence the comment above You have yet to provide proof of your statements. I have shown you where the code explicitly sets the difficulty to 2**256-1 if you set the difficulty to /0. Show me where it doesn't. I understand quite well that /0 or /100 or /10000000 is a manual override for share difficulty. What I want YOU to show to me is proof of your statement If it is set under this value of 6 mil it defaults to the current share diff.
Show me that. Not by screenshots. By the CODE. Your next statement: Weather you set it at 5 mil 4 mil 3.5 mil or 0 as the value is less than the min current diff in this case of 6 mil it not rocket science and the proof is ya only got to test it and take note of the diff your miner is set at to see it in effect 1st hand DO I HAVE TO SCREEN SHOT IT to highlight it too you that the / number if less than the current share diff it will default to the current min share diff of the node as ya do not know where to find the diff reading on ya miner ?? That's just outright incorrect. Your miner does NOT show the value you set in /0 or /100 or /100000. Your miner shows the PSEUDO share value you defined using +0 or +100 or +1000. Your miner has absolutely no concept of anything set with using /#. I am not going to go digging through code when it common knowelge you can not put a share in that not above the share value and be credited for it as a paying share...... hence that statement above if your share is not over that current share diff you not going to be credited with it as a paying share are ya ?? So it defaults to the current share diff value not rocket science Ps next time ya quote something quote the full statement not part of it It can only be set above the current diff to have any effect eg if the current diff is say 6 mil a share it need to be set above this to see any effect on diff... If it is set under this value of 6 mil it defaults to the current share diff You are obviously failing to understand. Your miner has no knowledge whatsoever of you setting a share difficulty of /0 or /256 or /245982345. None. Whatsoever. Your miner shows you the PSUEDO share value you have set using +0 or +256 or +1000. What I am stating is the following: If you set your share difficulty to /0, that then gets translated by the p2pool code to set your desired share target to be 2**256-1. If you set your share difficulty to ANY other value, p2pool will evaluate that value and attempt to add it to the share chain. It will not be added if your desired share target is LESS than the required difficulty to actually get on the chain in the first place. If you set your share difficulty to something LARGER than the p2pool minimum, when you find a share at least your target difficulty it WILL be added to the share chain (assuming it's not orphaned or DOA), and its payout value WILL be weighted appropriately. This is also proven in the code. I want you, or anybody, to prove to me that setting /0 somehow gets translated into p2pool minimum difficulty. That's what I'm looking for. Proof. The ACTUAL CODE that does this. I have shown the ACTUAL CODE that supports my theory. You have given nothing but incoherent blathering about how you're right and everybody knows it. Let me put it another way. I WANT to be proven wrong. I WANT to be shown where I'm incorrect. Do that. Prove me wrong. |
|
|
|
Lmao how hard is it to understand that /0 is a manual override code for diff.... It can only be set above the current diff to have any effect eg if the current diff is say 6 mil a share it need to be set above this to see any effect on diff..... If it is set under this value of 6 mil it defaults to the current share diff ........ Weather you set it at 5 mil 4 mil 3.5 mil or 0 as the value is less than the min current diff in this case of 6 mil it not rocket science and the proof is ya only got to test it and take note of the diff your miner is set at to see it in effect 1st hand DO I HAVE TO SCREEN SHOT IT to highlight it too you that the / number if less than the current share diff it will default to the current min share diff of the node as ya do not know where to find the diff reading on ya miner ?? Ps does not need to look at code etc to know you can not set a diff under the current share diff if you do it will default to current share diff hence the comment above You have yet to provide proof of your statements. I have shown you where the code explicitly sets the difficulty to 2**256-1 if you set the difficulty to /0. Show me where it doesn't. I understand quite well that /0 or /100 or /10000000 is a manual override for share difficulty. What I want YOU to show to me is proof of your statement If it is set under this value of 6 mil it defaults to the current share diff.
Show me that. Not by screenshots. By the CODE. Your next statement: Weather you set it at 5 mil 4 mil 3.5 mil or 0 as the value is less than the min current diff in this case of 6 mil it not rocket science and the proof is ya only got to test it and take note of the diff your miner is set at to see it in effect 1st hand DO I HAVE TO SCREEN SHOT IT to highlight it too you that the / number if less than the current share diff it will default to the current min share diff of the node as ya do not know where to find the diff reading on ya miner ?? That's just outright incorrect. Your miner does NOT show the value you set in /0 or /100 or /100000. Your miner shows the PSEUDO share value you defined using +0 or +100 or +1000. Your miner has absolutely no concept of anything set with using /#. |
|
|
|
Yes kinda. But I want to own the ghz and not rent it
So you want to trade in your miners for credit on cloud mining? Depending on how many you have, I might take you up on that offer. I would want to point my rigs at any pool I want though... What you are describing is co-locating hardware that you own, not purchasing cloud mining. A number of vendors provide this type of service. For example, GAWMiners partners with ZenMiners to provide collocation of purchased hardware (both scrypt and SHA-256). There's also the traditional method of finding a data center and having them host for you. An example of this is Advania in Iceland. They host your hardware at 90 Euros per month per kilowatt. An SP30 hosted there would cost about 270 Euros a month. |
|
|
|
Unless you are running 1th rigs forgot p2pool as you will earn no where the amount you would on a normal pool... I don't necessarily agree with this statement, although I don't have empirical data to back it up. Hashrate is hashrate, it should even out in the end. Even if you don't get a share today in this block, your share will count for the next block and you would get a payout then. This is regularly stated here, however it only holds true *if* bitcoin difficulty remains the same. Which it doesn't, so therefore it's false. If your luck averages out over the difficulty period, then yes, it will. However, the lower your hashrate, the less likely it is to average out over a fixed period of time (a given difficulty period). The higher the difficulty, the worse it gets. M While your statement about rising difficulty is true, the application of it here is not addressing the statement made by fire000. His statement implied a difference between using a dragon miner at 1TH/s vs using a combination of other miners to also achieve that 1TH/s. In this sense, hash rate is hash rate. If you have 500 Antminer U2s all hashing at 2GH/s each, or 5 over clocked S1s hashing at 200GH/s each, or 1 dragon hashing at 1TH/s, you still have 1TH/s mining. Your statement is entirely accurate about it not evening out in the end, precisely because of increased difficulty. |
|
|
|
|
Show Posts
