I see, your efforts to innovate come with some still unresolved technical issues that have the potential to result in more down time compared to a traditional pool. More like potential technical issues. Downtime last week was basically hardware failure, and technical issues with random people not being able to connect are some Linux bug. BTW, the last time I joined the pool, I was getting some kind of "upstream RPC error." The issue may have been with my miners though, as I think I was running them at a slightly unstable clock at the time. Also, my broadband connection was wonky at the time, so that is a potential culprit too. I can't think of any way that would have happened for any significant length of time. |
|
|
|
But I'm wondering if there is any connection between what you call the "experimental" nature of the pool and stability? And if there is a connection, what is it exactly? I'm not seeing any connection. It seems to me that the recent server crash and resulting down time could have happened to any pool operating from one server, regardless of how "experimental" or "traditional" the pool might be. In a way, I like the experimental nature of the pool, if this means you are still in the process of trying to improve the whole model. And the instability isn't a huge issue since I need backups anyway. Still, I'm wondering if the ongoing experimental nature of the pool means an ongoing higher probability of instability. I'm totally fine with the way the payment system works, and understand that this can at times mean a longer wait to get paid, so I'm just wondering about the stability connection, if in fact there is one. I keep the "experimental" label because I am not completely satisfied with the status quo yet. Eligius-Su runs a mixture of the old codebase with a newer codebase designed for MPPS and hacked to do SMPPS. It needs to replay the entire pool history (at about 12 TH/s) whenever I restart it (though I can hot-patch it without a restart). The current codebase is not capable of payout except in generation, which is causing some annoying delays. So a rewrite is still needed. In addition, the Linux networking stack has been randomly choosing machines it doesn't allow to connect-- we get the SYN packet fine, but Linux silently discards it without passing it to pushpoold. Investigation of this problem is ongoing. Finally, I am not 100% certain SMPPS is the best road to the future, and think newer, possibly better, payout methods should be researched and considered. I am happy that my efforts in this area have sparked others into researching alternatives as well, and hope we will see much more variety of payout methods to experiment with in the near future. |
|
|
|
To me PPS systems still seem to be tha fairest ones, but with SMPPS or RSMPPS there is a risk involved that some shares will never be paid, if the pool hash rate has a peak at a bad luck streak. No, there is no such risk. No matter how bad the luck, every share will always be paid at least something. |
|
|
|
The real question is, how low can variance be pushed without risking pool bankruptcy or making some shares worth a lot more than others or risking not pying some miners at all (a bad luck streak at a hashing peak with this method would mean if difficulty goes up the miners from back then will probably never be paid at all while a SMPPS pool gets deep into red numbers)
With PPLNS, variance is 0 per block for the operator and very low for the participants. Note that there is also variance created by the pool being to small regardless of the scoring method used. |
|
|
|
However, if someone has that much power, I would consider solo mining... Even if it took a week, it would be worth finding a block all to yourself. I'm sure they've done some solo mining just for the fun of finding their own blocks, but no matter how high the hashrate, a pool can still provide better income than solo mining  |
|
|
|
No extension is sane if it breaks the specification for the low-level protocol. However, one real problem found is that a mask like ff00ff00 would be a pain to implement. Therefore, I am proposing replacing noncemask with noncerange, with a value of two 32-bit integers (encoded as hex) specifying the initial value, and last acceptable value. So for example, to give a miner the first 29 bits of nonce space (up to 536 MH/s): "noncerange": "000000001fffffff" |
|
|
|
OMG:
#1 Eligius-Su 16ccjkuuQjQ64H9qssmXnj695DdBDR75wJ 59.06 GH/s
#2 6 Gh/s
Who the fuck is #1? Jesus! Thats a whole pool inside another pool, right?
That's a corporation that wishes to remain anonymous. They have a server rack full of GPUs. |
|
|
|
|
I suggest you update your website...
|
|
|
|
RSMPPS was something I considered when I was coming up with SMPPS. The key problem with it is, that cheaters (that is, people who only submit useless valid shares) can avoid taking any of the damage from their cheating. Solve that, and we have a winner  Can you elaborate on the submitting useless valid shares? Does SMPPS solve this? Only the one share that gets the pool a block is actually useful. Cheaters can reduce pool luck by refusing to submit those. With PPS, the liability is held entirely by the pool operator. With proportional, MPPS, and SMPPS, the liability is distributed among everyone in the pool. With RSMPPS, that liability is distributed among everyone except the cheater. I don't get it. If the cheater refuses to submit the winning share, would he be able to submit it elsewhere and get the 50 BTC? If not, is he just doing this to screw over the pool? Why would the liability not be distributed to the cheater in case of RSMPPS? Yep, pretty much just to screw the pool. So long as the cheater is careful going about it, he gets paid full PPS with no penalty under RSMPPS. I won't elaborate, as I don't care to encourage it. |
|
|
|
RSMPPS was something I considered when I was coming up with SMPPS. The key problem with it is, that cheaters (that is, people who only submit useless valid shares) can avoid taking any of the damage from their cheating. Solve that, and we have a winner Can you elaborate on the submitting useless valid shares? Does SMPPS solve this? Only the one share that gets the pool a block is actually useful. Cheaters can reduce pool luck by refusing to submit those. With PPS, the liability is held entirely by the pool operator. With proportional, MPPS, and SMPPS, the liability is distributed among everyone in the pool. With RSMPPS, that liability is distributed among everyone except the cheater. |
|
|
|
RSMPPS was something I considered when I was coming up with SMPPS. The key problem with it is, that cheaters (that is, people who only submit useless valid shares) can avoid taking any of the damage from their cheating. Solve that, and we have a winner I think people should run like hell from any system that delays payment for any reason other than "120 confirmations". So, you consider "we don't have the money to pay you more" a bad reason? Every pool does that... SMPPS just makes it rare. Why not just use a pool that uses the cheat-proof method... It discourages pool hopping, but doesn't devalue shares of intermittent use. As far as I can tell it doesn't have consistent share values... but more importantly, Python can't handle the huge numbers it was giving me, so I couldn't even get a visual example of what it would do. We had a nice analysis and vote on various systems for Eligius. SMPPS won. My pool pays out at 120 confirms for each round, discourages pool hopping, but doesn't hold funds. Eligius pays out at 1 confirm (ie, when it finds the block) usually, pays both pool hoppers and regular miners fairly, and only holds funds that nobody has done the work to earn yet. |
|
|
|
|
In case anyone cares to donate for this fix: 135LFGd9PxGdZQ4yBaAwTcfAUiZBY1bKvA
|
|
|
|
a) generation transaction does not require a fee, regardless of size of its outputs I wasn't talking about a transaction fee by the pool, but rather for the miners later when they want to spend it. fees do not depend on input sizes, only on output sizes. This is not correct, under the hard-coded rules in bitcoind. The data size of a transaction is the primary focus of fees, and will be huge if all the coins are fractions of what people actually spend. |
|
|
|
This does Proportional payouts, which are predictably unfair. To work, you'd have to also implement auto-hopping-- that is, when total shares reach 43%, throw them all away and start over. Alternatively, there is also a real-world PPLNS implementation in the Pools forum. Also, even with auto-hopping, each share would be valued at down to 0.00006806 at today's difficulty. Payouts of this size would result in huge transfer fees (which is why we added a minimum payout for Eligius) and coinbase transactions. Therefore, this kind of system would need to clutter together miners in different groups by similar hashpower so they all maintain at least 1% or so when the block is found. This also means that any number of CPU miners will still never find a block as a group.
a) generation transaction does not require a fee, regardless of size of its outputs I wasn't talking about a transaction fee by the pool, but rather for the miners later when they want to spend it. b) we'll let the miners take care of the pool hopping if they so choose That's a cop-out. c) difficulty: you have failed to read the proposal carefully - suggested difficulty is 1e-4 * currentdifficulty, and miners of different power can choose to create/join pools of different difficulties.
d) the system proposes exactly the 'cluster together of miners by hash power precisely - the miners will self-select into pools of appropriate difficulty for them. That doesn't really fix the problem. CPU miners won't be able to meet that difficulty, and a pool of just CPU miners will never get a block. They are left out in the cold. |
|
|
|
Arsbitcoin is another SMPPS pool like eligius. I like eligius as a backup but they have had a lot of issues staying online for more than a day or so at a time. That was with failing hardware. Seems to be stable since getting Su up and running. |
|
|
|
I've been dipping my feet in to test the waters at this pool but am getting ~80% invalid/stale shares. I don't have this problem anywhere else, is there something I can do to correct this? Without your address, nobody can investigate. My first tip would be to check your system clock. 1BwiSFPwkPaB14KYLjVVzSNJjcbFrwNycP Everything seems to check out on my end. Going to leave a card running on your pool for 30-60 minutes to see how it works out. Fingers crossed. 75% of the shares are "corrupted", which basically means your shares have work the pool never asked you to do in the first place... This is generally either cheating (trying to solo mine, but still claim shares), miner bugs (ie, if it's changing the merkle root or prevblock instead of the ntime), GPU problems (overclocking or overheating?), or the pushpoold crashing (in which case it would affect everyone). I would suggest trying different miner software, and seeing where that gets you. |
|
|
|
I've been dipping my feet in to test the waters at this pool but am getting ~80% invalid/stale shares. I don't have this problem anywhere else, is there something I can do to correct this? Without your address, nobody can investigate. My first tip would be to check your system clock. |
|
|
|
|
This isn't mining software.
|
|
|
|
|
What's wrong with B⃦ and/or B⃫ ?
|
|
|
|
|
Show Posts
