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

[baddw]

ya i was wondering that...if lets say i split my hashrate with eligius, guild, slush, i guess ghash.io and maybe a cpl more...would that take luck outta the question? usually seems like when a pool luck is down its gotta be up somewhere else

Mining on multiple pools will make luck much less of an issue: https://bitcointalk.org/index.php?topic=78031.0

@organofcorti - If you get a chance, there seems to be a paper that is trying to say that a block withholding attack is somehow * more profitable * for the attacker than legitimate mining... (someone linked to it a page or so ago in this thread)

I skimmed it and, honestly, was not able to come to that conclusion from what they described.  I personally (and presumably others) would value your opinion a lot more on the topic, however, if you ever get around to checking it out.

The paper's fatal flaw was assuming that one miner's luck affected the other miners' luck, so if one pool had bad luck, the other participants in the network would have better luck to compensate.  The "profit" conclusion (expressed in a nice little formula) hinged entirely on this false assumption.

https://bitcointalk.org/index.php?topic=441465.msg7712963#msg7712963

baddw, I agree the paper has a number of conceptual and real-world inaccuracies, and as it stands I'd agree that it's wrong.

However, unless I'm completely off-base, I'd always thought it was trivial to show that a substantially sized block-withholding attack on one section of the network would increase the proportion of the network attributable to the attacking group, and therefore solve more blocks than expected before the next retarget.

This gets into "pool hashrate" versus "network hashrate" distinctions.  (Which is another blind spot in the paper.) A pool will know its hashrate quite well, because pool miners are submitting low-difficulty shares constantly, and although there is minor variance, there are a huge number of low-difficulty shares to base its hashrate estimate off of.  The network on the whole, however, does not know about the trillions of low-difficulty shares generated by miners, but only valid blocks which meet the full difficulty requirement.  The overall network hashrate therefore is much harder to estimate, and much less accurate.

Let's say that the network hashrate is 1000 GH/s (simplify to 1000G for readability).  And let's say that there is a large pool, it has 30% of the network hashrate or 300G.  The other 70% (700G) can be considered monolithic.  An attacker starts mining with the pool, and withholds all found blocks.  This attacker has 100G, which technically adds 10% to the network hashrate.  So the pool now thinks that it has 400G.  But since the attacker is withholding all found blocks, this 100G is effectively wasted in the eyes of the network on the whole, and the network still thinks that it is mining at 1000G instead of 1100G.  The pool will realize that something is up: that it is commanding 400G but is only earning blocks at a rate expected of 300G.  But the network on the whole has no way of knowing that the pool has been accepting shares at a rate of 400G while effectively representing to the outside world that it is hashing at 300G.

So the pool will continue to find blocks at the rate of 30% of found blocks.  The rest of the network will continue to find 70% of blocks.  The 100G is essentially "phantom hashrate" as far as the network is concerned.  They are a deadweight on the pool, and the pool will perceive its luck to drop to 75%, but all other miners (the honest 300G in the pool, and the honest 700G outside the pool) will continue to find blocks at the same rate as before.  If the 700G outside the pool somehow knew about the attacker's 100G inside the pool, then maybe they would naïvely consider themselves lucky because they are earning 7/10 blocks when they should have only been earning 7/11 blocks (although they are not really lucky because the blocks will be coming slower overall, and the 700G will be generating blocks at the same rate regardless).  However, the network as a whole cannot concern itself with knowing the inner workings of pools (nor indeed the true hashrate of other miners within the 70%), but must estimate pools' hashrate based on the number of found blocks.  So again, the network as a whole would consider the pool to have 300G and leave it at that.

Now let's consider the scenario that the paper devises.  In this scenario, all mining takes place in pools which are able to be attacked and which pay miners "in proportion to their contribution" (bad assumption, but we'll take it for now).  We will also ignore difficulty adjustment (since the paper ignores it) and assume a set block difficulty for all time.  The attacker has 200G out of a 1000G network, for 20% of the hashrate.  First let's consider what would happen if the attacker simply solo-mined.  They would earn 20% of all blocks, and the network would produce blocks at a rate associated with 1000G.  (Let's say that it's 1 block every 10 minutes, on average, as designed.)

