Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB

[un_ordinateur]

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

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.

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.

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.

[1714739164]

1714739164

[1714739164]

1714739164

[1714739164]

1714739164

[-ck]

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.

You have to get out more then.

[mdude77]

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.

This will be the big test of Bitcoin.  If we get a bunch of halvings, price doesn't increase significantly, and/or transaction fees don't increase, Bitcoin has a problem.

In other words, hang on tight.  It'll be a wild ride, and no one knows where it'll end.

M

[realproject]

sure this pool is 0% fee? how you get maintenance cost if your pool is free?  

[baddw]

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.

Thank you for posting this, I will link it in the post linked in my sig.

[xstr8guy]

sure this pool is 0% fee? how you get maintenance cost if your pool is free?  

Donations.

[RoadStress]

What exchange is the most popular for NMC?

[Biffa]

What exchange is the most popular for NMC?

Popular or highest prices?

Popular would be using ghash.io or vircurex.com for higher rate

Cryptsy is probably up there as well.

[baddw]

What exchange is the most popular for NMC?

According to Coinmarketcap.com, the highest volume Namecoin exchange is BTC-E by a longshot (29 BTC volume over the past 24h), then CEX.IO (2 BTC), Cryptsy (1 BTC), Kraken (.6 BTC), BTER (.5 BTC), Vircurex (.3 BTC).  Everything else is too low-volume to be worth your while.  Current prices all hover in the .0028 +/- .0001 BTC range.  I don't know if Namecoin has much bot action, but in general, arbitrageurs across the exchanges will keep prices to a pretty low spread.

http://coinmarketcap.com/currencies/volume/24-hour/#namecoin

[brox]

How possible that pool is getting donations from unused NMC when NMC are not working since march?

[baddw]

How possible that pool is getting donations from unused NMC when NMC are not working since march?

NMC was being mined continuously the whole time.  NMC payouts were delayed for a couple of months after the exploit occurred in March, but wizkid patched up the code and everybody got paid in full recently, maybe a month ago?  And NMC payouts happen regularly now, AFAIK.  At least nobody has asked about it recently.

[wizkid057]

NMC is working fine.

I seem to have broken automatic BTC payouts yesterday, though.  I'll do a manual payout to catch that up as soon as these blocks confirm.  Sorry about that.

[jgu1394]

NMC is working fine.

I seem to have broken automatic BTC payouts yesterday, though.  I'll do a manual payout to catch that up as soon as these blocks confirm.  Sorry about that.

when manual payout gonna hit ? thanks 

[un_ordinateur]

Ok, I may have answered a lot of questions on this forum, but I have one now.

It has been often said on this forum that because of the orphaned block, the pool payout to miners converges to about 97% PPS, instead of 100%.

Therefore, if blocks were -never- orphaned, the payout would converge to 100% PPS. However, it is my understanding that when a block is orphaned, the pool (and the Bitcoin Network) act as if that block had never existed.

Therefore, I do not see how it makes a difference to the payout value that some block are orphaned, since acting as if it had never existed, is the same as if no block was ever orphaned, no?

[frisco]

Ok, I may have answered a lot of questions on this forum, but I have one now.

It has been often said on this forum that because of the orphaned block, the pool payout to miners converges to about 97% PPS, instead of 100%.

Therefore, if blocks were -never- orphaned, the payout would converge to 100% PPS. However, it is my understanding that when a block is orphaned, the pool (and the Bitcoin Network) act as if that block had never existed.

Therefore, I do not see how it makes a difference to the payout value that some block are orphaned, since acting as if it had never existed, is the same as if no block was ever orphaned, no?

