Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 # - page 147. (Read 458499 times)
June 10, 2012, 07:46:17 PM
We just finished a 23h57m round.
June 08, 2012, 07:32:39 AM
http://eligius.st/wiki/index.php/Shared_Maximum_PPS also describes the variants.
The link I posted links to that page, and I looked at it, but didn't scroll down. Where's the facepalm emoticon? June 08, 2012, 12:29:45 AM
I'm actually surprised it didn't come earlier.
Would be pro. I already see the pool hashrate down. New people might help it a little.
If this goes on for too long, I might consider "upgrading" to ESMPPS just so new miners don't feel like they're losing out. Thoughts?
Would be pro. I already see the pool hashrate down. New people might help it a little.
June 07, 2012, 07:00:45 PM
http://eligius.st/wiki/index.php/Shared_Maximum_PPS also describes the variants.
June 07, 2012, 04:08:48 PM
I don't think you included a link in your post about going to ESMPPS pointing to information on the two systems. This would make it easier for incredibly lazy bums who don't want to (or average joes who don't know where to) search for information on the difference between the two systems.
ETA: https://en.bitcoin.it/wiki/Comparison_of_mining_pools (and you thought I was one of those people)
This page links to Eligius's definition of SMPPS and a post about ESMPPS in a thread on this forum. I guess I'd get paid the same amount at the end of the day, but with a low hashrate and more old work, I'm not sure which I like better. I say we just get back to the other side of the luck.
ETA: https://en.bitcoin.it/wiki/Comparison_of_mining_pools (and you thought I was one of those people)
This page links to Eligius's definition of SMPPS and a post about ESMPPS in a thread on this forum. I guess I'd get paid the same amount at the end of the day, but with a low hashrate and more old work, I'm not sure which I like better. I say we just get back to the other side of the luck.
June 07, 2012, 01:32:45 PM
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.
There is currently approximately 1000 BTC worth of extra credit issued.Considering Eligius's history of above-average luck, and often peaking out over 1000 BTC buffered, this seems pretty normal/expected.
For comparison, another pool member noted yesterday that p2pool's luck works out to 2400 BTC behind.
If this goes on for too long, I might consider "upgrading" to ESMPPS just so new miners don't feel like they're losing out. Thoughts?
June 07, 2012, 01:17:44 PM
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 ...
Fair point. Did you find out why / who was DDOSing ? Called the FEDs ?
June 07, 2012, 01:13:58 PM
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
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
June 07, 2012, 01:01:19 PM
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 ...
June 07, 2012, 12:52:14 PM
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 ...
June 06, 2012, 07:38:22 PM
Uh oh.
DDoS. Working on it, should be back online soon. 
June 06, 2012, 07:21:11 PM
Uh oh. Artefact server down?
Code:
500 Internal Server Error
nginx/0.8.54
nginx/0.8.54
June 05, 2012, 10:00:11 PM
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. 
June 05, 2012, 08:37:26 PM
Can the new address type be used for regular transactions, or is it limited to multisig transaction types only?
June 05, 2012, 07:40:01 PM
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
June 05, 2012, 09:00:40 AM
Anyone want to test our fancy new donation address? 31igiusSdShicXmGAbJHNJuit1rzuJYKzF (requires 0.6.0+)
June 01, 2012, 12:40:27 AM
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
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
May 31, 2012, 11:32:18 PM
Firstly, I know this used to be correct - so I'll ask here to see if that has changed:
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?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?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
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.
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.
May 28, 2012, 02:09:57 PM
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.I guess I don't see the problem with taking users' balances negative. They get the payout either way, correct?
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.
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. May 28, 2012, 11:39:22 AM
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.I guess I don't see the problem with taking users' balances negative. They get the payout either way, correct?
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.
Jump to: