Topic: Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB - page 133. (Read 1061417 times)

Indeed, the full Bitcoin network has difficulty of any arbitrary value, but I've never seen a pool (any pool! not just this one) that sent share of values not multiple of two.

That's wrong. Difficulty can be anything including fractional values. It's a power of two as a cheap optimisation/numerical convenience for the pool software run here.

nice manual payout 

THX 

Your last sentence is exactly what I was driving towards.  While it may be a long ways off and chances are pretty good none of us on this board will be around to see it, the transaction fees are what will be utilized to incentivize miners of the future.  A lot of people, when discussing the block reward halving in the next couple years fall back on the argument of, "Yeah, but BTC will be worth double what it is now, so it all balances out."  What would be really nice to see is the widespread adoption of BTC globally, and as such transaction fees playing a larger role in payouts as well.  As you very correctly point out, Eligius in its current form does nothing with transaction fees except to pay off some more of the shelved shares.

The ideal mathematical case is that it takes infinitely many steps, so you never reach 0, but Bitcoin cannot be subdivided smaller than 0.00000001 BTC. In 2140, the reward will round down to 0 and no new bitcoins will be created. However, that is very far in the futures, and many things will change from here. (One probable thing that might happen is that the protocol might be modified to make bitcoin divisible to smaller unit)

Anyway, the point is moot, as it is know that the current algorythm of Eligius is unsustainable in the long term. It is built as if transaction fees do not exist; and indeed at first it didn't even pay them to the miners. The fact that the transaction fees are put toward paying the share log is a relatively new thing (a few months), but the shares are still 'created' as if the the transactions fees were not paid to the miners.

That problem is not really significant currently, because the transaction fees are insignificant, but I'm pretty sure the pool operator will address this when the transaction fees will become significant. It is just difficult to devise a "fair" way of paying the transaction fees to the miners, because contrarily to the block reward, their value is unpredictable and varies a lot.

Yes, karma is a bitch. The universes balance will kick in sooner or later... that's just the way it is.

According to The Bitcoin Wiki, the block reward of block # 6930000 and all subsequent blocks will be 0.

I have a question for you. 

If you're 5 feet from a wall, and each step you take, you cover half the distance, how many steps will it take before you're there?


(the block reward will never reach 0)

M

The new point you added about what will happen when the block reward goes from 25 to 12.5 is very interesting and I hadn't thought about that previously, but it bears consideration especially if you bring it to its logical conclusion: a share becomes worthless when the block reward becomes 0.  The payout logic remains the same, (block reward + transaction fees) worth of shares are paid out, but the intrinsic "value" of the share, which previously was always some positive value in BTC, becomes zero.

I just changed it anyway, made that section more detailed.

Assuming his sentence is the first quote, and your proposed change is the second, his is far clearer.  If anything needs to be added at all, perhaps the second sentence could read, "The 'worth' of the previously found share does not change when the bitcoin difficulty changes."

TLDR (yet), but ...
Need some rephrasing to make it more clear ... probably

I just tought that it might help people undestand how this pool works by making a summary of the pool operations in list form.

A) The pool maintains the following:
1. A share log.
2. A payout queue.
3. For each user, a record indicating their own personnal balance, their payout threshold, the date of their last payout and the date of their of their last account activity.
4. An offline wallet.

B) Initialization
1. The share log and the payout queue begin empty.
2. The personal balance of each miner is initialized at 0; and the date of their last payout and their last activity is initialized at the date they begun mining.
3. The payout threshold is chosen by each miner, if none is given, it defaults to 0.04194304 BTC.
4. The offline wallet begins empty.

C) Unit of accounting
1. The basic unit of accounting in Eligius is a "share". A share is 'worth' block_reward/bitcoin_difficulty. (At the time of writing this: 25 BTC/17 336 316 979 = 0.000 000 001 442 BTC)
2. The value of bitcoin_difficulty for a given share is the difficulty at the time the share was awarded. It does not change later when the bitcoin difficulty increases.
3. The value of block_reward, however, is always taken as the current block reward. So when the block reward will be cut in half in 2017, the 'value' of all the shares still in the share log will be halved.

D) When a user submits a miner share (a valid proof-of-work meeting the difficulty requirement of the pool, pdiff):
1. The pool adds to the top of the share log pdiff shares. These shares are identified as belonging to the miner who submitted them.

E) When the pool finds a block:
1. 25 BTC+Transaction fees worth of shares are removed from the top of the share log, and credited to their respective miners' record. Each miners who was credited at least one share has it's date of last activity updated to the time the block was found.
2. If a miner was payed out with the generation transaction of that block, the payed out amount is removed from it's personnal balance. The date of their last payout is updated to the moment the block was found.
3. The pool refreshes the payout queue, see below.