This pool is a PPS variation so it rewards (block reward / estimated # of shares per block) to every share, the estimated # of shares block, depends on the pool dificulty and the network difficulty but it does not takes into account the orphans.
So when a block found by the pool is orphaned the rewards of that block and the next one, should be the half of a normal block to avoid that 1-2% of global bad luck/shelved shares (in the case of double orphan it should be 1/3, etc.)

Anyway global variance seems to affect a lot more than the orphans, since April my account have been at least twice at 100% of rewarded shares even with the block withholding issue we had a couple of months ago and I am right now at 98.8% with this week bad luck.

[baddw]

Ok, I may have answered a lot of questions on this forum, but I have one now.

It has been often said on this forum that because of the orphaned block, the pool payout to miners converges to about 97% PPS, instead of 100%.

Therefore, if blocks were -never- orphaned, the payout would converge to 100% PPS. However, it is my understanding that when a block is orphaned, the pool (and the Bitcoin Network) act as if that block had never existed.

Therefore, I do not see how it makes a difference to the payout value that some block are orphaned, since acting as if it had never existed, is the same as if no block was ever orphaned, no?

The pool expects to find blocks at a given rate.  This is what the PPS payout rate is based on.  An orphaned block counts as a "found block" (per expectations of the rate of finding blocks) but the pool does not get the BTC for it.

[TheGreatWhatsIt]

I just wanted to say how awesome it is to have 8.5 Ph/s and no fail safe! How high do you think it can go? I have new hardware coming in, should increase my processing around 4x.

[wizkid057]

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'll just clarify here that in a manual payout the payout queue, *not counting potential earnings for the current round*, is generally paid completely (the "As of Last Block" balance value in the user stats).  Since the estimated earnings for the current round will obviously sum to 25 BTC, that is why when you see the payout queue it seems like one block was left unpaid, but those are just balances not yet rewarded/earned.

The payout queue/coinbase payout normally contains the exact earnings calculation for the moment a block is found (with a correction for the obvious delay in work->mining->block submission) so that miners in the top of the queue are already paid for the block that was just found immediately when it is found.  In a manual payout this is not possible, since it's not a block that is found and earning funds.  So, only the balances valid/earned as of the previous block are able to be paid.

[baddw]

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'll just clarify here that in a manual payout the payout queue, *not counting potential earnings for the current round*, is generally paid completely (the "As of Last Block" balance value in the user stats).  Since the estimated earnings for the current round will obviously sum to 25 BTC, that is why when you see the payout queue it seems like one block was left unpaid, but those are just balances not yet rewarded/earned.

How can balances not yet rewarded/earned show up in the payout queue?  Related, what if the payout queue is completely emptied out by a manual payout, and (due to vagaries of the queue and people not yet hitting their threshold) there are not yet enough users in the queue for payouts to total 25 BTC in the currently-being-mined block?  Is the remainder just sent to the cold wallet for future manual payouts?  Or will the pool just pay out accounts before they hit their thresholds?

The payout queue/coinbase payout normally contains the exact earnings calculation for the moment a block is found (with a correction for the obvious delay in work->mining->block submission) so that miners in the top of the queue are already paid for the block that was just found immediately when it is found.  In a manual payout this is not possible, since it's not a block that is found and earning funds.  So, only the balances valid/earned as of the previous block are able to be paid.

1) So manual payouts are just normal transactions pushed to the Bitcoin network?  I.e., they often end up in blocks that aren't mined by Eligius?  If so, it seems that it would be nice to just have that transaction included in the next Eligius-mined block so that the pool can keep the fees (equivalent to not paying fees).  Obviously this could lead to a delay in payments if there is a long round, but I think that most people would understand.

2) How often does Eligius push new block contents to miners?  If the exact payout amount is fully paid out and kept current (not just the "as of last block" amount) in every block, this would have to be pretty frequent..... several times a minute?  So if a miner successfully finds an "old" block (with "old" version of the coinbase transaction that has "old" balances), I suppose the new balance differentials are just kept in the user's account to be paid out the next time they enter the queue?

[crashoveride54902]

I just wanted to say how awesome it is to have 8.5 Ph/s and no fail safe! How high do you think it can go? I have new hardware coming in, should increase my processing around 4x.

welcome to the forum newb hehe i like yer name

I'm hoping it'll go alot higher...course with all this new HW coming to the pool it sure tanked out luck % thank god for avg.'s Ya i've added a few more th/s here and there to eligius praying for ROI each and everyday