Thanks for a nice payout today!  How's it going with Gigamining? Yeah, I was going to ask same thing. I myself already sent them affidavit and monday I'm gonna have first, beefy payout since GLBSE closure. |
|
|
|
|
BID:
6 BTC/board for all 48 boards.
Please PM me to discuss details.
|
|
|
|
Already bought hardware from 4 forum members. Thank you guys I am waiting for more offers from anyone willing to sell FPGAs. Regards Lenny |
|
|
|
Everything arrived secured very well and 100% working. Thank you |
|
|
|
|
DeadTerra I sent you PM can you reply please:)
|
|
|
|
|
I discovered this bug in December 2012 but I didn't realize back then that my Bitcoins addresses are gone forever. I was discussing problems with sending Bitcoins from my wallet with Multibit main developer, jim618. But we both wasn't aware how serious this problem is, and my reported issue has been put away to his queue.
In February 2013 I checked again all my private keys and all adresses and realized that two private keys not match my Bitcoin addresses. Keys were for different address, but wallet still thought that they match and kept trying to do my transactions using wrong private keys, which was of course unsuccessful. Then I contacted Jim again, I sent him my wallet with some backups from past, but all of them contained wrong private keys and recovery failed completely.
This is a really serious bug. Everytime you create new receiving address you should check it triple times on different wallets like Satoshi Client of Blockchain that private key match Bitcoins address - otherwise any payment sent to these addresses will be gone forever.
|
|
|
|
This sucks hard. Have you contacted the developer? Has the bug been fixed? Yes that's sucks really hard. I am not using Multibit anymore, it's too risky. Of course I contacted Jim (developer) and he made all effort to recover my Bitcoins but without success. Bug has not been identified so it's still in the wild. If you using Multibit, please be careful, always add all your private keys to different wallet and compare addresses after. |
|
|
|
|
Please let me know if you have any FPGA to sell.
|
|
|
|
I think we completely misunderstand each other.
I am talking about:
my FPGA hardware doing 0.01% rejects or less on Bitminter using Stratum. Same hardware, exactly same configuration doing 15% rejects on p2pool. I tried to tweak config and got slightly better results about 10% but that's still not the main case. 15% - That's reported by miner and by p2pool stats as well.
That's much too high. I have ~2.5% rejects on all my Spartan6 (CM1 and Icarus with MPBM). I have 2.6% rejects on my GPUs (5870 and 5970 with cgminer). So I really don't see any problem with FPGAs and P2Pool: in fact they react slightly faster than my GPUs (cgminer autotune the intensity on each one to react in 50ms). That's wasting resources, nothing else. When we invest our money and time in something, we should do it right.
They don't waste resource, a share is only rejected if it both arrives too late and doesn't solve a block so there's no,zero,0 income wasted by these rejects. I repeat: rejects don't reduce the pool's income. FPGAs just react too slow to change nonce every couple of seconds
Now that's mixing your particular configuration which is clearly not optimized for p2pool and plain FUD (since when the target is a couple of seconds?). , to top of that add remote node's bitcoind latency + network latency + time to prepare getwork etc... This is just not working for LP= 10s, it's a disaster.
Nope, it isn't a disaster: I earned more with p2pool in 6 months than I would have on a 100% PPS pool since I started (I keep track of each and every payment and compare it to my theoretical income on a no fee PPS pool). No one is mining of remote p2pool nodes as it will just not work as it is right now.
Probably depends on the actual node and who connects to it: some have better connectivity than others. I used to mine on one of my rented VPS servers with a 45ms round-trip time with my miners and it worked OK (it was around 98% efficiency IIRC). If you guys are saying there is no solution for that - so beware, because one day p2pool will die.
I think p2pool is for geeks who like to setup and tune everything themselves. When you can host a node properly (for me this means locally on a host with a good CPU, 2GB RAM on a Linux server dedicated to bitcoind+p2pool, a SSD to store bitcoind's data and with a good QoS setup so that both bitcoind and p2pool don't suffer from other traffic on your WAN connection) and configure a backup pool it's arguably the most reliable and profitable option. It's not for everyone, but if you are a serious miner and have the network connection and hardware available it's simply the best solution. From what you wrote there are surprising latencies in your setup: it probably isn't for you. Can you please share your settings with me? cgminer is able to get similar results? |
|
|
|
PANIC SELL!! Price has just dropped to $30... Im buying at $29  On which exchange? |
|
|
|
|
I think we completely misunderstand each other.
I am talking about:
my FPGA hardware doing 0.01% rejects or less on Bitminter using Stratum. Same hardware, exactly same configuration doing 15% rejects on p2pool. I tried to tweak config and got slightly better results about 10% but that's still not the main case. 15% - That's reported by miner and by p2pool stats as well. That's wasting resources, nothing else. When we invest our money and time in something, we should do it right. FPGAs just react too slow to change nonce every couple of seconds, to top of that add remote node's bitcoind latency + network latency + time to prepare getwork etc... This is just not working for LP= 10s, it's a disaster. No one is mining of remote p2pool nodes as it will just not work as it is right now.
If you guys are saying there is no solution for that - so beware, because one day p2pool will die.
|
|
|
|
|
So what's your solution for 10-15% rejects?
|
|
|
|
|
I don't care about variance. I am patient (wise?) enough, to not follow "luck" drama.
I tried Icarus, CM1 and Ztex on remote nodes - result was 10-15% doa/orphan. Absolutely not acceptable. On local p2pool indeed I have nice results, but I cannot afford to run another spare computer 24/7 with Phenom II onboard just to get bitcoind latency lower. I just want to mine on remote nodes like I do with any other central pool. Increasing difficulty is only one solution for this.
|
|
|
|
|
Good idea. It will be exactly same as it is now, but 5x greater chance to have block and payout within 5 days, especially matter for small miners. And LP 50sec will greatly decrease orphan+DOA ratio. Right now there is no point to mine on p2pool unless: we have GPU only with low intensity + we have fast CPU + fast Internet and local node on it. I tried remote nodes with many configurations, with GPUs, many FPGAs, result was always tragic.
|
|
|
|
the PPLNS system should be changed to the last 7 days.
Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money. I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners. |
|
|
|
Block ETA is now 19hrs and rising, when we go over 24hrs (pool rate under 200GH) mining will become totally unprofitable...
We need more power!
Can you please explain in more technical way? |
|
|
|
Hi, I want to buy any FPGA working and mining device you have. I am located in Europe. PM me with your offers! Regards Lenny |
|
|
|
|
Show Posts
