Ever have one of those days where your miners just refuse to find shares? Yup, that's my day today. 22 hours and 1 share. 400GH/s and 1 lonely, single share. I feel like I should go give the S1s a little pep talk...  |
|
|
|
|
Agreed. It's just that you need to satisfy the target difficulty, doesn't mean you need to exactly equal it. For example, I found a block a couple weeks ago and my miner showed a 63B difficulty - well above the target 6.9B that it was when I found it.
|
|
|
|
Yes, the simplest difficulty is to find a hash with a single leading zero. That is incorrect. Difficulty 1 represents that it will require on average 1 full nonce range, which is 2^32 attempted hashes to solve a block, not 1 attempted hash (or 16 which is what a single zero would represent). The initial target at difficulty 1 (2^256 / 2^32) is computed as 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF to store this however would require 256 bits. Bitcoin uses a truncated target to save space in the blockchain which means the actual target for difficulty 1 is 0x00000000FFFF0000000000000000000000000000000000000000000000000000 Note the leading eight zeroes. There are no block hashes in the blockchain which have less than eight zeroes. As an example here is block #1 https://blockchain.info/block/00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048Yes Satoshi made some things a little more complex than they need to be. There is no requirement that difficulty 1 equal 2^32 attempts. Difficulty is just for us humans anyways the network works off the raw target and difficulty is computed from that. So Satoshi could have made Difficulty x = x attempted hash (on average) per block. If that were the case the original difficulty would have been 4.2 billion and today it would be 34,363,484,163,461,100,000. Yes that is 34,363 quadrillion. It means that on average to solve a block means computing 34,363 quadrillion hashes. We probably would just shorthand difficulty to "quads". "Damn difficulty is now more than 30,000 quads, it is getting insane". Thanks for your response and I stand corrected. Now I've learned something, too  . I suppose I could have just looked at the very first block in the chain to see how many leading zeroes there were. |
|
|
|
To calculate a big number and somehow have it start with 16 zeroes? Yes, I'd say that is pretty difficult.
Was it one zero back when Bitcoin started and the difficulty was at 1? Or one of some other number?
Yes, the simplest difficulty is to find a hash with a single leading zero. Difficulty is adjusted every 2016 blocks to keep the average generation time about 10 minutes per block. Therefore, as more hashing power gets added to the network, the greater the difficulty must become. To answer the original question, current difficulty means you need to find 16 leading zeroes to satisfy the requirements. Anybody can find it, from the poor guy who has a miner doing only a single hash per second to the giant farm hashing at quadrillions of hashes per second. |
|
|
|
I've got a couple S1s hashing away and have been looking to up my game to the TH/s club as well. I can get the S2, but I've also been looking at the SP-10. Of course, I could pick up 2 S2 for the price of the SP-10... but it's a question of power at that point. I'm setup at home, so I have limits on how much power I can draw . Of course, if I could find a nice cheap data center willing to rent me cabinet space... oh wait... I've gone off topic. |
|
|
|
I thought you had a choice of whether or not to pay a transaction fee, just like a miner has a choice whether or not to pick up your transaction? The transaction fee is there to incentivize miners to pick them up and work on them. From the wiki: Transaction fees are voluntary on the part of the person making the bitcoin transaction, as the person attempting to make a transaction can include any fee or none at all in the transaction. On the other hand, nobody mining new bitcoins necessarily needs to accept the transactions and include them in the new block being created. The transaction fee is therefore an incentive on the part of the bitcoin user to make sure that a particular transaction will get included into the next block which is generated. |
|
|
|
Solo mining can be fun, and is very much like playing the lottery. I have 5 U2s that solo mine. Is it likely they'll ever solve a block? Nope. I thought it was unlikely my S1 would solve a block, but last week it did just that... boy do I wish I was solo mining then. It's unlikely I'll ever win the PowerBall either, yet I'll still buy a ticket or two. Winning that buys me a whole lot of hashing power |
|
|
|
I completely forgot about using gyft.com to purchase an Amazon gift card with BTC. Great advice! Gigabit, a pair of TX750 will have way more power than necessary to drive the Antminers. You could *almost* drive both of them off a single PSU. If you are insistent upon each miner having a dedicated PSU, you wouldn't need more than a 500W unit. The Corsair RM550 would work out quite well. Available on Amazon, too |
|
|
|
I have been looking into this but it seems like you need to modify it in order to not connect you to the p2pool network.. https://github.com/Rav3nPL/p2pool-rav/blob/master/README.mdI seen one mod of the python script out there but I have not got a chance to fully play with it… I did set this up and it works we on OSX even thought it shows no support for OSX.. I also did a direct connect to bitcoind however the reject rate is SO high I just can't make that recommendation .. If you find anything, please keep this thread updated.. P2pool has nothing to do with solo mining. You don't need to modify any python script from rav3ns code to get it to run on OSX either. If you want to solo mine and your bitcoind can't feed your miners quickly enough put a stratum proxy in between and point your miners to it. |
|
|
|
|
That's an interesting setup... use my proxy... if that blows up, use the pool itself... and if that's gone, try a completely different pool. Any advantages to using the local stratum proxy?
|
|
|
|
I thought the S1s were strictly failover. I figure you could probably edit /etc/init.d/cgminer to add the --failover-only to your secondary and tertiary pools, but OOTB, it's not there.
Yes, they are, but apparently the DDOS attacks were causing some miners to disconnect, which would make them failover to the backup pool. That's my point... since the S1 is failover, if it was disconnected from Eligius due to DDOS attack, it wouldn't go back to Eligius without a reboot (or changing the pool configurations). They wouldn't "leak" shares, they'd simply stop mining on Eligius altogether. |
|
|
|
in the last ~6hrs my mining speed at eligius for some units has been a little sporadic. even having 3 stable antminer S1s ont he same power supply, only one of them shows 60-80GH for a data point and then bounces back. seems like when these data points happen about 1/3-1/2 of my machines will show slightly low hashrate at the pool then jump up again to normal.
is this a pool issue? (high difficulty to the miner, stats page issues, etc)? Its not enough to severely impact my 3hr hashrate, but my 22.5min hashrate shows about 20% lower whenever it occurs. Its not the first time, these little chunks of instability or low hashing on select units seems to occur during small 1-4hr periods of time and then absolutely problem-free for hours or days after
Check if those miners are 'leaking' shares to your backup pool. I've also noticed some strange stats in the last 2 days and found that my miners (S1 & S2) had switched pools for a while and moved back again... happened again about 40mins ago. I thought the S1s were strictly failover. I figure you could probably edit /etc/init.d/cgminer to add the --failover-only to your secondary and tertiary pools, but OOTB, it's not there. |
|
|
|
I am seeing huge swings in the predicted payout, which is normally spot on when a payout occurs because I verify it when I look at when I get paid.
My 100GH miner has fallen to .001 while my 180GH/s of miners is .008 to .010 which doesn't make sense for the 100GH/s miner.
I see the global pool is now 485GH/s.
It depends on when the last share was found by your 100GH miner. Expected payout will indeed swing around wildly as hash rates increase/decrease, share difficulties increase/decrease, shares drop off the payout list, etc. To see what I mean visit p2pool.smoothrunnings.ca:9332 I went to your node and see nothing wrong with the reported numbers. The payouts to each miner are determined by how many shares that miner has submitted in the given timeframe, and the weights associated to those submitted shares. As an example, I have 2 S1s running on my local node. Currently, my expected payouts show one with 0.02 and the other with 0.007. Both have been running for exactly the same time, but one has found more shares than the other. |
|
|
|
I am seeing huge swings in the predicted payout, which is normally spot on when a payout occurs because I verify it when I look at when I get paid.
My 100GH miner has fallen to .001 while my 180GH/s of miners is .008 to .010 which doesn't make sense for the 100GH/s miner.
I see the global pool is now 485GH/s.
It depends on when the last share was found by your 100GH miner. Expected payout will indeed swing around wildly as hash rates increase/decrease, share difficulties increase/decrease, shares drop off the payout list, etc. |
|
|
|
Oh, and I can confirm that merged mining works fine still as I now have block rewards for IXC, NMC, and DVC.
jonnybravo - would you mind telling me what ports (rpc & p2p) you are using for your different coins? I see so many different statements regarding this it's daft, & seeing as yours are confirmed working...... Thanks For those of you interested in merge mining on your p2pool node, there's a great thread here: https://bitcointalk.org/index.php?topic=62842.0It's rather old, but the information in it is good. Below, I've put the *.conf files from my system, and the command I use to start my node. User names and passwords have been changed. 1) bitcoin.conf server=1 rpcuser=BTCuser rpcpassword=BTCpassword rpcallowip=10.0.1.* rpcport=8332 2) devcoin.conf server=1 rpcuser=DVCuser rpcpassword=DVCpassword rpcallowip=10.0.1.* rpcport=53333 3) ixcoin.conf server=1 daemon=1 listen=1 rpcuser=IXCuser rpcpassword=IXCpassword rpcallowip=10.0.1.* rpcport=8338 4) namecoin.conf server=1 daemon=1 listen=1 rpcuser=NMCuser rpcpassword=NMCpassword rpcallowip=10.0.1.* rpcport=7333 5) Node startup nohup ./run_p2pool.py --give-author 0 --merged http://NMCuser:NMCpassword@10.0.1.10:7333 --merged http://IXCuser:IXCpassword@10.0.1.10:8338 --merged http://DVCuser:DVCpassword@10.0.1.10:53333 -a NODEWALLETADDRESS BTCuser BTCpassword > /dev/null 2>&1 & Hope this helps! |
|
|
|
You know, it's funny. I've read that wiki like 1000 times and just completely missed that. I think my brain said, "Yeah, you'll never find a block, so no need to worry about that bonus. Not storing this information.". Thanks for pointing it out for me |
|
|
|
And with all the hashing power coming onboard, it was my little S1 that found the block this morning  I'm just excited - it's the first block I've found! Oh, and I can confirm that merged mining works fine still as I now have block rewards for IXC, NMC, and DVC. Just curious about one thing. I must have gotten a reward for finding the block. Because the amount "mined" my S1 shows in my wallet is way above what the expected payout graphs show on my node. Does p2pool offer a reward to the block finder? If so, how much? |
|
|
|
|
With p2pool you need to find shares to get on the payout list. With your Antminer S1, you should expect to find a share approximately every 8 hours or so. Once you find shares, every time p2pool finds blocks, you get paid based on how many shares you've found in a given timeframe (rolling 3 day window). Take a look at the p2pool thread to get a complete overview of how it works.
|
|
|
|
I'm pretty sure that's the theory behind bit solo ( http://bitsolo.net). You get the 25 BTC, the pool gets the transaction fees. EDIT: I misread your original query. Sorry, I don't know of any pools that will give a full BTC to the miner that found the block, then split the remaining 24.xxx with the rest. |
|
|
|
Don't complain. Be thankful  Oh, I'm very thankful, and I want more! Lemme go buy up some more hardware so I can cash in on this mania! ... *evil grin* Definitely! I went from expected time to share of about an hour and a half to about 3 and a half hours because of the jump in difficulty that came as part of the increased hash rate. First thing I thought was, "Better get new hardware!" |
|
|
|
|
Show Posts
