Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 57573CA6 for ; Fri, 4 Mar 2016 19:39:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9EE5A178 for ; Fri, 4 Mar 2016 19:39:01 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id k15so72764403lbg.0 for ; Fri, 04 Mar 2016 11:39:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=VrK15eSl8m0ML9Yp4N19qGZDg94iCU8bebhLmI4X4ic=; b=zagXtu5F09WRD08zK5bAz/Y3uf0ihod6bD+Cb0CVy2IeQv2SrioKIs9/UhPCjuLhnn ABKWQ0V1eGoAGXR4zwEijLNLiAYYhnCJayqrkIa8E269m2mNLecad7NonNifGjJT4Tjk 8DZgRknPR6nn2R590Rt/VOW18QDQnhyxoe8J7dOllRBYZkV0BAab87P3Ps0bgt8iIdFa n8X6BjqDxpxF50ONRHFtZbhDee+bKFVUCpyBmeIT1xM1AkjLo+UWe1ZStH4buhRYGClX f4lOYvBCXE66lmWtPRxF9hGMXi3nLHATdbxithFnB1IgJJbD0H1kLK8Syyx+lkfs3HIM y1/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=VrK15eSl8m0ML9Yp4N19qGZDg94iCU8bebhLmI4X4ic=; b=VKCc0mPd1cuJNHj20xR08D82YoY3A6yW9u5ynjgz7qWrXGm7GMJPGquVpG2M/FzNxG KleOpqTpvWiR6USdailyaHmd9Idn3CycKqQscpg51Ry51aytrsfOenaluN8P61wotMGS gEUZzKY4Gq5MficFTLAeBnTLJZzkHUTgMWo5gPZx3VbkRhaFYSpdNyX0XClzZVlz8+Y6 p7w1NgiwRSuLnmVHm8AhGFqJKnp90kEkWnYbdyubh4s3ai15XCulqkpQJTOsGex9IkA5 RdmOyFXlQFcS8bKCE8fsTNVOFMM12EXtgXXojoqIfGmeczHXm/oEVvZ+uLbSlPf8KPmu FIDg== X-Gm-Message-State: AD7BkJIZ/fExzfx1HaP4d0Nh9s03ukDv6Cc4HiLNPw1qsrhFk4u4Hg719Q9IZzxpAOlXwegNtRN0QQwjEVsjGQ== MIME-Version: 1.0 X-Received: by 10.112.180.5 with SMTP id dk5mr1127134lbc.86.1457120339868; Fri, 04 Mar 2016 11:38:59 -0800 (PST) Received: by 10.114.78.34 with HTTP; Fri, 4 Mar 2016 11:38:59 -0800 (PST) Date: Fri, 4 Mar 2016 11:38:59 -0800 Message-ID: From: David Manheim To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW 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, 09 Mar 2016 20:00:08 +0000 Subject: [bitcoin-dev] Proposing a (potentially less contentious) difficulty drop solution X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:39:05 -0000 Hi all, I've been following this discussion closely. Unlike most of the developers, I'm more of an economist and game theorist than cryptographer, and I wanted to suggest a possible compromise solution. Brief review of discussion so far, as background; There is a clear split in the discussion on the list about the costs and benefits of a potential solution. Most of this is because of implicit disagreement about the probability of a stalled blockchain at the halving, and how a change would open the door to worries about future changes. That said, as Paul Sztorc noted, "This halving-difficulty-drop problem can, with some bad luck, get quite disastrous, very quickly." If it doesn't happen, however, the solutions proposed unfairly give a bonus to miners, and speeding up the chain for a while - which also potentially increases the odds of block-splits during that time. Lukejr suggested that "it would need some way to avoid its early activation outside of such an emergency (which could possibly be detected in code, in this case)." That means it would fork after the halving, if and only if there was a stall. The problem with this is to detect it, and how to retarget, given asynchronous nodes. I don't think this can be avoided nicely without either creating some perverse incentives, or handing a large bonus to miners. Paul suggests a very low retarget difficulty, which essentially gives a larger bonus to miners until the next retarget; that's non-ideal. He also suggests investigating dynamic retargeting, (This was proposed a while ago here: http://www.truthcoin.info/blog/mining-heart-attack/ ) which others note is unfairly changing the implicit contract. The methods implemented by many altcoins with smooth / dynamic retargeting are not really suitable directly - as noted, people didn't sign up for dynamic retargeting, and there are stability issues. If bitcoin's hash rate drops after the halving, it could be sudden and drastic. Any solution I can foresee that prevents this leads to some difficult to analyze incentives for the miners. My proposal: I think a simple solution splits the difference; a short temporary dynamic difficulty retargeting after the halving. This allows for a fix, while making it clear that the original ruless of bitcoin shouldn't be discarded, and when they need to be altered, it will be a minimal change. It also limits the period where perverse incentives can exist, which minimizes their effects. We don't know what difficultly is appropriate after the halving, but can still allow a temporary dynamic difficult retargeting starting then. Halving occurs at block 420,000; it will then be 1/3 of the way to the next difficulty retarget. The remaining 1344 of those 2016 blocks can be used for a dynamic retarget, without changing the schedule otherwise. The initial retarget difficulty would be 1/2 of the previous one, as suggested by others, but it would very quickly stabilize at the appropriate level, using essentially any dynamic method - and so it would not stay low for long, unless necessary. One potential downside is that the probability of a orphaned blocks increases for a couple blocks. (That seems inevitable with any method that might reduce difficulty and lead to faster block generation, but by retargeting quickly, we limit that time frame.) At block 421344, it reverts to using the current method - and that can use the entire last 2016 blocks, to smooth out the lower difficulty adjustment that occurred. (Conveniently, in the longer term, the same method could be used for the 3 halvings after this one, with correspondingly shorter retarget windows, since 210000 isn't divisible by 2016 - until we're down to the 1.25btc coinbase reward, with 336 blocks until the next retarget. The next halving could eliminate this; the coinbase reward would be much less than mining fees by then, and halving difficulty would be unneeded. This also means that the retarget about would be reduced in the subsequent 2016 blocks each time, since the smaller retarget window will still be averaged in with the earlier blocks.) The only remaining question is what temporary retargeting method should we use? I'm completely agnostic on this one, since I think it doesn't make a huge difference, as long as there is a method chosen. Short altcoin methods review, to make some options clear; Smooth difficulty readjustment methods have been implemented by many altcoins. The first of these seems to be Kimoto Gravity Well, which does smoothing as follows; KGW = 1 + (0.7084 * pow((double(PastBlocksMass)/double(144)), -1.228)); DigiByteCoin tested this in the presence of discontinuities, and found it responded too slowly. Instead, they created the so-called Digishield, which was created explicitly to do smoothing in the presence of sudden shifts in mining, without causing stalling - but uses much closer together blocks to do so. See: https://www.reddit.com/r/Digibyte/comments/1yn6t1/digibyte_v_20_code_name_digishield/ for more. Another such method is Heavycoin's temporal retargeting. Any of these should be fine, since we don't need such fast response times. I hope this is a useful potential compromise, David Manheim