6 ms·

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 w

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#msg3478147 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 13y ago
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 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.