Bitcoin Forum
December 06, 2016, 02:28:29 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 [52] 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 ... 201 »
  Print  
Author Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #  (Read 417766 times)
muyuu
Donator
Legendary
*
Offline Offline

Activity: 924



View Profile
May 27, 2012, 02:33:16 PM
 #1021

My production has gone to shit lately while my hashing rates are the same. What's going on?

GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)
forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
1481034509
Hero Member
*
Offline Offline

Posts: 1481034509

View Profile Personal Message (Offline)

Ignore
1481034509
Reply with quote  #2

1481034509
Report to moderator
1481034509
Hero Member
*
Offline Offline

Posts: 1481034509

View Profile Personal Message (Offline)

Ignore
1481034509
Reply with quote  #2

1481034509
Report to moderator
1481034509
Hero Member
*
Offline Offline

Posts: 1481034509

View Profile Personal Message (Offline)

Ignore
1481034509
Reply with quote  #2

1481034509
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 27, 2012, 02:47:31 PM
 #1022

My production has gone to shit lately while my hashing rates are the same. What's going on?
You're not finding any blocks <.<

muyuu
Donator
Legendary
*
Offline Offline

Activity: 924



View Profile
May 27, 2012, 03:20:43 PM
 #1023

My production has gone to shit lately while my hashing rates are the same. What's going on?
You're not finding any blocks <.<

Eh well, definitely not a matter of chance. The whole graph has changed completely. It was steady for months, now it's not.

This particular machine I moved it to Eligius in February:

(tested different configurations, ramped up with 2 card)


Same machine in March (a couple reboots there):


And this is now (stopped it last night to see if it made any difference - didn't):

GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)
forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 27, 2012, 03:33:34 PM
 #1024

My production has gone to shit lately while my hashing rates are the same. What's going on?
You're not finding any blocks <.<

Eh well, definitely not a matter of chance. The whole graph has changed completely. It was steady for months, now it's not.
Eligius is SMPPS: so long as it consistently has income to cover full PPS, it does so. When it runs out, it's similar to proportional (but still not vulnerable to hopping), but keeps track of work done (the pink "maximum reward") so it can overpay later when it catches up on blocks.

John (John K.)
Global Troll-buster and
Legendary
*
Offline Offline

Activity: 1092


Will read PM's. Have more time lately


View Profile
May 27, 2012, 04:05:46 PM
 #1025

By the way, how long do you need to be idle before what's remaining on your address (including the namecoins) are paid out? I've taken some of my rigs offline lately due to the heat here and the balance around ~0.21 coins including 5.2~ NMC are still sitting there for almost a week.

My BTC Tip Jar: 1Pgvfy19uwtYe5o9dg3zZsAjgCPt3XZqz9 , GPG ID: B3AAEEB0 ,OTC ID: johnthedong
Escrow service is available on a case by case basis! (PM Me to verify I'm the escrow!)

muyuu
Donator
Legendary
*
Offline Offline

Activity: 924



View Profile
May 27, 2012, 04:17:30 PM
 #1026

My production has gone to shit lately while my hashing rates are the same. What's going on?
You're not finding any blocks <.<

Eh well, definitely not a matter of chance. The whole graph has changed completely. It was steady for months, now it's not.
Eligius is SMPPS: so long as it consistently has income to cover full PPS, it does so. When it runs out, it's similar to proportional (but still not vulnerable to hopping), but keeps track of work done (the pink "maximum reward") so it can overpay later when it catches up on blocks.

Still, this would mean we have hit very exceptional "hard times", is this the case? should I turn off this shit or not? Cheesy

GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)
forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 27, 2012, 04:21:53 PM
 #1027

By the way, how long do you need to be idle before what's remaining on your address (including the namecoins) are paid out? I've taken some of my rigs offline lately due to the heat here and the balance around ~0.21 coins including 5.2~ NMC are still sitting there for almost a week.
The first block after your balance hasn't increased for a week. In "extra credit" mode, balances might keep increasing even after you stop mining for a while, though.

My production has gone to shit lately while my hashing rates are the same. What's going on?
You're not finding any blocks <.<

Eh well, definitely not a matter of chance. The whole graph has changed completely. It was steady for months, now it's not.
Eligius is SMPPS: so long as it consistently has income to cover full PPS, it does so. When it runs out, it's similar to proportional (but still not vulnerable to hopping), but keeps track of work done (the pink "maximum reward") so it can overpay later when it catches up on blocks.

Still, this would mean we have hit very exceptional "hard times", is this the case? should I turn off this shit or not? Cheesy
Not that exceptional. We've had huge buffers before, and the equivalent in extra credit is just as likely. So long as we keep mining, it should even out eventually, so I'm personally not going to stop.