Now let's say that they implement the attack proposed in the paper.  Instead of solo-mining with 200G, the attacker uses 100G to infiltrate pools, and 100G to solo-mine.  The 100G in the pools means that the pools think that they have 900G in total, but with the 100G withholding blocks, they only hash at an network-effective 800G.  The attacker's 100G solo-mining therefore represents 1/9th of the network and mines 1/9th of the blocks.  The pools effectively represent 8/9ths of the network and therefore mine 8/9ths of the blocks.  The 100G in the pool represents 1/8th of the pools' effective network hashrate, BUT it only represents 1/9th of the pools' known POOL hashrate.  Therefore the attacker will only be paid 1/9th of the pools' earnings.  Since the pools earn 8/9ths of the blocks, the attacker's 100G will earn 1/9th of that which is 8/81.

Now you say, "Aha!  I've got you now, baddw!  1/9 + 8/81 = 17/81 = .20987 which is almost 5% greater than 20%!!  The attacker has increased his earnings by 5%!"  But the one thing that I left out of the above is that the network is now hashing at an effective rate of 800G (infiltrated pools) + 100G (solo mining attacker) = 900G.  So the blocks are coming 10% slower, i.e. instead of averaging every 10 minutes, they are now coming at the average rate of every 11 minutes (or would it be 11.11 minutes?  I'll go with 11 just to be conservative).  In the 200G solo mining scenario, the blocks came every 10 minutes = 6 blocks per hour = 144 blocks per day.  The 200G solo miner could expect to earn 28.8 blocks daily.  Now if the blocks come every 11 minutes, the network is finding 130.9 blocks per day.  130.9 * 17/81 = 27.47 blocks per day.  So the attacker's income is actually decreased under the 100G block withholding scenario.  The attacker earns a greater percentage of blocks, but the rate of block production drops to compensate.

Of course, this discussion (as in the paper) ignored difficulty retargeting, which as we all know is a huge consideration for miners' profitability.  As far as delayed difficulty retargeting goes; I discussed this in my follow-up https://bitcointalk.org/index.php?topic=441465.msg7737259#msg7737259.  The attacker will benefit from the additional time to retarget (additional shares submitted at the lower difficulty level = higher value per share), but only to the extent of the difference between the Current Difficulty and the Retargeted Difficulty, and only for the time period of the delay (a few hours, max?).  The attacker also stands to benefit from the lesser difficulty increase when the retarget does occur.  However, even the combined effect there would be much more subtle than the paper presents. The paper doesn't consider difficulty retargeting at all.  And, unless I'm mistaken, in order to maximize these effects, the attacker would be better served by using ALL of their hashrate to execute block withholding attacks, and not solo-mine at all.  Far from the paper's conclusion that it is "optimal" to split the hashrate 50/50.

[RoadStress]

I've still never seen any math where a withholding attack doesn't cost you more than it provides.  If you have 10 PH/s, the network is 100 PH/s (including you), and you do a withholding attack on a pool with 20 PH/s.  Okay, so now you have effectively removed your 10 PH/s from the network, so the difficulty won't reflect your speed.  However, in the course of doing that (effectively reducing the next difficulty by 10%) you're taking a HUGE cut in your pay.  You'd be earning 33% less than expectation (you would be 1/3rd of that originally 20 PH/s pool, and by withholding that pool will under-perform by 33%).

I've played with the numbers endlessly, and the result is always the same.  You cannot perform a withholding attack where you end up earning more are higher than they would be if you were legitimately mining at 100% capacity.  It's the simple fact that you can not make the network difficulty be adjusted by more than the pay cut you're taking by performing the attack.

Now, this obviously only applies to non-PPS pools.  With PPS it's completely viable to do withholding attacks because your earnings hit is only the pool fee whether you are solving blocks or not.  Your only problem there is making sure you are able to continue pulling your balance out before the pool goes bankrupt.

There might not be a direct gain from this, but there might be an indirect gain as baddw suggested below. It seems logical to sacrifice X PH/s just to gain something in the medium/long term

The only impact that such an attack would have is to try to ruin the pool, or to earn BTC without impacting the difficulty.  (Which, granted, could be goals of an attacker.)  But the attacker could not *gain* anything by such an attack.  Their 10% would earn just as much BTC by solo mining as they get in the pool; and the other 10% would not earn any more or less.

[vittorio88]

Hello Everybody!

Mining n00b here!

I just bought an Bitmain Tech Antminer S2, and after having the factory PSU throw sparks that sounded like gunshots and stink up my house like an electronics factory burning down; I successfully replaced it with an Enermax Platimax 1350W and am back online.

I successfully configured Slush's Pool to verify the functionality, and am trying to switch to Eligius.

After roughly 12 hours of mining on the stratum server, and 5 hours of mining on the GBT server, I have not seen updates in the Stats server.

I would love to say, "It's not you, it's me", and keep troubleshooting on my end, but I'm afraid I'm throwing away BTC. (or at least throwing them at the pool instead of my own wallet)

Thanks everybody,
Vittorio

Hi,
can you send screenshot of your settings for Eligius?

https://dl.dropboxusercontent.com/u/13943233/Cattura.JPG

Hi!

I hope the previous image is sufficient, please let me know otherwise.

Thanks,
Vittorio


PS: How long does it normally take for stats to post for a new miner?
PS2: Wallet address for pastiness: 3HMiKMkBCBeEoP5ik4u3mBzckKfBYsru1B

Um... I thought all BTC addresses start with a 1... Why is yours starting with a 3...?

Edit: well I guess it is a valid address since I can find it in blockchain... Learn something new every day...

Those are multi-sig addresses.  I think they are a good idea for a payout address for a consortium.
At this point, I would add a 3rd address to a 1prefix, and I would run the miner as load balanced.  I would point it to the same address as the 2nd miner.  I don't recognize the 1st http address, so naturally I suspect it.

After it has run a while, I would check all payout addresses.  If the 1address shows statistics and the 3address does not I would send a message in to wizkid and Luke to see if that is intentional behavior.

Good catch! Thanks! Another address worked perfectly, and I was listed in the stats page in around 5 minutes.

Mining payouts to multisig addresses are not officially supported (yet).  They're currently treated as invalid due to some incomplete code which needs to be finished in order to properly handle them.  Unfortunately it hasn't been a priority and no one has really requested this either.

Thanks Wizkid057, and thanks for the service!

This address is one provided by Green Address, these are apparently multisig.
It worked well with a Blockchain address.

-Vittorio

[organofcorti]

baddw, I agree the paper has a number of conceptual and real-world inaccuracies, and as it stands I'd agree that it's wrong.

However, unless I'm completely off-base, I'd always thought it was trivial to show that a substantially sized block-withholding attack on one section of the network would increase the proportion of the network attributable to the attacking group, and therefore solve more blocks than expected before the next retarget.

I've still never seen any math where a withholding attack doesn't cost you more than it provides.  If you have 10 PH/s, the network is 100 PH/s (including you), and you do a withholding attack on a pool with 20 PH/s.  Okay, so now you have effectively removed your 10 PH/s from the network, so the difficulty won't reflect your speed.  However, in the course of doing that (effectively reducing the next difficulty by 10%) you're taking a HUGE cut in your pay.  You'd be earning 33% less than expectation (you would be 1/3rd of that originally 20 PH/s pool, and by withholding that pool will under-perform by 33%).

I've played with the numbers endlessly, and the result is always the same.  You cannot perform a withholding attack where you end up earning more are higher than they would be if you were legitimately mining at 100% capacity.  It's the simple fact that you can not make the network difficulty be adjusted by more than the pay cut you're taking by performing the attack.

Now, this obviously only applies to non-PPS pools.  With PPS it's completely viable to do withholding attacks because your earnings hit is only the pool fee whether you are solving blocks or not.  Your only problem there is making sure you are able to continue pulling your balance out before the pool goes bankrupt.

I wasn't saying that the attack would be profitable for the attackers, just that the attacked portion of the network (including the actual withholders) would solve fewer blocks than expected and the attacking portion of the network (everyone not being attacked by the block withholders) will solve more blocks than expected until retarget, since the effect of block withholding would be to reduce the estimated hashrate for a significant portion of the network.

However, the only winners are entities / pools that that are a) not attacked and b) not involved in any withholding attacks. I think I could show that being a by-stander would be the only profitable position in the 'game'. I don't think the attackers would earn more than expected per block.

