Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 # - page 190. (Read 458370 times)

I would suggest you move this to http://eligius.st/

I had created a similar tool for my own purposes and it my code correctly determines the order since it seems to match with the payout queue from the new raw .txt file.  It does draw lines every 50 BTC to give me a sense of how far out my payment is likely to be:

http://twistymaze.net/eligius/  http://eligius.st/~twmz/

But don't count on this estimate being accurate.  There are several fundamental flaws with my web page...

One problem is that it's looking at a snapshot of balances as of right now.  If you look at it now and a block is not found for 2 hours, the order will probably not be the same when the block is found because a) people are still mining and so the people in the first block will earn more BTC and push out the last few people from the first block into the second block and b) people who aren't above the threshold for payout may get over the threshold and suddenly qualify for payout and when they get added to the queue, they'll push everyone below them down the list furthur and possibly in a different block.

Another problem is that it is not accurately splitting large balances between blocks.  For example, if someone has an unpaid balance of 20 BTC and is near enough the top of the queue to get included at the end of the first block, they may only get paid say 15 BTC (because there isn't enough of the generated 50 BTC to pay them in full).  The web page will list their remaining 5 BTC at the top of the next block.  In reality, that's probably not what will happen because that remaining 5 BTC is probably not old enough to qualify to be at the top of the queue.  You can see this happening several times in the web page where the last address of a block is the same as the first address of the next block.  Those are all likely wrong (the address won't usually be the first address of the next block anymore once the first payment is made).

So, this is a pretty good estimate of who will get paid in the next block if it is found right after you look at it (but you can already see that at http://eligius.st/~luke-jr/raw/5/current_block.json).  On the other hand, my page is not a perfect estimate of exactly who will be paid 4 blocks from now--certainly not the amounts since by the time we find 4 blocks, everyone's balances will be higher.

Knowing those flaws, I still use it myself and find it useful to know if I going to be paid "soon" or "not soon".  If it shows I am not due to get paid for 5 blocks, I at least know that I am not getting paid in the next 1-2 blocks.  I find it valuable that it removes some of the unknown even though it isn't perfectly precise.  Your mileage may vary.

Look at that text file luke just posted.  You should be on there in the queue.

Just to ask: is it normal to have 0.50181637 BTC of unpaid reward, when a block has been found 34 minutes ago? I'm fairly certain that it exceeded 0.33554432 BTC at the time when the block was found, and suspect something might be malfunctioning. I'm certain that payout has not occurred, since my local block chain has an equal number of blocks as a well known exchange service reports on their website.

( address edited out, all OK )

Lack of usefulness is why I didn't publish it to begin with. There are no block boundaries and it's reordering constantly.

It seems to list users that are over the threshold sorted from oldest to most recent... I guess I agree that the list would need to be divided into block/50BTC segments according to up-to-date user balances to be useful.

This isn't very useful to be honest, since there are no block boundaries. Unless I am missing something important?

Due to popular demand, new data: http://eligius.st/~luke-jr/raw/5/payout_queue.txt

And always use trim instead of (insert your language's default way of doing it here) to avoid incoming "your language is horrible" arguments trolling!

Always .trim() input.

That's what I thought would be the case but after 3 hours and having transactions from my other pool showed up, I started wondering. Anyway probing deeper and finding the transaction in block explorer made me figure I must had just experienced the same bitcoin client bug after missing transaction which some of the others had posted about. Shutting down and running bitcoin client with the -rescan option fixed that.

Payouts are done with "generate" transactions.  If you get paid in any given block, you should see it in your wallet almost immediately, but it won't be spendable or be counted in your balance until it gets 120 confirmations.

Anybody knows if payout depends on whether the last block (crossing the payout floor) has gotten 120 confirmations or not?

No, the problem here is that there are two sets of probabilities involved – the normal pool luck, and the risk of a block being invalid. Since all shares have equal chance of meeting the difficulty requirement it means that valid and invalid blocks would, on average, require the same amount of work. The problem then, as I see it, is that invalid blocks don't have a good luck counterpart – as I said, there are no lucky hashes that pay double. So, if a PPS pool has a 1% rate of invalid blocks it means that it will reward its miners 1% more than it earns for the valid blocks.

Copy and paste by dragging down to the next line?
Fortunately, mine starts with 1MT

Whoever owns 1MY3ypFCDSbFYnM9jw4YvPnCfEDQz9sGGE is a n00b and broke sharesrv by sending "1MY3ypFCDSbFYnM9jw4YvPnCfEDQz9sGGE\n" as their username. I fixed and hot-patched it, so everything's fine now, but stats weren't updated while it was broken. Also, the username is still invalid-- so it is being treated as donated shares like any other invalid address. Since this one might be non-obvious, I thought I'd better post about it to try to wake whoever it is up... how do you get \n into a username anyway? -.-

Your argument assumes that there is such a thing as "x% completed" on a block. Any share has the same probability to be a valid block and invalid blocks are just bad luck because somebody else was quicker with a new block while your client did not yet get word of that block. Once you got notified there's no drawback anymore since the chances are the same. Only during the time period where somebody has published a new block and bitcoind is not yet aware of it are shares lost.

Invalid blocks can't really be prevented, it can only be reduced by connecting the pools and solo-miners better so that the time is reduced in which a collision can occur. But it can't be reduced to 0.

It's the same with offline time, by the way. During the 8 hours that Eligius was offline recently which resulted in a 33-hour round, no shares were really lost although a couple of blocks were generated. So it's perfectly OK to pay for shares on invalid, old and long running rounds since a valid block can be found with every share and the probability is independent of how long the round has been running / not running.

I see a spike on the reward graph that seems to indicate there was an invalid block in the last long round. It's the first I've noticed on Su, and considering the number of valid blocks since the server was started up I'd say the ratio is quite good.

But, what I'm wondering, is how well paying full PPS for rounds that include invalid blocks will work in the long run. It feels like it, eventually, will push the pool's balance into the red since there are no "extra valid" blocks that pay double to help correct the relation between luck and available funds.

I assume this is something that has been given thought, but it feels like something worth a bit of discussion as well.

is there a JSON output for individual user stats

Ha, that explains it alright!
Thanks for the quick answers, I appreciate it.