Cool, glad to hear it.
But you then are paying a fee, even if knowingly and voluntary. I have knowingly volunteered to pay fee's too.
Sam
you can't disable the fees on the top 3 pools.  Of course you can. We have the freedom to not to use those pools if we don't want to pay the fee's. I choose to pay those fee's because they provide a service that has a value to me. Also I "donate" to another pool because that pool has a value to me as well. Sam You can't use the service without paying the fees. I can mine on P2Pool without paying anything to anyone except myself. One of these days I will look into P2Pool and estimate for myself the value for that software. And if it is as good as you say I'm sure I'll be paying/donating more than the default .05%. Sam |
|
|
|
Cool, glad to hear it.
But you then are paying a fee, even if knowingly and voluntary. I have knowingly volunteered to pay fee's too.
Sam
you can't disable the fees on the top 3 pools. Of course you can. We have the freedom to not to use those pools if we don't want to pay the fee's. I choose to pay those fee's because they provide a service that has a value to me. Also I "donate" to another pool because that pool has a value to me as well. Sam |
|
|
|
The trick was finding a no-fee pool with 100% up time. After that problem was solved, it became a no-brainer.
It would be a good trick to find ANY pool with a 100% up time. I have never heard of one yet. Sam P2Pool is 100% up time of course. If my mining computers are running, I'm mining. Now, if my power or electricity goes out, I'm not mining, but I wouldn't be with any pool. So, 100% practical up time. Doc, Point taken . But one must be aware that there is a default donation, I understand, (that isn't advertised???), and you need to disable if you don't want to pay a fee. Sam The fee is stated in plain English on the P2Pool wiki page. Cool, glad to hear it. But you then are paying a fee, even if knowingly and voluntary. I have knowingly volunteered to pay fee's too. Sam |
|
|
|
The trick was finding a no-fee pool with 100% up time. After that problem was solved, it became a no-brainer.
It would be a good trick to find ANY pool with a 100% up time. I have never heard of one yet. Sam P2Pool is 100% up time of course. If my mining computers are running, I'm mining. Now, if my power or electricity goes out, I'm not mining, but I wouldn't be with any pool. So, 100% practical up time. Doc, Point taken . But one must be aware that there is a default donation, I understand, (that isn't advertised???), and you need to disable if you don't want to pay a fee. Sam |
|
|
|
The trick was finding a no-fee pool with 100% up time. After that problem was solved, it became a no-brainer.
It would be a good trick to find ANY pool with a 100% up time. I have never heard of one yet. Sam |
|
|
|
I did switch recently to slush's pool purely because I wanted to get my hands on some Namecoins
Once you get your hands on a Namecoin, then what are you going to do with it? I guess you could then another 193 or so and then trade it for a Bitcoin  . Sam |
|
|
|
I am mostly sick of the recent pools turning into straight-up thieves and this time I am involved in this and wont let it slip away.
How many pools have done this kind of thing? Sam |
|
|
|
I'm testing P2SH implementation, so small part of our blocks may be marked as /P2SH/, don't worry.
So is P2SH fully implemented or are you still in the testing phase? Well, I tried to delay it as much as possible but this is not productive already, so I'll give up. Currently P2SH is deployed and expected network switch date is 01.04.2012 unless something happens. Sorry for that. No need to apologize. Who knows, maybe this will actually be the greatest thing since sliced bread? I just can't see making a major and permanent change for a temporary and, sometime in the future, self obsolescent vulnerability. Thanks, Sam |
|
|
|
I'm testing P2SH implementation, so small part of our blocks may be marked as /P2SH/, don't worry.
So is P2SH fully implemented or are you still in the testing phase? Sam |
|
|
|
I can vote for it or not vote at all.
Your original post states your annoyance at the 591, which I'm part of, that are not voting for or against. Since I'm not a programmer and you programmers have not built in the option for me to choose, I cannot vote against. And since the current client also is voting for P2SH with NO NOTIFICATION to the end user you have force people to vote for it that have no idea they are. 1. This is NOT a voting. 2. Not putting /P2SH/ in your coinsbase is the same as "voting against". I've heard you say that many times. But how does D&T come up with this statement? "377 Support vs 32 Oppose (and 591 who can't be bothered to include a couple bits in the coinbase to indicate an opinion one way or the other)." Did he just make up the 32 that oppose? Sam |
|
|
|
377 Support vs 32 Oppose (and 591 who can't be bothered to include a couple bits in the coinbase to indicate an opinion one way or the other).
And how, exactly, does one bother themselves "to include a couple bits in the coinbase"? I have seen no options in any of my Bitcoin Clients to "vote" one way or another on any BIP! Sam Edit: sarcasm removed, for now It's NOT a voting and just adding a couple of bytes will make things worse. Those who include /P2SH/ in their coinbase aren't just saying that they like BIP16, it means that their software is ready to support it. That's all well and good and informative. But my point is that this "voting" can only be done by developers/programmers and not by ordinary mortals like myself since it requires a code change and recompilation. So that gives developers free reign to do whatever they want, no matter what anyone else may think. Sam Really you are that helpless? You can use choose to either use a p2sh capable bitcoind OR NOT. You can choose to mine at a p2sh capable pool OR NOT. Hence you can "vote" by your actions. I can vote for it or not vote at all. Your original post states your annoyance at the 591, which I'm part of, that are not voting for or against. Since I'm not a programmer and you programmers have not built in the option for me to choose, I cannot vote against. And since the current client also is voting for P2SH with NO NOTIFICATION to the end user you have force people to vote for it that have no idea they are. Sam |
|
|
|
377 Support vs 32 Oppose (and 591 who can't be bothered to include a couple bits in the coinbase to indicate an opinion one way or the other).
And how, exactly, does one bother themselves "to include a couple bits in the coinbase"? I have seen no options in any of my Bitcoin Clients to "vote" one way or another on any BIP! Sam Edit: sarcasm removed, for now It's NOT a voting and just adding a couple of bytes will make things worse. Those who include /P2SH/ in their coinbase aren't just saying that they like BIP16, it means that their software is ready to support it. That's all well and good and informative. But my point is that this "voting" can only be done by developers/programmers and not by ordinary mortals like myself since it requires a code change and recompilation. So that gives developers free reign to do whatever they want, no matter what anyone else may think. Sam |
|
|
|
377 Support vs 32 Oppose (and 591 who can't be bothered to include a couple bits in the coinbase to indicate an opinion one way or the other).
And how, exactly, does one bother themselves "to include a couple bits in the coinbase"? I have seen no options in any of my Bitcoin Clients to "vote" one way or another on any BIP! Sam Edit: sarcasm removed, for now |
|
|
|
I'm using Phoenix 1.5
That's quite an old version, 1.7.5 is current. Yep, its an old version. I believe I had tried a newer version on this system and it didn't work. But I'll re examine that. Well I did re-examine that. 1.7.5 does work on this system just fine. Thanks again, Sam |
|
|
|
The miner kernel is designed to find difficulty 1 hashes. If you are solo mining, then only 1/1,500,000th of these will meet the full difficulty and be a block solve. It may take many months to find a 50BTC block. If you are using P2PPool, this is normal as they use a higher difficulty than 1.
So, for clarification in my mind. Are you saying that this is normal operation or that this isn't the proper miner to use for solo mining? Thanks, Sam |
|
|
|
I recently started playing around with solo mining. I'm using Phoenix 1.5 and am getting the following message
"Result didn't meet full difficulty, not sending"
I get this about 2 to 4 times per block.
Is this normal?
Thanks,
Sam
That's quite an old version, 1.7.5 is current. That message means either that the pool you are mining for has a higher difficulty setting for shares than normal, or more likely your miner kernel is returning bad hashes (too high GPU overclock, etc). Yep, its an old version. I believe I had tried a newer version on this system and it didn't work. But I'll re examine that. Since this is mining against a local Bitcoin client which has the updated blockchain it should be mining the correct difficulty. How would I go about verifying that? This system is being used for other purposes so the GPU is set to factory default clocks with a very low aggression. Thanks, Sam |
|
|
|
|
I recently started playing around with solo mining. I'm using Phoenix 1.5 and am getting the following message
"Result didn't meet full difficulty, not sending"
I get this about 2 to 4 times per block.
Is this normal?
Thanks,
Sam
|
|
|
|
I've tried both custom and auto miners and cant get them to work. Failed connection.
which mining node and what mining software are you using? A few clues would help us troubleshoot Breif downtime coming up, doing patches to bitcoind.
Nodes should only be down a few minutes.BIP30 and BIP16 patches applied. What's BIP30? Sam |
|
|
|
I have not checked the source code, but it seems that CGMINER keeps getting work from all defined pools, regardless if it mines on them or not. I am on very slow line (GPRS), so this hogs it the line a lot. Can it be run in "no poll" mode, just being switched on failure of primary pool?
BTW, i already use --failover-only, but it has no effect on amount of work being downloaded.
That is how CGMiner works and is one of the nice features, except in your case I guess. When/if the main pool is slow sending work then it "leaks" shares to the backup pools so that your GPU's are more fully utilized. In most cases this is desirable behavior. I have no idea how to disable this share "leak" feature though if "--failover-only Don't leak work to backup pools when primary pool is lagging" doesn't do it. Sam |
|
|
|
Executive summary: if you are a p2pool or solo miner you should upgrade before the switchover date (April 1, if all goes well) or there is a good chance you'll produce nothing but orphan blocks. I welcome suggestions on how to effectively get that message out to the community.
Quick clarification on this, Solo miners need only upgrade the bitcoin client they are mining through in order to ensure generated blocks are "clean". But, with P2Pool, because it's peer to peer. Would not EVERY P2Pool miner need to upgrade their clients or else the entire pool could be affected? (example being I'm mining against P2Pool, I'm using an updated client, but joebob is also mining on P2Pool with an old client. If his client happens to be the one that finds the block, even though I've contributed shares towards said block, and he includes the invalid tx, the whole block, and all contributing miners to that block get screwed correct?) If this is the case, that's a pretty big problem for P2Pool miners. Because there is no way for us to know if the rest of the pool is updated. (and it essentially opens up P2Pool to a DOS attack vector. Anyone looking to take down P2Pool can join up with bogus clients and mine to start injecting bad blocks into the mining results for the whole pool... Sure it would only be proportional to the mining power brought to the table by the "attacker" relative to the rest of P2Pool, but it's still an attack vector). Also what classifies as "upgraded". (ie: I'm running the latest official client from bitcoin.org, but not a dev branch. Do I need a dev branch? if so which version specifically) Thanks! Well, I'm assuming the non-upgraded miner's shares would not be valid to the rest of P2Pool if they are not valid as a block, so they would effectively be harming only themselves. Valid shares will be paid for and potentially be a block on the Bitcoin network. Non-valid shares will not be paid for and will not be a block on the Bitcoin network. So, legitimate P2Pool miners will not be affected in the slightest. But don't take my word for it, find someone with actual technical knowledge on the subject. I'm sure someone will see this thread eventually, but if you want a quick answer, ask it in the P2Pool thread. If you do as Doc suggests please post the answer back here too. Thanks, Sam |
|
|
|
|
Show Posts
