[OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #

[punin]

+1 for #1 here. Mind publishing the address of the miner who submitted that block? He might come forward and help resolve this.

[willphase]

vote for #1 - seems like the least work.  miners should probably check that the time on their rig is set to something consistent with reality.

Will

[drlatino999]

vote for #1 - seems like the least work.  miners should probably check that the time on their rig is set to something consistent with reality.

Will

Woops, my main mining rig was only behind by...a year and a month. ~If there is a God, Please don't let this be my fault~

[Luke-Jr]

Since it's technically in the public share log anyway... 1Q5vfJ2dEFgRcsF9SQSGgvAnpk2Fp2bMCi is the one who found the block in question.

I've accepted this block into the pool since it seems innocent enough (no balances went negative even briefly). What to do with future occurances, if any, we can figure out later.

[PawShaker]

In FAQ the is:

The Payout Queue prioritizes qualifying payouts based on their age.

May I suggest adding:

The age of payout is counted since last payout or first contribution.

Current wording implies that age is counted since "payout" became a "qualifying payout".

I went over FAQ again because there is something that bothers me and I could not figure it out. How does current block estimate works? At this moment I contribute tiny 0.17% of the whole pool hash rate. However, estimated reward for the next block is only 0.12% of 50 BTC per block reward. It may seem that 0.05% is not much but it actually makes about 40% diff to my payouts.

Does it means that there are some people who jumped out of the pool and pool still owes them "maximal reward"? I am I correct at guessing that I am offered (my unpaid reward)/(all unpaid rewards)*50BTC. This would depend on historical contributions as long as 30h ago. While hash rate calculations are based on last 3 hours performance only.

[TheSeven]

I went over FAQ again because there is something that bothers me and I could not figure it out. How does current block estimate works? At this moment I contribute tiny 0.17% of the whole pool hash rate. However, estimated reward for the next block is only 0.12% of 50 BTC per block reward. It may seem that 0.05% is not much but it actually makes about 40% diff to my payouts.

Does it means that there are some people who jumped out of the pool and pool still owes them "maximal reward"? I am I correct at guessing that I am offered (my unpaid reward)/(all unpaid rewards)*50BTC. This would depend on historical contributions as long as 30h ago. While hash rate calculations are based on last 3 hours performance only.

This is caused by two things.
First, the timeframe for the hashrate calculation is not identical to the time it takes to find a block.
Second, the SMPPS reward system currently has a depleted buffer, causing it to not be able to pay full PPS rewards until pool luck will get high enough. It will attempt to pay that back as soon as it can, but nobody knows if it will ever be able to fully pay it.
This is my main concern against SMPPS: It is more likely for you to be fully paid if you leave the pool now, however if everybody does that nobody will be fully paid at all. This is a very critical situation for the pool, and if it stays like this for a long time, miners will start leaving, and new miners will have no incentive to join, effectively killing the pool. Let's hope for luck to catch up quickly

Regarding the valid block in invalid share dilemma, I think the most fair solution is the most complicated one (which wasn't proposed above), to take these blocks into account, dropping a user's balance negative if necessary, only putting the "collected" funds into the buffer, until the user "pays back" his debt (by mining), which would put the remaining funds in the buffer once this happens. A bit complicated, but should be possible, and should not be attackable any worse than any of the other solutions.
I had an in-depth discussion about the pros and cons of this with Luke-Jr yesterday on IRC, and it seems that we agree that this is the solution with the least negative impact on the pool (or even a positive one).

[PawShaker]

OK. I made a tottal newbe out of myself... again. However, I think there is a mistake on page:
http://eligius.st/wiki/index.php/Shared_Maximum_PPS

The pseudo code reads:

Code:

totalFunds += 50 BTC
availableFunds = totalFunds - totalReward

totalEarned = 0
for each miner m
  totalEarned += m.Earned + m.ExtraCredit

for each miner m
  reward = m.Earned + m.ExtraCredit
  if totalEarned > availableFunds:
    reward = reward * (totalFunds / totalEarned)
  m.Reward += reward
  totalReward += reward
  m.ExtraCredit += m.Earned - reward
  m.Earned = 0

It should be:

reward = reward * (availableFunds / totalEarned)

[49er]

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.

Why are you personally liable for those over payments?  Do you just mean it can make the pool look bad?  Technically, those people are being overpaid either way, just one way you are tracking it in the system.  And I would guess that for 99% of these cases, people will already be positive, or go positive within a day or two.

I understand negative balances could cause the pool to lose it's buffer over time.  To avoid the appearance of this, perhaps only count those parts of the payout once those accounts have gone back positive.  So if a payout was 50 btc and someone was paid out 5 when they were only owed 1, then take them to 0, and say the block reward was only 46.  Track those would be negative accounts and as they earn payments, deduct the payouts until the block reward is back to 50.  Perhaps this is what was meant by option #4, but with tracking.  It's probably the most complicated to implement, but seems to me to be the most fair.

[Luke-Jr]

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.

Why are you personally liable for those over payments?  Do you just mean it can make the pool look bad?  Technically, those people are being overpaid either way, just one way you are tracking it in the system.  And I would guess that for 99% of these cases, people will already be positive, or go positive within a day or two.

If it's accepted into the system, then not only are the payouts deducted from miners' balances, but there's also 50 BTC the pool was "supposed" to have received for distribution. If the 50 BTC doesn't go to pay off the pool's debts (because someone gets overpaid), I'm liable out-of-pocket for that difference.

I understand negative balances could cause the pool to lose it's buffer over time.  To avoid the appearance of this, perhaps only count those parts of the payout once those accounts have gone back positive.  So if a payout was 50 btc and someone was paid out 5 when they were only owed 1, then take them to 0, and say the block reward was only 46.  Track those would be negative accounts and as they earn payments, deduct the payouts until the block reward is back to 50.  Perhaps this is what was meant by option #4, but with tracking.  It's probably the most complicated to implement, but seems to me to be the most fair.

Yes, that seems the most ideal, but probably almost impossible to implement with the current setup. Maybe one day I'll rewrite the coinbaser in a sane way (perhaps upgrading to ESMPPS at the same time?), but until then, I'm inclined to just accept "no overpayment" blocks as they come up and ignore ones that are clearly trying to harm the pool if we encounter them.

[Luke-Jr]

Firstly, I know this used to be correct - so I'll ask here to see if that has changed:

Code:

13:35 <@kanoi> your pool ignores transactions ... so I'm of course suspicious of your comments ...
13:35 < luke-jr> no, it doesn't.
13:35 < luke-jr> that's just slander.
13:35 <@kanoi> it's true
13:36 <@kanoi> you ignore transactions with no fee
13:36  * luke-jr puts kanoi back on ignore for slander

then

13:39 <@kanoi> luke-jr true or false: <@kanoi> you ignore transactions with no fee

Can anyone deny this?
The way to deny it would simply be to identify any 0 fee non-coinbase transaction in a recent Eligius BTC block ...
(before block 182456)

I don't mind being wrong, in fact I'd be happy to be wrong about this particular issue, but I do want the facts, not here-say.

Block #182428, Block #182410, Block #182370, Block #182322, Block #182294, Block #182235, Block #182159, Block #182145 - enough?

And it's not a matter of "ignoring" transactions, it's a matter of not processing them. Any processing of transactions without a fee is done charitably; by design, Bitcoin does not oblige miners to be charitable with processing. Eligius continues to employ aggressive anti-spam checks on feeless transactions, to avoid wasting charity on spammers. Because of the nature of spam detection, it is necessary to keep the algorithms used confidential (or the spammers would just design the spam to fit the rules), so it's easier to just stick to a simple "fees are 0.00004096 BTC per 512 bytes", but there has always been exceptions to that rule when the pool is reasonably certain a transaction isn't spam. And yes, there are a lot of "not sure" cases that aren't let through feeless, but if they needed faster processing they really should be offering a fee - Eligius's fee rules are quite relaxed compared to the defaults.

[Luke-Jr]

Yep - enough - I looked at the current block (182454) and it also has no 0 Fee txn's - so I thought you still hadn't changed that.
http://blockchain.info/block-index/231606/0000000000000256e46d46b389de5690e5033c1ebb94561fdc261bcb831d9c1b

Looks like you have improved your 'algorithm' ...
Good

P.S. I'll delete these posts soon - you already have a copy here in your post if you need it - I just don't want "Show new replies to your posts." to show up here

[Luke-Jr]

Anyone want to test our fancy new donation address? 31igiusSdShicXmGAbJHNJuit1rzuJYKzF (requires 0.6.0+)

[drlatino999]

Anyone want to test our fancy new donation address? 31igiusSdShicXmGAbJHNJuit1rzuJYKzF (requires 0.6.0+)

 I could be tempted if the unlucky streak is broken sooner rather than later

[rjk]

Can the new address type be used for regular transactions, or is it limited to multisig transaction types only?

[Luke-Jr]

Can the new address type be used for regular transactions, or is it limited to multisig transaction types only?

Pretty much any kind of transaction, even non-standard ones.

[John (John K.)]

Uh oh. Artefact server down?

Code:

500 Internal Server Error

nginx/0.8.54

[Luke-Jr]

Uh oh.

DDoS. Working on it, should be back online soon.

[bulanula]

Uh oh.

DDoS. Working on it, should be back online soon.

Funny stuff. I remember you saying the other day Eligius would be harder to DDOS than P2Pool yet now I see p2pool still working.

I have nothing to do with the DDOS BTW. Just an observation and you got proved wrong ...

[Luke-Jr]

Uh oh.

DDoS. Working on it, should be back online soon.

Funny stuff. I remember you saying the other day Eligius would be harder to DDOS than P2Pool yet now I see p2pool still working.

I have nothing to do with the DDOS BTW. Just an observation and you got proved wrong ...

No, it didn't prove anything wrong. Eligius is still working, I just had to activate the DDoS protection - now we have more info to build on to automate activating it better next time. p2pool is still working because nobody bothered to try DDoSing it yet. If someone wanted to do a comparison to "prove me wrong", they need to DDoS p2pool too (which is just as illegal as DDoSing Eligius, so I don't endore doing it) with the same amount of bandwidth and see how each pool does after 24 hours of it.

[Krakonos]

Hey,

with the recently very poor luck, I'd be interested in how many blocks are we "behind". Is there some way to get info about negative buffer size? A graph would be cool (I like graphs), but numbers will suffice.

Thanks