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 D2CCCB00 for ; Wed, 2 Mar 2016 16:17:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 10344157 for ; Wed, 2 Mar 2016 16:17:32 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id ts10so202855452obc.1 for ; Wed, 02 Mar 2016 08:17:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=x8EzkCnkYbFWuZJqc3bK+QW/jRY5OMrWupPBau2AUo0=; b=iy4HhhKMfocUwaR1MOCairk7zDRuIj9tdAeWJi+8SzRdM+PJWsg+2PoEXI1Th2GATn Jy6VPhDtlDN67pZKDFnnCnWzYMx5plj0q/4wx52f9gJefIxocfaFNsib/yWM5VbM9amx k/RmFQ8Le9/yFYX6vTmmsHFiFOQ1iwhwo5BBn/joiQl8iliBW4E5mk+GP0iGwwB25se3 jkTwMwckfWCJJUkUE4tXdnGJBv3tctvpQQV9tv0gOSt4wmd8o5LU4l4bECJUhYN+5cpG 9R91dSdy2QJPxuD2XmZbY7VbcNt4gN9kMjMZDPW9btcodyb3T++j4tkAHTKKIRJ9WUcS g00g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=x8EzkCnkYbFWuZJqc3bK+QW/jRY5OMrWupPBau2AUo0=; b=bMT+es2CeCUvYdg8mNjA3yCTe9V6bq0GxLkWSl/IGMt9GawN8KvQtmqB2OqHIe/qiP NRdoc2pLZylCl7j2dPZ5sfJ1TRVgeUGBgVxy/vnH+AZfkRgY1sf7Pa3ZGTLCiSrMkqbZ 7nYY+uSm7g5Rfs4bXeTvxairqrYeIFGaO8F9xARcUU2K4uYYpejYqeFLhjbtY8sUxa3S 5CWIkLPsno4Y4SCm4fG0qNTQqcjFFTFsUk2ib8sYFfK55zuvUVPqpBydHEgOgLCf+9R4 YuC/bD5zXp9PJOujonGs6Hg9BQSi3pIUL6xDncb3tgsZRZOCs3L0zqQASDTrsqmigQU5 25Eg== X-Gm-Message-State: AD7BkJJssiR2kHAQ932K5xOxzfjqssJeWKCRsH3XN4OnelsE/cLM5GjsDEsdryYXnf6sSrVydFlFbprfW6SG/Q== MIME-Version: 1.0 X-Received: by 10.182.73.225 with SMTP id o1mr22871106obv.80.1456935451379; Wed, 02 Mar 2016 08:17:31 -0800 (PST) Received: by 10.157.17.117 with HTTP; Wed, 2 Mar 2016 08:17:31 -0800 (PST) In-Reply-To: <201603021456.15820.luke@dashjr.org> References: <201603021456.15820.luke@dashjr.org> Date: Wed, 2 Mar 2016 10:17:31 -0600 Message-ID: From: Bryan Bishop To: Bitcoin Dev , Bryan Bishop Content-Type: multipart/alternative; boundary=089e0160b7c60a532f052d133877 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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, 02 Mar 2016 16:31:05 +0000 Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm 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: Wed, 02 Mar 2016 16:17:32 -0000 --089e0160b7c60a532f052d133877 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 2, 2016 at 8:56 AM, Luke Dashjr wrote: > We are coming up on the subsidy halving this July, and there have been so= me > Luke, One reason "hard-fork to fix difficulty drop algorithm" could be controversial is that the proposal involves a hard-fork (perhaps necessarily so, at my first and second glance). There are a number of concerns with hard-forks including security, deployment, participation, readiness measurement, backwards incompatibility, etc. In fact, some Bitcoin Core developers believe that hard-forks are not a good idea and should not be used. # Hard-forks An interesting (unspoken?) idea I=E2=80=99ve heard from a few people has be= en =E2=80=9Cwe should try to avoid all hard-forks because they are backwards incompatible=E2=80=9D, another thought has been "there should only be one m= ore hard-fork if any" and/or "there should only be one hard-fork every 30 years". I also recognize feedback from others who have mentioned "probably unrealistic to expect that the consensus layer can be solidified this early in Bitcoin's history". At the same time there are concerns about =E2=80=9Cs= lippery slopes=E2=80=9D.... Also, if you are going to participate in a hard-fork then I think you should make up some proposals for ensure minimal monetary loss on the old (non-hard-forked) chain, especially since your proposed timeline is so short seems reasonable to expect even more safety-related due diligence to minimize money loss (such as using a new address prefix on the hard-forked upgrade). Anyway, it should be clear that hard-forks are an unsettled issue and are controversial in ways that I believe you are already aware about. # Have miners gradually reduce their hashrate instead of using a step function cliff adam3us recently proposed that miners who are thinking of turning off equipment should consider gradually ramping down their hashrate, as a show of goodwill (and substantial loss to themselves, similar to how they would incur losses from no longer mining after the halving). This is not something the consensus algorithm can enforce at the moment, and this suggestion does not help under adversarial conditions. Since this suggestion does not require a hard-fork, perhaps some effort should be made to query miners and figure out if they need assistance with implementing this (if they happen to be interested). # Contingency planning Having said all of the negative things above about hard-forks, I will add that I do actually like the idea of having backup plans available and tested and gitian-built many weeks ahead of expected network event dates. Unfortunately this might encourage partial consensus layer hard-forks in times of extreme uncertainty such as "emergencies".... creating an even further emergency. # "Indefinite backlog growth" You write "the backlog would grow indefinitely until the adjustment occurs". This seems to be expected behavior regardless of difficulty adjustment (in fact, a backlog could continue to grow even once difficulty adjusts downward), and the consensus protocol does not commit to information regarding that backlog anyway... # Difficulty adjustment taking time is expected This is an expected part of the protocol, it's been mentioned since forever, it's well known and accounted for. Instead, we should be providing advice to users about which alternative payment systems they should be using if they expect instantaneous transaction confirmations. This has been a long-standing issue, and rolling out a hard-fork is not going to fix mistaken assumptions from users. They will still think that confirmations were meant to be instantaneous regardless of how many hard-forks you choose to deploy. - Bryan http://heybryan.org/ 1 512 203 0507 --089e0160b7c60a532f052d133877 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 2, 2016 at 8:56 AM, Luke Dashjr wrote:
We are c= oming up on the subsidy halving this July, and there have been some

