Bitcoin Forum
December 04, 2016, 03:50:04 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 103 ... 201 »
  Print  
Author Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #  (Read 417536 times)
punin
Hero Member
*****
Offline Offline

Activity: 559


View Profile WWW
May 27, 2012, 09:59:32 PM
 #1041

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

Head of Product Development
Bitfury Group
www.bitfury.com
1480823404
Hero Member
*
Offline Offline

Posts: 1480823404

View Profile Personal Message (Offline)

Ignore
1480823404
Reply with quote  #2

1480823404
Report to moderator
1480823404
Hero Member
*
Offline Offline

Posts: 1480823404

View Profile Personal Message (Offline)

Ignore
1480823404
Reply with quote  #2

1480823404
Report to moderator
1480823404
Hero Member
*
Offline Offline

Posts: 1480823404

View Profile Personal Message (Offline)

Ignore
1480823404
Reply with quote  #2

1480823404
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480823404
Hero Member
*
Offline Offline

Posts: 1480823404

View Profile Personal Message (Offline)

Ignore
1480823404
Reply with quote  #2

1480823404
Report to moderator
willphase
Hero Member
*****
Offline Offline

Activity: 770


View Profile
May 27, 2012, 10:19:42 PM
 #1042

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
Sr. Member
****
Offline Offline

Activity: 335



View Profile
May 27, 2012, 10:23:30 PM
 #1043

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~

Sappers clear the way
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 27, 2012, 11:02:25 PM
 #1044

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
Full Member
***
Offline Offline

Activity: 140



View Profile
May 28, 2012, 09:55:02 AM
 #1045

In FAQ the is:
Quote
The Payout Queue prioritizes qualifying payouts based on their age.

May I suggest adding:
Quote
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.

1FQkH63k6hkexFMTRzLtJEE6ZAaTBRhjiS
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
May 28, 2012, 10:39:06 AM
 #1046

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 Smiley

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).

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
PawShaker
Full Member
***
Offline Offline

Activity: 140



View Profile
May 28, 2012, 01:24:37 PM
 #1047

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:
Quote
reward = reward * (availableFunds / totalEarned)

1FQkH63k6hkexFMTRzLtJEE6ZAaTBRhjiS
49er
Jr. Member
*
Offline Offline

Activity: 52


View Profile
May 28, 2012, 04:39:22 PM
 #1048

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
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 28, 2012, 07:09:57 PM
 #1049

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
Legendary
*
Offline Offline

Activity: 2086



View Profile
June 01, 2012, 04:32:18 AM
 #1050

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
Legendary
*
Offline Offline

Activity: 2086



View Profile
June 01, 2012, 05:40:27 AM
 #1051

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 Smiley

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 Smiley

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
June 05, 2012, 02:00:40 PM
 #1052

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

drlatino999
Sr. Member
****
Offline Offline

Activity: 335



View Profile
June 06, 2012, 12:40:01 AM
 #1053

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 Cheesy

Sappers clear the way
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
June 06, 2012, 01:37:26 AM
 #1054

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

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
June 06, 2012, 03:00:11 AM
 #1055

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.)
Global Troll-buster and
Legendary
*
Offline Offline

Activity: 1092


Will read PM's. Have more time lately


View Profile
June 07, 2012, 12:21:11 AM
 #1056

Uh oh. Artefact server down?

Code:
500 Internal Server Error

nginx/0.8.54

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!)

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
June 07, 2012, 12:38:22 AM
 #1057

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

bulanula
Hero Member
*****
Offline Offline

Activity: 518



View Profile
June 07, 2012, 05:52:14 PM
 #1058

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. Wink

I have nothing to do with the DDOS BTW. Just an observation and you got proved wrong ...
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
June 07, 2012, 06:01:19 PM
 #1059

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. Wink

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
Member
**
Offline Offline

Activity: 60


View Profile
June 07, 2012, 06:13:58 PM
 #1060

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

Tip jar: 1MWj8Etpt3ayLG5AvXwhtEU42szJD2m97z
Pages: « 1 ... 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 103 ... 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!