muyuu
Donator
Legendary
*
Offline Offline

Activity: 924



View Profile
May 27, 2012, 04:29:34 PM
 #1028

Not that exceptional. We've had huge buffers before, and the equivalent in extra credit is just as likely. So long as we keep mining, it should even out eventually, so I'm personally not going to stop.

Well, since I'm mining here (Feb) only very recently this has started happening. But if it's just a temporary occurrence I will just shrug it off.

It's also the right place to mine, ain't it.  Smiley

GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)
forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 27, 2012, 04:43:41 PM
 #1029

OK, so we've hit an interesting dilemma, and I'd like input on how to handle it. Until this is resolved, all balances and payouts are frozen (but will be retroactively corrected/paid when we come to a conclusion).

Block 000000000000081a00eb707e9a9d816708933b50887afd895a38ac3c425e56de was found by an Eligius miner. However, the miner who found it didn't obey the 2 minute rule on jobs, and it was expired (this means a very slow internet connection and/or buggy mining software). It was therefore rejected as a share, but still submitted to the Bitcoin network as a valid block. One of the safeguards in Eligius's SMPPS implementation checks that all blocks crediting the pool are also valid shares - if it didn't, someone could submit shares that were invalid because they paid the wrong people, for example. Especially in "extra credit" mode, accepting shares over 2 minutes long could very well result in overpayment as well.