[Bitskint]

Having been watching the last round that has just taken about 8 hours to complete,
I expected the pool hash rate to fall slightly.
Hovers around the 6,850 Th normally.
But before it had finished the hash rate has steadily rose to 7,300+

Who is moving those TH's and for what purpose ?

I know we will be back down to the 6,850 Th mark again sometime today.

[jcumins]

HMMM wonder who has 500Th worth of hashing power that is jumping around, thats a munch of small users or some one with allot of power masking who they really are with multi wallet id's.

This could be a issue or could be not.  If they are making $$$$ at that power why move around.  Makes no since to me. 

Makes one think something fishy is going on.

WizKid whats your thoughts?

[un_ordinateur]

Say the pool shuts down tomorrow (not saying it will but bear with me.)  What happens to all the miners who have a balance on their account?  Obviously new blocks won't be mined so we can't be paid out the traditional way.  Do you have enough BTC in cold storage to pay everyone off?  Right now there's a staggering 571.77 BTC in the payout queue and that's not even counting the miners who haven't hit their minimum.  Furthermore, how does the cold storage wallet get paid?  Do you send off a percentage of each new block to it?  Or is it only credited when the payout system goes into "fallback" mode?

This just confuses me because the point of the CPPSRB system is that there will never be more BTC in shares credited than what the pool actually mines.  Yet it seems the "debt" in the payout queue continues to grow and we're at the mercy of the miners tomorrow to pay off what we mined yesterday.

