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

[itistoday2]

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

It's a security issue related to bitcoin, which in turn is related to Namecoin, which in turn affects DNSNMC. Seems fairly on topic to me, but others are welcome to disagree (just explain why if you do).

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.

Sorry, I did not realize that I was coming off as demanding and abrasive. I can see how "demanding" might have been seen now, and I apologize for that. Abrasive though? I don't see that, I was just asking questions and for help understanding the BTC dev's thoughts on this.

Note that I also asked whether there was a document (perhaps on the bitcoin wiki) that had all the explanations on it already. The response was less than helpful.

Your proposed urgent deployment of "fixes" carries enormous risk and so it absolutely will not be done.

I think this was simply due to misunderstanding. It was never my intention that any one "fix" be adopted immediately. I was just looking for reassurance that something is being done about this, even if it's just the reassurance that the devs acknowledge the problem and are investigating methods of addressing it.

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.

And as was pointed shortly out by gmaxwell, that doesn't matter for those who choose not to. If it's a certainty (or highly probable) that the network will adopt GBT, and that somehow implies that the problem is fixed, then that could have simply been explained. Instead, I was kicked from the channel and then my posts here were downvoted out of spite.

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.

I'm sorry you perceived it as me "sending demands to volunteer developers". For any part of that that is true, I apologize. Like I said at the start of this reply, all I wanted to hear was that something is being done to address this problem, and if not, why not.

As for me solving it, I had pointed out a solution that I thought was helpful (Stephen's), but folks chose not to discuss that in any calm sort of way. I don't know why. Perhaps you may want to re-evaluate the way you (and others) reacted toward someone approaching the community with a concern and asking questions. I am not some type of thing for you to feel threatened by. My intentions were benevolent. I come in peace. ;)