From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CB59E13AF for ; Tue, 18 Sep 2018 20:26:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 17AFA7D5 for ; Tue, 18 Sep 2018 20:26:18 +0000 (UTC) Received: by mail-wr1-f53.google.com with SMTP id v90-v6so3490983wrc.0 for ; Tue, 18 Sep 2018 13:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=+easKDryOlR4AJF9SDFIPE6PM0y9sWptPanOpxSnlfY=; b=Vfa2lOQxavXSiqtNUNJIyuOuKFiMtaMR4EPK+vb88fC96Ntxdn6q4mz+Wxc7cNe5hI UrupRHZy5herxwMjY09HHJZqNI0OGiHsyOsUmBosj9PK5cGY9gOH4TH4MyGU1KTgAKoc U7D/7Heuci7rfxBYMjxNBXYVWzTa0nRmx2aCePxS6v7Yi93yP1Q+SjQQmPlKlqCrJz6J fbq/nyf/8rsnBo0viUNHOKD8TN5ub7tKlXLPtLJYcMoUbcXpGtRPWTS4J6Uu1riI2vpN sMUN/Mtd7bgOH/28z/REdp13H4eyncHIGoqfKj1tgktpxuYi1NzTtc7JZZIZBXJxTsA6 0ABg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=+easKDryOlR4AJF9SDFIPE6PM0y9sWptPanOpxSnlfY=; b=OmG6AzUbnckcCx/LOKQJooyli0AI8J8eoqYtU9ICYROIahKWOzfOIfW26PcgqtaJtF rPWjnut4UxPMnVL2uYqBX9qhPR8dD79fun9Fsun63n+RcbcNDoMQz1YjAn06tM5q3o/h 5qbZNJKSWL7ciw0l1tKLy+0ZtmGc43HGckI9vtdG3wtAo8PPdcONUi6gV1YxrAmg9i2p bD36KAXzufJVm+mqiNnNHJzIwx8Z+/Jy3RZV/Zoki0nCN4MmnVaBso/iZt/sWuQFGlJD o4gwr+qgXMVKjs0mBDQo/txBUypZVqFhofVhA5r2Vv5zGac85d3uFFclV2KndxlDMCte dITw== X-Gm-Message-State: APzg51C/EIDpl0rkWhNatdnhJ8o0mT3RVMAxmwBD9fMqfySSAXMYkwkF gNLcbI0EPkrf988n5+K+h3FpVscWFXEOmyxq3Zo= X-Google-Smtp-Source: ANB0VdaspanYzR5W991L2JrlmvB35TeNhU6MHqlYBSt8yGDzsr5sTE8vtxlbZEjQNtUr0aOL3h3U4Oqge4qzEsPhHo0= X-Received: by 2002:adf:ad47:: with SMTP id p65-v6mr25359376wrc.222.1537302377531; Tue, 18 Sep 2018 13:26:17 -0700 (PDT) MIME-Version: 1.0 Sender: akaramaoun@gmail.com Received: by 2002:a1c:e1c4:0:0:0:0:0 with HTTP; Tue, 18 Sep 2018 13:26:16 -0700 (PDT) In-Reply-To: References: From: Andrew Date: Tue, 18 Sep 2018 20:26:16 +0000 X-Google-Sender-Auth: fFwcgp3JSDH5i8X6Rg9r6GBtfVw Message-ID: To: Zawy , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 19 Sep 2018 13:18:31 +0000 Subject: Re: [bitcoin-dev] Selfish Mining Prevention X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2018 20:26:19 -0000 @ Eric: Yes I forgot to mention that cost (in addition to price) also determines the profitability of mining and thus the total hashpower. I disagree with your assessment of merge mining as really what matters is opportunity cost of honestly mining vs attacking, and one reason we are currently safe from other networks attacking is that SHA256 is ASIC friendly and currently the main network utilising this (the ASICs) is Bitcoin mining. It would be hard for people computing prime numbers to quickly switch to Bitcoin mining, since they would need the ASICs. But if you really want to discuss this then I suggest opening a new thread here or bitcointalk since this is off-topic from my thread. Also there is a discussion about merge mining here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/003981.html On Mon, Sep 17, 2018 at 2:09 PM, Zawy via bitcoin-dev wrote: > The 51% problem is deep. Any discussion of a solution to it should > begin with a link to an article that shows a profound discovery has > been made. Selfish mining prevention and pollution should be on > bitcoin-discussion, but it appears that list is not active. > > The problem with Andrew's idea below is that it is a positive feedback > loop that amplifies oscillations. If h goes up or down due to price > changes or random solvetime variation, then the net reward goes in the > same direction, which motivates miners to cause h to go even further > in the same direction, which is a positive feedback loop until some > limit is reached. To make matters worse, miner profit motivation in > choosing which coin to mine is a non-linear function: a 30% drop in > difficulty (or 30% increase in this reward function) in an alt coin > can cause a 300% increase in hashrate. > > Average of 144 past blocks to determine h are needed so that it does > not vary too much. A selfish mine of 72 blocks would result in only a > 12.5% loss compared to not using this pro-oscillation function. I've > tried similar reward functions in trying to reduce on-off mining. > > There may also be a problem of issuing too many or too few coins, > depending on how fast h rises in the long term. > > An alternative is to increase difficulty with this or a similar > function instead of reward. From a miner's perspective, there is not a > difference (they are only interested in the (price+fees)/difficulty > ratio. This would have the same problems. @Zawy: Are you talking about my proposal to modulate the subsidies? Because if you read my second post you see that I scrapped that part as it can be disruptive, and I am only proposing to let users have more control over how their fees are spent. A certain portion of fees is put in reserve and gets allocated to miners based on hashrate conditions, and once the "contract" expires, the remaining part goes back to the user for future fee payments. I understand it is unclear whether this will cause a significant benefit (I can work on simulations if I have time), but what could possibly go wrong with giving users more choice over how their fees are spent? Also if you see my post, I am not just trying to prevent Selfish Mining (33%) or 51% attacks, but in general any types of attacks that try to drive away mining competition (like block withholding attacks, networking attacks, etc). Someone on bitcointalk was also worried about a positive feedback loop, and I think my answer remains valid: "First, I think a price drop will be slightly offset by the lower rate of coins being mined. Also, confirmation times will get longer: Both the time to get a block will increase and the number of confirmations needed to have enough work done on the chain so that your transaction is considered safe. The fees would likely rise and this would increase rewards to miners, especially in a fee-market dominated future." Merge mining can also help to smooth hashrate so it doesn't depend so much on price, but even without merge mining it is not so clear that a there would be a destructive feedback loop and that's where simulations / math equations would help. Your idea of increasing difficulty, I haven't thought about much, but I don't think it's the same effect. When you increase the difficulty, the reward per block remains the same, only reward per real time falls, but it could also have the negative effect of incentivizing selfish mining or timestamp attacks to reverse the increased difficulty. Though actually timestamp attacks would sort of be dis-incentivized if underestimates of hashrate led to lower rewards. Obviously I will not work on a pull request if there is no strong interest for this. I think it is a harmless addition, so if I have time I can work on simulations to try to prove that there is a significant benefit with doing this. -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647