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

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://bitcointalksearch.org/topic/m.7737259.  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.

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.

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.

Correct.  The current system will have eternally shelved shares (most likely) since the expected luck is 98-99% due to orphans.  Luck can pay off some shelved shares, but it's extremely unlikely it will ever pay them all.  The problem with paying oldest first is that it penalizes newer miners, which discourages pool growth, and instead of having very old shares that will never get paid, its the newest shelved shares that will never get paid.

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://bitcointalksearch.org/topic/m.7712963

They have indeed evaluated this.  Eligius used to use SMPPS which is very similar to the current system but with oldest backpay.  If I understand it right, the only difference with SMPPS was instead of the logic with "shelving shares" it paid out every share but upon bad luck reduced the amount paid per share proportionally.  Upon good luck, these underpaid shares got paid back "extra credit" (in the order of oldest first) until every share gets paid the full PPS amount.

This system sounds OK in theory but the problem is that luck does not even out to 100%.  According to Eligius's stats, the luck for the entire duration of the pool evens out to about 98%.  This is due in a big part to orphaned blocks (and maybe a small part due to some miners withholding blocks.)  In any case, this means if you backpay the oldest shares first over time the backlog will grow faster than the pool can pay it off.  Eventually the pool will end up in a situation where the backlog reaches a very undesirable length for new miners.  Say it gets to the point where it takes 3 months to pay back everything in the backlog.  If you're a new miner this means you won't see any benefit from lucky blocks for 3 whole months until your first shelved shares reach the front of the queue.  Also the people mining 3 months ago may no longer be contributing to the pool (and if it's been that long who knows if they even still control the payout address.)  A lot of people thought it unfair that current miners were using their hashpower to pay people no longer contributing.  The current miners are also depending on the pool still mining 3 months down the road in order to receive any of their backpay. (if the backlog gets that bad it's likely the miners will abandon or the pool with switch payment methods like Eligius did.)

Another way to think about it is that oldest backpay is unfair because it benefits the people who mine on the pool when it first opens (and eventually punishes new miners as the backlog grows.)  This is because there is no backlog initially so chances are good that all your shares will be paid out 100% making it effectively a 0% fee straight PPS pool (with your backpays being only slightly delayed.)  This low/no backlog state can also occur later if the pool gets some very good luck (likely while the pool is still relatively new since, given time, the backlog will inevitably grow faster than it can be paid off) and this encourages pool hopping.  If someone sees the pool has a low/no backlog they can benefit themselves by hopping on it while the chances are good that they'll get all their shares paid 100% in a timely matter.

In any case, when a pool with oldest backpay shuts down or changes payment systems (which will likely happen to any such pool when the backlog inevitably reaches unacceptable levels) the end result will be the same:  the original miners and the pool hoppers who mined when the backlog was low and then bailed when the backlog grew will get all their shares paid 100% while the new miners may never get any of their backpay.

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

Mining on multiple pools will make luck much less of an issue: https://bitcointalksearch.org/topic/mine-in-multiple-pools-to-reduce-variance-78031

Luck isn't a zero-sum game.  The entire network can be having bad or good luck simultaneously.  That's why any graphs which try to show the network hash rate have massive fluctuations from day to day.  People are NOT turning equipment on/off at random, it's simply the network getting lucky/unlucky as a whole.

EDIT:  I didn't mean to imply that splitting hash rate will not reduce the impact of luck.  Just that the concept of "luck has to go somewhere" is false.

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

You could SSH into your Antminer and modify its cgminer settings directly to enable load-balancing and thus split the hashing power among multiple pools if you want. A quick search in this forum should yield the post with the steps on how to do that.

Was just saying what I would have gotten if I had 20% of the network hash rate worth of my own mining equipment... I didn't actually get a Tesla Model S P85+...

...... I did get a blue Tesla Model S P85, though.  Nothing to do with Bitcoin, however. I had invested in TSLA back when it was ~$39 (500 shares)... it shot to ~$260, so I sold some of it and my Volt then bought the Model S.  Took delivery from showroom stock, so, I kind of cheated the wait I guess.

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.

I never understood the pool-hopping business.  Would you (anyone) mind working up an example with a 10% oldest / 90% recent?  Perhaps use the actual Eligius block data for a new 1 THs miner starting at block 308,729?

You can split your power into multiple pools.  I ran an Avalon with 2 payout addresses on Eligius to simplify some accounting. 
You have to use load balancing.  There are also some commands to specify the % load each receives, but I never did grok how to do that.

check load balancing strategy

Have you read my post some time ago?

Yes, it is possible, but it takes time (2+ months) to profit from it - to get the attacker and punish him for that is the 'antidote' for such attempts

Ok the reason why you can not mine 2 pools  at the same time.

Priority 0 will be the first place mined if it is running,

if it is not available it will drop to priority 1 pool if it is not available

it will drop to priority 2 pool. 

You can only mine 1 pool at a time.

Whether 100% oldest or 50% oldest, neither system works without including a fee. The reason is that as soon as a backlog develops, it is always more profitable to just move to another pool than to continue to mine there even if your shares are in the old backlog.