G) How the payout queue is built:
1. Each user records are checked. Miners whose personnal balance is above their payout threshold are put in the payout queue. Miners whose date of last activity is older that a month are also put in the payout queue.
2. The queued miners are sorted by the time of their last payout, the oldest first.
3. The pool then goes down the list and finds the last queued miner such as the total of the balance of all the miners above him (including him) stays below 25 BTC. All those miners are put in the generation transaction to be put in the next block the pool finds, to be payed the full amount of their balance.
4. If the payout queue does not contain 25 BTC worth of queued miners's balance, the exceeding amount is sent to the pool's offline address.
5. While the pool computes 1, 2 and 3 (it takes time), it makes the miner work on a simple block that would send all the generated amount to the pool's offline address, to not waste miner's work.

H) When the payout queue grows longer that a few hundred BTC:
1. The pool operator initiates a transaction with the bitcoins in the offline wallet, paying everybody in the payout queue (except those in the first block, so that miners still have something to work on) the full amount of their balance.
2. If a miner was payed out with the manual payout transaction, the payed out amount is removed from it's personnal balance. The date of their last payout is updated to the date the transaction was submitted.
3. The pool refreshes the payout queue.

I) When the Bitcoin network orphans a block found by Eligius.
1. Everything that was done when the pool found the block (see E) is completely reversed.
2. Safe mode is triggered, see below.

J) When the pool is in safe mode:
1. The pool works mostly as normal, meaning submitted share are recorded as belonging to their respective miners, and when a block is found, those shares are credited to the miners' balance.
2. However, the automatic payout by generation transaction are disabled: The pool will always mine to the offline wallet until the situation is checked by the pool operator, who'll do some sanity check to ensure everybody is receiving their due amount. If everything is OK, the pool will resume normal operation.
3. During safe mode, the payout queue and the stats displayed on the main site may of may not be correct.
4. Safe mode may be triggered by an orphaned block, but it may also be triggered when a checks built into the pool software fails for whatever reason, it is however usually benign, but better be safe that sorry.

Difficulty is a power of 2.

Difficulty indirectly represents the number of zeroes a the binary representation of a block hash must begin with to be considered a valid share.

The formula is :
Number of zeros necessary = 32 + log2(difficulty).

So a diff1 share begins with: 0000 0000 0000 0000 0000 0000 0000 0000 XXXX XXXX....

A diff2 share adds one 0: 0000 0000 0000 0000 0000 0000 0000 0000 0XXX XXXX....
Since it cuts in half the number of valid shares, the "difficulty" of finding a valid share is doubled.

A diff4 share adds another 0:  0000 0000 0000 0000 0000 0000 0000 0000 00XX XXXX....
The number of valid share is again cut in half, so the amount of work necessary to finding a valid share, relative to a diff1 share, is 4 times.

You can see, then, how and why the difficulty is constrained to powers of two. Furthermore, putting a non-power of two in the above formula would result in a non-integer amount of zeros necessary, which is impossible.

At the protocol level, the most meaningful value is the number of 0s, but difficulty is more useful and meaningful reprensentation for us humans, since we are mostly interested in the amount of work we'll need to do, and not what a correct answer looks like.

Your joy was before the current round, hmmm? :-p

I think you have that backwards?

256 would be about 4x as fast as 1024.

M

I do appreciate you taking the time to explain this.
I kept assuming because my units can do 1024 very quick on majority of pools that I was some how missing out on shares/work done by doing smaller shares at a more "aggressive" rate. I'll be quite honest, I see them buzz through 1024 so when I seen the speed of 256 it just felt as if it was slowed down. Maybe just my perception.

Thank you for explaining I will continue to give a run on your pool. You have very good feedback and people backing you up.

Let's find blocks now!

i've also noticed does the diff rate only go like 256 512 1024? so there is no middle ground? like 720?

The pool targets each worker submitting 16 shares per minute, or one every ~4 seconds.  Whatever difficulty it takes to do this at your hash rate (higher difficulty, less shares/min) the pool tries to use.  Higher target difficulty shares are worth more, but found less frequently.  Likewise lower target difficulty shares are found more often, but worth proportionally less. (I specifically say target difficulty because the achieved difficulty is meaningless.)

This is to make sure you submit enough shares to make stats usable and at the same time limit the amount needed to send to the pool.  16 shares per minute is pretty aggressive.  Some people want far fewer shares/min (higher difficulty) for some reason, which makes no sense and just adds unnecessary variance.

With the pool setting the difficulty appropriately, the pool can determine what works best for the pool load, also.

9 seconds for a block. Hooray!