First, to clarify, shelved shares are not "owed" to you. They represent work you did that the pool has not yet found money to pay for yet. By the CPPSRB rules, theses are "worth" nothing until the pool finds enough blocks, if it ever does.

However, rewarded-but-unpayed shares (your account balance that grows until you hit your treshold then you get payed) is indeed owed to you; and if the pool were to close down, it must have enough money on hand to pay for them for all their miners.


Right now, the cold storage address has 777.68 BTC, and the payout queue is 652.41 BTC long. So Eligius has more that enough money to cover the queue. The remaining 125.27 BTC would then cover those who were rewarded BTC but have not yet hit their treshold. (However, I do not know how to check it these amount equals, but it does seem a reasonable value.)

So, no need to worry.


The cold storage address is 18d3HV2bm94UyY4a9DrPfoZ17sXuiDQq2B. It is mainly funded in the following conditions:
- The pool is in failsafe mode.
- The total amount of BTC in the queue is less that a block's worth. (i.e., not enough miners are above their treshold)
- Two blocks are found so fast by Eligius that it had not enough time to properly compute who gets what amount.

In usual condition, the miners are payed directly from the generation transaction, so the queue length does not grow. (it will of course vary a little bit according to the different miner's threshold, but it averages out over a sufficient long time)

When one of the above condition is met, since miners were not payed by the block, the queue grows, and fast. But, that money will be sent, manually, some time later.


The cold storage address is also sent 0.00000001 BTC each time Eligius finds a block. It can be used to quickly check directly on the blockchain if Eligius has found a block even if the pool's webserver is down.

[soapmodem]

Hello Everybody!

Mining n00b here!

I just bought an Bitmain Tech Antminer S2, and after having the factory PSU throw sparks that sounded like gunshots and stink up my house like an electronics factory burning down; I successfully replaced it with an Enermax Platimax 1350W and am back online.

I successfully configured Slush's Pool to verify the functionality, and am trying to switch to Eligius.

After roughly 12 hours of mining on the stratum server, and 5 hours of mining on the GBT server, I have not seen updates in the Stats server.

I would love to say, "It's not you, it's me", and keep troubleshooting on my end, but I'm afraid I'm throwing away BTC. (or at least throwing them at the pool instead of my own wallet)

Thanks everybody,
Vittorio

Out of simple curiosity, why do you prefer GBT to stratum server(s)?

[bgibso01]

So I'm back up to 6 days waiting payout.  I quality for one after about 6hrs of mining.  Is everyone else having this issue, or am I just 'lucky'?

[wizkid057]

So I'm back up to 6 days waiting payout.  I quality for one after about 6hrs of mining.

Payout queue is a little long, but I'll clear it out soon with a manual payout.

Sounds like you need to set a higher minimum payout anyway.  You'll pretty much never actually get a payout every 6 hours.  You should set it to at least a full day of earnings.

[rkinnin]

So I'm back up to 6 days waiting payout.  I quality for one after about 6hrs of mining.

Payout queue is a little long, but I'll clear it out soon with a manual payout.

Sounds like you need to set a higher minimum payout anyway.  You'll pretty much never actually get a payout every 6 hours.  You should set it to at least a full day of earnings.

The simple fact of the matter is that I would like to be paid out at the amount I select or within very close proximity.  For instance if I have selected .1 BTC.  I shouldn't have to wait until its .15 or even .235 to finally get paid. 

[crashoveride54902]

So I'm back up to 6 days waiting payout.  I quality for one after about 6hrs of mining.

Payout queue is a little long, but I'll clear it out soon with a manual payout.

Sounds like you need to set a higher minimum payout anyway.  You'll pretty much never actually get a payout every 6 hours.  You should set it to at least a full day of earnings.

The simple fact of the matter is that I would like to be paid out at the amount I select or within very close proximity.  For instance if I have selected .1 BTC.  I shouldn't have to wait until its .15 or even .235 to finally get paid.  

then either this is not the pool for you or set your payout for a weeks worth or more of mining...then you'll hop to the front of the queue everytime and not have to wait

i have mine on .25 which is a day n half mining...but i don't care how long it takes to payout...hehe i like getting .91btc all at once too i know my btc is safe which is what matters to me

[bgibso01]

So I'm back up to 6 days waiting payout.  I quality for one after about 6hrs of mining.

Payout queue is a little long, but I'll clear it out soon with a manual payout.

Sounds like you need to set a higher minimum payout anyway.  You'll pretty much never actually get a payout every 6 hours.  You should set it to at least a full day of earnings.

The simple fact of the matter is that I would like to be paid out at the amount I select or within very close proximity.  For instance if I have selected .1 BTC.  I shouldn't have to wait until its .15 or even .235 to finally get paid.  

then either this is not the pool for you or set your payout for a weeks worth or more of mining...then you'll hop to the front of the queue everytime and not have to wait

i have mine on .25 which is a day n half mining...but i don't care how long it takes to payout...hehe i like getting .91btc all at once too i know my btc is safe which is what matters to me

So does it really matter to set the payout higher?  I normally don't see a payout until .4-.8.  This coming one will be around 1.0.  If I had set the rate at .25, would I have already seen a payout, or just still accumulating waiting on enough blocks found to payout?

[proclivity]

So does it really matter to set the payout higher?  I normally don't see a payout until .4-.8.  This coming one will be around 1.0.  If I had set the rate at .25, would I have already seen a payout, or just still accumulating waiting on enough blocks found to payout?

Yes and no. The longer the queue, the longer everyone will wait. The higher your minimum payout, the longer you will wait.

wizkid performs a manual payout when the queue gets this large, so you can expect things to normalize pretty soon.

[PlanetCrypto]

So I think I got this payout queue threshold thingy wrong.

Would like some recommendations given the following:
Hashing @ 2.2 - 2.3 TH/s
Would like to be paid every 2 - 3 days.

Thanks in advance from a noob.

[baddw]

So I think I got this payout queue threshold thingy wrong.

Would like some recommendations given the following:
Hashing @ 2.2 - 2.3 TH/s
Would like to be paid every 2 - 3 days.

Thanks in advance from a noob.

See link in my sig for payout threshold explanation.  TLDR version: the higher you set your threshold, the sooner you will likely be paid once you hit it.  If your threshold is low (1 day's worth or less) then you could easily see a 2-3 day variance in payouts.

[KNK]

Would like some recommendations given the following:
Hashing @ 2.2 - 2.3 TH/s
Would like to be paid every 2 - 3 days.

Make that a week and set your threshold to 0.5 BTC

[bitspender]

My payout is set at 0.5BTC. Yet my reward is already in the 4BTC region, and still 8 block delay according to stats.
Need the coins to pay the bills, i dont have a whole week to wait for a payout

[un_ordinateur]

You can go check on the payout queue page. (http://eligius.st/~wizkid057/newstats/payoutqueue.php) A good rule of thumb is that you will never receive two payout faster than the "age" of the last payment in the first block of the queue. AND THAT, REGARDLESS OF YOUR THRESHOLD.

If your theshold is set such that you cross it at longer intervals than the queue time, you will be immediately payed when you cross it. If you cross your treshold at a shorter interval that the queue time, your threshold essentially does nothing (it might as well be 0), and your payout interval will be entirely dependent of the fluctuations of the queue.

The last payment of the first block, at the time of writing this, is 1 week, 6 hours and 29 minutes old. People who have received their last payment earlier than 1 week, 6 hours and 29 minutes ago will have to wait longer before their payout.

A queue longer that a week is a bit long I admit, usually it is more around 3-4 days, but it is not unheard of. However, wizkid has stated earlier in this thread that he will do a manual payout soon, which should help shrink the queue.

[crashoveride54902]

My payout is set at 0.5BTC. Yet my reward is already in the 4BTC region, and still 8 block delay according to stats.
Need the coins to pay the bills, i dont have a whole week to wait for a payout

like i said...either make it way higher n jump to the front of the queue when payout is due or accept that it could be delayed...