[emin-gun-sirer]

I'm one of the two authors of the selfish mining paper. Let me chime in on the selfish mining aspect of this generally insightful comment:

>The interesting question remains: what happens when some pools start to implement this strategy?

>I do not know for sure, but I suspect that the result will be a wash, so to speak, and most likely will end poorly for the cheaters (when they are caught). Their entire paper is based on the absurd claim that a single selfish pool will grow, like some sort of cancer, until it reaches 51% proportions (and then it's game over). While this is a possibility, at the moment it seems like an exceedingly remote one. In fact, the more cheating pools there are that use this strategy, the less likely their vision of a BTC doomsday becomes. Which group of bandits should one join, and is it worth the risk?

The revenue dynamics of selfish mining (SM) are such that two SM pools working independently are better off joining forces. The excess revenue for SM is super-linear in pool size. So, with X% of the mining power working selfishly, you make (X(1+eps))%, with Y% mining selfishly, I make (Y(1+iota))%, but if we combine forces, we make (X+Y)*(1+delta)%, where delta>eps+iota. So we not only get our normal winnings, but we win an additional reward for joining forces. And since there is nothing at the protocol level to break up large mining pools, there is an incentive for SM pools to get large and grow until the 50% point.

We deliberately deferred a game-theoretic analysis of selfish mining to a future paper, because such analyses tend to be highly dependent on modeling assumptions. E.g. would an attacker view reaching the >50% point as a complete failure event when all coin value drops down to 0, or as a complete success event? The answers on how to model this apocalypse depend on too many assumptions about the attacker, his motivation, and what others can detect about his power. A thorough job of modeling the game-theoretic dynamics of Bitcoin (with selfish mining) would indeed make an exciting follow-on paper.

[itistoday2]

Ah, thanks for that interesting analysis!

> if we combine forces, we make (X+Y)•(1+delta)%, where delta>eps+iota. So we not only get our normal winnings, but we win an additional reward for joining forces.

I'm not convinced that that matters. Let's say you're right and that your math is flawless (it's late, so I haven't verified it).

If there is just one cancerous pool growing, then doesn't that make the job of policing the network even easier? Have a look at Stephen's post on btctalk: https://bitcointalk.org/index.php?topic=324413.msg3478147#ms...

Using his method (or something similar) it would be rather obvious that something was fishy about the blocks this group was publishing. If it could be developed into a proof, then the entire selfish pool would be permabanned from the network, publicly tarred and feathered, etc. and there would be no problem.

Am I missing something? (If I am, don't jump too hard on me please, I'm about to head to sleep! :p)

[emin-gun-sirer]

The math seems to be correct and borne out by simulations, even independent simulations devised by people who did not believe that the selfish mining attack would work [1].

So Stephen's point is that there may be operational procedures that might allow one to detect selfish mining. This is great, as this is what we want is for Bitcoin to deploy in-protocol incentives to break up selfish miners. But there are two issues: (1) I'm not sure that his suggested tactic of judging by the latest timestamp would actually work well for established pools. I suspect that some pools are less eager to update their xaction sets, and therefore might lose to selfish miners, and (2) even if these operational measures worked perfectly, they would succeed in lowering gamma. But even with gamma at 0, selfish mining is still a win for groups of size 33% and above.

Hope this is useful.

[1] http://hackingdistributed.com/2013/11/17/selfish-mining-simu...

[itistoday2]

> (1) I'm not sure that his suggested tactic of judging by the latest timestamp would actually work well for established pools. I suspect that some pools are less eager to update their xaction sets, and therefore might lose to selfish miners

I don't see a reason as to why they would object, care to offer one? Plus, since you point out a threat that I think needs to be addressed (thanks btw!), this can be mandated in an updated protocol if the Bitcoin (or Namecoin) devs feel similarly.

> (2) even if these operational measures worked perfectly, they would succeed in lowering gamma. But even with gamma at 0, selfish mining is still a win for groups of size 33% and above.

Here I think you misunderstand. The implications of my comment were not simply that gamma is reduced to zero, but that the whole problem is thrown out the window because the entire pool would be banned from the network (blacklisted). Their selfish blocks would no longer be accepted by the network, and the implications could be even stronger than that (transactions, connections, etc. could also be rejected).

[emin-gun-sirer]

>The implications of my comment were not simply that gamma is reduced to zero, but that the whole problem is thrown out the window because the entire pool would be banned from the network (blacklisted).

Ah, but even if detection worked perfectly (and did have a false positive rate of 0), who precisely do you blacklist? The Bitcoin wallet? It's trivial to generate more. The IP address? Which precise IP address? Even if you could locate the IP address of the submitting node accurately, a pool has many, and it's possible to get more.

[itistoday2]

Definitely was not implying the wallet, but more along the lines of an IP. Your raise a good point though, that IP addresses might not carry sufficient weight/reliability.

I must focus on other things now, but I want to thank you for bringing this problem to the attention of the bitcoin community, even if they have chosen to ignore it and pretend that it's a non-issue.

I look forward to reading your followup paper (if and when you publish it). I hope you'll have a good solution in it.

(My brain is tempted to consider some using sort of stronger identity system than IP addresses [like Namecoin], but I really don't like that. That could potentially cause far more severe problems, especially if done incorrectly. And it seems like a hack.)

[itistoday2]

FYI I sent an email to the btc sec list with some recommendations on this issue and a link to this discussion. I hope they will act.

[itistoday2]

On #bitcoin-dev, the BTC developers consider this problem to be a non-issue because they think it is easily detected simply by the number of orphaned blocks.

No one on the IRC channel explained how this problem would be handled once it is detected. They refused to engage in such discussion, except to say that they wouldn't use Stephen's solution because it could introduce other problems. The current response has been an almost resounding, "We're going to stick our head in the sand and ignore it." (And then downvote you on HN for bringing it up and attempting to discuss it. :p)

Edit: Here is the full, unedited transcript of what went down on #bitcoin-dev (in RTF doc format): http://jmp.sh/v/sTXe0VvyTW7pM3WgOGkT

[nullc]

Perhaps you're being down-voted because this thread has drifted off-topic.

Sorry, this subject matter has been discussed and debated at great length in a dozen places. No one has the time to hand-hold each and every person who learns about it and freaks out, especially if they come off as demanding and abrasive rather than inquisitive and helpful.

Saying that it is considered a non-issue would be a misrepresentation. It exists as part of a large collection of things which are potentially concerning but which are not currently problematic. Your proposed urgent deployment of "fixes" carries enormous risk and so it absolutely will not be done. So far as I've seen none of the proposed "fixes" are compromise free and many carry new, subtle, and difficult to analyze risks which may have far greater practical implications than the problem they claim to solve.

From a more practical perspective, action has been taken to improve network connectivity so that achieving alpha much greater than zero should be impossible in practice, and do the extent thats successful then there is only an issue with >33% consolidations— which are already problematic for other reasons (e.g. they can reverse six confirms with a 20% success rate).

Your specific concerns seemed to be mostly related to mining pools engaging in this activity without the consent of their hashers, this particular threat is eliminated completely by hashers that use GBT and submit blocks themselves— as you were pointed to.

In any case, in the future when you find yourself sending demands to volunteer developers asking them when they will solve your pet concern you should first ask yourself when _you_ plan on solving it.