Luke,

One reason "hard= -fork to fix difficulty drop algorithm" could be controversial is that= the proposal involves a hard-fork (perhaps necessarily so, at my first and= second glance). There are a number of concerns with hard-forks including s= ecurity, deployment, participation, readiness measurement, backwards incomp= atibility, etc. In fact, some Bitcoin Core developers believe that hard-for= ks are not a good idea and should not be used.

# H= ard-forks

An interesting (unspoken?) idea I=E2=80= =99ve heard from a few people has been =E2=80=9Cwe should try to avoid all = hard-forks because they are backwards incompatible=E2=80=9D, another though= t has been "there should only be one more hard-fork if any" and/o= r "there should only be one hard-fork every 30 years". I also rec= ognize feedback from others who have mentioned "probably unrealistic t= o expect that the consensus layer can be solidified this early in Bitcoin&#= 39;s history". At the same time there are concerns about =E2=80=9Cslip= pery slopes=E2=80=9D....

Also, if you are going to= participate in a hard-fork then I think you should make up some proposals = for ensure minimal monetary loss on the old (non-hard-forked) chain, especi= ally since your proposed timeline is so short seems reasonable to expect ev= en more safety-related due diligence to minimize money loss (such as using = a new address prefix on the hard-forked upgrade). Anyway, it should be clea= r that hard-forks are an unsettled issue and are controversial in ways that= I believe you are already aware about.

# Have min= ers gradually reduce their hashrate instead of using a step function cliff<= /div>

adam3us recently proposed that miners who are thin= king of turning off equipment should consider gradually ramping down their = hashrate, as a show of goodwill (and substantial loss to themselves, simila= r to how they would incur losses from no longer mining after the halving). = This is not something the consensus algorithm can enforce at the moment, an= d this suggestion does not help under adversarial conditions. Since this su= ggestion does not require a hard-fork, perhaps some effort should be made t= o query miners and figure out if they need assistance with implementing thi= s (if they happen to be interested).

# Contingency= planning

Having said all of the negative things a= bove about hard-forks, I will add that I do actually like the idea of havin= g backup plans available and tested and gitian-built many weeks ahead of ex= pected network event dates. Unfortunately this might encourage partial cons= ensus layer hard-forks in times of extreme uncertainty such as "emerge= ncies".... creating an even further emergency.

# "Indefinite backlog growth"

You writ= e "the backlog would grow indefinitely until the adjustment occurs&quo= t;. This seems to be expected behavior regardless of difficulty adjustment = (in fact, a backlog could continue to grow even once difficulty adjusts dow= nward), and the consensus protocol does not commit to information regarding= that backlog anyway...

# Difficulty adjustment ta= king time is expected

This is an expected part of = the protocol, it's been mentioned since forever, it's well known an= d accounted for. Instead, we should be providing advice to users about whic= h alternative payment systems they should be using if they expect instantan= eous transaction confirmations. This has been a long-standing issue, and ro= lling out a hard-fork is not going to fix mistaken assumptions from users. = They will still think that confirmations were meant to be instantaneous reg= ardless of how many hard-forks you choose to deploy.

- Bryan
http://heybryan.org/
1 512 203 0507
--089e0160b7c60a532f052d133877--