So as I see it, there are 4 options available:
  • (1) Ignore this block and any like it, as if it was completely unrelated to the pool. Everyone paid in the block gets a little bonus compliments of the miner who didn't follow the rules.
  • (2) Accept blocks that don't actually try to overpay someone, even if the pool doesn't recognize it as valid participation. This could be fairly difficult to implement, as it means refactoring the code such that it can "back out" of a block it has already begun to process.
  • (3) Partially accept these blocks: recognize the payouts as valid and deduct it from the relevant balances, but don't add the 50 BTC to the "pool blocks found" balance. The net effect of this means that the block value more or less gets redirected to me.
  • (4) Partially accept the blocks, but add the actual deductions (that don't take balances negative) to the "pool blocks found" balance. This is basically the same as accepting the whole block (1) when it doesn't take balances negative, but with a "half way" state. It's also the most complicated option to implement.

Any other ideas for how to handle it? I'll try to put up a poll when I'm satisfied there's no more nominations - hopefully by the end of today.

Edit: Please note that in any case, the miner who found the invalid share will not be credited for it. The share validity rules are there for a reason.

Edit: Also, I was wrong about why the share was invalid: it wasn't expired work, the time header was too old. Miners may move the time header forward or backward, but only 5 minutes backward! Since jobs expire after 2 minutes, a share with over 5 minute old time header means the mining software is doing something pretty stupid. In this particular case, it probably means the miner's system clock is wrong. (This also puts the block at risk of being rejected by Bitcoin itself.)

Edit: To clarify, having your system clock wrong can make invalid shares if your miner uses it to modify the time header. In this case, the miner in question is using Eligius's distributed mining via getmemorypool, probably with gmp-proxy which does supplant the proxy's system time in the header (or else it'd drift too fast). Most (all?) getwork miners seem to be reasonable with how they modify the time header. In any case, unless your shares are showing rejected as time-too-old, you don't need to worry about it.

muyuu
Donator
Legendary
*
Offline Offline

Activity: 924



View Profile
May 27, 2012, 05:09:08 PM
 #1030

I vote 1.

GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)
forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
atsoat
Newbie
*
Offline Offline

Activity: 23


View Profile
May 27, 2012, 05:39:10 PM
 #1031

Looking at blockchain.info, after the block you dsicussed, I see two other blocks today that appear to be Eligius blocks, which are not showing up on the eligius.st under found blocks:

http://blockchain.info/block-height/181845
http://blockchain.info/block-height/181839

They both payout to the address normally included on Eligius payouts (   18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B ) so I don't think they are just relayed blocks, that blockchain is incorrectly tagging against Eligius.

In fact they have payed out the full 50 BTC to that address.

Has that dodgy block confused the code somehow?

Edit: In fact, looking at that address a bit more, it has picked up a couple of other 50 BTC payments over teh last few days whilst we have been running with a long payout queue:

http://blockchain.info/address/18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B

Absolutely not suggesting anything improper - just hoping that there is a code error contributing to our poor luck over the last few days.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 27, 2012, 07:11:54 PM
 #1032

Looking at blockchain.info, after the block you dsicussed, I see two other blocks today that appear to be Eligius blocks, which are not showing up on the eligius.st under found blocks:

http://blockchain.info/block-height/181845
http://blockchain.info/block-height/181839

They both payout to the address normally included on Eligius payouts (   18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B ) so I don't think they are just relayed blocks, that blockchain is incorrectly tagging against Eligius.

In fact they have payed out the full 50 BTC to that address.

Has that dodgy block confused the code somehow?

Edit: In fact, looking at that address a bit more, it has picked up a couple of other 50 BTC payments over teh last few days whilst we have been running with a long payout queue:

http://blockchain.info/address/18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B

Absolutely not suggesting anything improper - just hoping that there is a code error contributing to our poor luck over the last few days.
18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B is the pool's (offline) address, generated to when there's no payouts ready and in "blank" longpoll blocks before the transactions have been recalculated following a network block. Generally, the 50 BTC ones are the latter case. As mentioned in my previous post, payouts are frozen until the issue is resolved, so all blocks mined until then will go entirely to this address. The SMPPS code automatically catches any abnormality and shuts down until a human has had the opportunity to look over the situation and deal with it. Basically, all of this is expected behaviour to ensure the pool is kept secure from attempted exploits.

lunchb0x
Newbie
*
Offline Offline

Activity: 20


View Profile
May 27, 2012, 07:39:19 PM
 #1033

I vote for 1 because it seems like the simplest solution. Although there will definitely need to be some sort of warning about it on the homepage.

You wont donate, so why do I bother?

1KVorVNG5nSjstYvYxcqDEauhLGhGPmbF3
49er
Jr. Member
*
Offline Offline

Activity: 52


View Profile
May 27, 2012, 07:43:26 PM
 #1034

I'm not sure I fully understand the problem, but personally I'd prefer the fairest option.

If the invalid share paid the "official" pool address, then that should go to the "pool blocks found" balance. If the invalid share paid pool users' addresses, then the amount paid to them should be subtracted from what those users will earn.  If they go negative then so be it, hopefully (most likely?) it won't be by much.

I guess I don't see the problem with taking users' balances negative.  They get the payout either way, correct?
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 27, 2012, 07:55:09 PM
 #1035

If they go negative then so be it, hopefully (most likely?) it won't be by much.

I guess I don't see the problem with taking users' balances negative.  They get the payout either way, correct?
Yes, but if I treat it as a block, I'm personally liable for overpayments. If those negative balances never "pay back" with mining, they're paid, but the pool has that much less funds.

atsoat
Newbie
*
Offline Offline

Activity: 23


View Profile
May 27, 2012, 07:57:26 PM
 #1036

18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B is the pool's (offline) address, generated to when there's no payouts ready and in "blank" longpoll blocks before the transactions have been recalculated following a network block. Generally, the 50 BTC ones are the latter case. As mentioned in my previous post, payouts are frozen until the issue is resolved, so all blocks mined until then will go entirely to this address. The SMPPS code automatically catches any abnormality and shuts down until a human has had the opportunity to look over the situation and deal with it. Basically, all of this is expected behaviour to ensure the pool is kept secure from attempted exploits.

OK, that makes sense - I missed the bit where you said payments had been suspended.

If I understand correctly, a user producing such blocks can't be altering the payouts (or all their shares would be being rejected) - so they are just submitting late/messing up altering timestamps. So I wouldn't try to write complicated routines for such an abnormal case. In virtually all cases when you get a block like this it is going to be paying out to correct addresses which will not be taken negative by the payout. So I'd aim to accept in these cases.

However, I don't really like solution 1, as that seems exploitable by somebody who wants a chance of get their payout multiple times, by delying their submission should they find a block.


atsoat
Newbie
*
Offline Offline

Activity: 23


View Profile
May 27, 2012, 08:04:47 PM
 #1037

If they go negative then so be it, hopefully (most likely?) it won't be by much.

I guess I don't see the problem with taking users' balances negative.  They get the payout either way, correct?
Yes, but if I treat it as a block, I'm personally liable for overpayments. If those negative balances never "pay back" with mining, they're paid, but the pool has that much less funds.


How can they go negative? The only way I can see is if one of those blocks occur around the same time as a manual payout is being done.

In any case, if they should go negative then I don't see how the pool is any worse off - as accepting that abnormal block has reduced the pools payout liability.
drlatino999
Sr. Member
****
Offline Offline

Activity: 335



View Profile
May 27, 2012, 08:15:57 PM
 #1038

OK, so we've hit an interesting dilemma, and I'd like input on how to handle it. Until this is resolved, all balances and payouts are frozen (but will be retroactively corrected/paid when we come to a conclusion).

Block 000000000000081a00eb707e9a9d816708933b50887afd895a38ac3c425e56de was found by an Eligius miner. However, the miner who found it didn't obey the 2 minute rule on jobs, and it was expired (this means a very slow internet connection and/or buggy mining software). It was therefore rejected as a share, but still submitted to the Bitcoin network as a valid block. One of the safeguards in Eligius's SMPPS implementation checks that all blocks crediting the pool are also valid shares - if it didn't, someone could submit shares that were invalid because they paid the wrong people, for example. Especially in "extra credit" mode, accepting shares over 2 minutes long could very well result in overpayment as well.

So as I see it, there are 4 options available:
  • (1) Ignore this block and any like it, as if it was completely unrelated to the pool. Everyone paid in the block gets a little bonus compliments of the miner who didn't follow the rules.
  • (2) Accept blocks that don't actually try to overpay someone, even if the pool doesn't recognize it as valid participation. This could be fairly difficult to implement, as it means refactoring the code such that it can "back out" of a block it has already begun to process.
  • (3) Partially accept these blocks: recognize the payouts as valid and deduct it from the relevant balances, but don't add the 50 BTC to the "pool blocks found" balance. The net effect of this means that the block value more or less gets redirected to me.
  • (4) Partially accept the blocks, but add the actual deductions (that don't take balances negative) to the "pool blocks found" balance. This is basically the same as accepting the whole block (1) when it doesn't take balances negative, but with a "half way" state. It's also the most complicated option to implement.

Any other ideas for how to handle it? I'll try to put up a poll when I'm satisfied there's no more nominations - hopefully by the end of today.

Edit: Please note that in any case, the miner who found the invalid share will not be credited for it. The share validity rules are there for a reason.

Edit: Also, I was wrong about why the share was invalid: it wasn't expired work, the time header was too old. Miners may move the time header forward or backward, but only 5 minutes backward! Since jobs expire after 2 minutes, a share with over 5 minute old time header means the mining software is doing something pretty stupid. In this particular case, it probably means the miner's system clock is wrong. (This also puts the block at risk of being rejected by Bitcoin itself.)

Edit: To clarify, having your system clock wrong can make invalid shares if your miner uses it to modify the time header. In this case, the miner in question is using Eligius's distributed mining via getmemorypool, probably with gmp-proxy which does supplant the proxy's system time in the header (or else it'd drift too fast). Most (all?) getwork miners seem to be reasonable with how they modify the time header. In any case, unless your shares are showing rejected as time-too-old, you don't need to worry about it.
Interesting, I need to get some coffee to help with the thinking.

Sappers clear the way
coinft
Full Member
***
Offline Offline

Activity: 187



View Profile
May 27, 2012, 09:42:41 PM
 #1039


OK, so we've hit an interesting dilemma, and I'd like input on how to handle it. Until this is resolved, all balances and payouts are frozen (but will be retroactively corrected/paid when we come to a conclusion).

Block 000000000000081a00eb707e9a9d816708933b50887afd895a38ac3c425e56de was found by an Eligius miner. However, the miner who found it didn't obey the 2 minute rule on jobs, and it was expired (this means a very slow internet connection and/or buggy mining software). It was therefore rejected as a share, but still submitted to the Bitcoin network as a valid block. One of the safeguards in Eligius's SMPPS implementation checks that all blocks crediting the pool are also valid shares - if it didn't, someone could submit shares that were invalid because they paid the wrong people, for example. Especially in "extra credit" mode, accepting shares over 2 minutes long could very well result in overpayment as well.

So as I see it, there are 4 options available:
  • (1) Ignore this block and any like it, as if it was completely unrelated to the pool. Everyone paid in the block gets a little bonus compliments of the miner who didn't follow the rules.
  • (2) Accept blocks that don't actually try to overpay someone, even if the pool doesn't recognize it as valid participation. This could be fairly difficult to implement, as it means refactoring the code such that it can "back out" of a block it has already begun to process.
  • (3) Partially accept these blocks: recognize the payouts as valid and deduct it from the relevant balances, but don't add the 50 BTC to the "pool blocks found" balance. The net effect of this means that the block value more or less gets redirected to me.
  • (4) Partially accept the blocks, but add the actual deductions (that don't take balances negative) to the "pool blocks found" balance. This is basically the same as accepting the whole block (1) when it doesn't take balances negative, but with a "half way" state. It's also the most complicated option to implement.

...

This is the first time this happened? Likely it will not happen soon again. Let's go with 1 as it is least work and simplest to understand, and doesn't change much overall.

-coinft.
Peter Todd
Legendary
*
Offline Offline

Activity: 1064


View Profile
May 27, 2012, 09:54:15 PM
 #1040

I mine on Eligius for fun with some spare equipment, so take this for what it's worth, but I'm all for #1; sounds like a lot less work for you.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 [52] 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 ... 201 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!