5 ms·

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 wou

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-simulator/ http://hackingdistributed.com/2013/11/17/selfish-mining-simu...

itistoday2 13y ago
> (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).
- itistoday2 13y ago
  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 13y ago
    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 http://jmp.sh/v/sTXe0VvyTW7pM3WgOGkT
    - nullc 13y ago
      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.
- emin-gun-sirer 13y ago
  >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 13y ago
    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 13y ago

> (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).

itistoday2 13y ago
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 13y ago
  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 http://jmp.sh/v/sTXe0VvyTW7pM3WgOGkT
  - nullc 13y ago
    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.
emin-gun-sirer 13y ago
>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 13y ago
  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.)