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 4DBBFE1E for ; Mon, 17 Sep 2018 14:09:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DE559784 for ; Mon, 17 Sep 2018 14:09:36 +0000 (UTC) Received: by mail-ua1-f47.google.com with SMTP id q7-v6so10467411uam.12 for ; Mon, 17 Sep 2018 07:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ncKFpXid2Qc3aJ/1zuUiEzPTDrUe2hmXnp77TwpQe2c=; b=N5O5yezxrl88kfYzaQlqWQLuiQzZaw8R/6Ie7Z/VLseCsfY7adhg46gC7tkQ3D6Yzk TWVRulhAR0yw0+sgR9HJbvjLj2Pst6eFiDkxtQjVUNSK2LQwEggUeh6aAHZb+1IgxnDH hHFSVC5Mu+6zoQzP4mK55nW1+1avXcsDpH+rO+dTqaS6TO6nP5Cd4BIkWnzkgD3pTbCo SMVa8tRTkqY4w1gfZPjwNm9jhFh5fnvnajnhr9XP2sxjtAOS/bGxKco9LA4rUfZa+T+I IGLicgokdCtcFRf0JZcmBfFJKxAEZiHG+qiFBoAvarDr2PcIoKtsYBfsQ2zKQf0edzUG YpGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ncKFpXid2Qc3aJ/1zuUiEzPTDrUe2hmXnp77TwpQe2c=; b=Z9I/Hhh+yRYr57XHsD8U/btjrSlVph1045ZkGVv+FsRwpHXaUyloNH5j3xCv8XhqJJ Z9Lw2U9+eyPX71iWGQ6U2l+qRDB7VdSgzzna2PPZNEHd6Tc84VSyfCo8Chq4u1kTH5pA SW4Yx1gZWM7g9v+CqEqi80vPlINbjAvprj+sZIRWDU8tZRVUg2rJRACcR8sbBpLkKpZA cgvvhviBpg9nz5gepRb2s3k7mYSBef9EooDYJRRu9VwOwuD+N3DfyPMguKvoOpxhQC0Q JGgT+BVCHQ7qqFbnaKk3SzuQO+iGzrBAGiMjS9wOz2MhivhSahUXJsQaGZx5SqkdgUvK OWrQ== X-Gm-Message-State: APzg51AvUXbi4DIXqliGnCfqPyQkQh1wL6SyWSIqLuEE20NWygYnCOsg T4yG643texOYFpXpZNFy5wp6xZ/KQUhtwGOjPWIs2FfH X-Google-Smtp-Source: ANB0Vdag2KspDdU98/56IyVxW3X5OIy+ltJge+JMVQGm1OolFJLUb5PWvgZJpN3PXeJTYYZ0N3FjLR3ctM6aooRIEac= X-Received: by 2002:a9f:386a:: with SMTP id q39-v6mr7703354uad.196.1537193375329; Mon, 17 Sep 2018 07:09:35 -0700 (PDT) MIME-Version: 1.0 From: Zawy Date: Mon, 17 Sep 2018 10:09:23 -0400 Message-ID: To: 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: Tue, 18 Sep 2018 04:32:30 +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: Mon, 17 Sep 2018 14:09:37 -0000 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. The problem has been solved to the best of our ability by the Nakamoto consensus. The math is straightforward, so you can't get around it's failings unless it's a profound solution or we shift trust to some place else. Currently we have to choose and trust a small group of coins (or 1) to be the best choice(s), and to trust that the reward plus fees we pay for mining (compared to coin value) is enough to prevent a 51% attack. > Say p is the peak hashrate for 365 periods (1 year) > consisting of 144 blocks, h is the hashrate of the last 144 block (1 > day) period, and r is the base subsidy (12.5 BTC currently). You can > then make the max block reward 0.5 r (1 + h/p). So if hashrate is at > peak you get the full reward. Otherwise you get less, down to a min of