Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DA4181BB for ; Sun, 15 Nov 2015 12:17:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com [209.85.213.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8F5FA8 for ; Sun, 15 Nov 2015 12:16:57 +0000 (UTC) Received: by vkas68 with SMTP id s68so14764701vka.2 for ; Sun, 15 Nov 2015 04:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon_cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=w4m9x6utcJx5x1Gy4JjkA9lLlXjo9NQCYcvYgErNCcE=; b=YDDfVXefJYYKVwMC90ZKLbAAwElCEj0hGrwkuGrRma1UNgGizmo+4SozyS9nUutBy2 hzyybbSge1zY+6Mck7pudWM8Mj48ARx2I3whfWhpr95Yq4v5uszb9nysFG+mblKuZfUi trsw5ZUi7J/vGl11QtIBcWLVrxnv9HngR7P7yuGgxM7M43Ooj3mc5kxR+wCCGROj73QD 5yhA1hm0X9HGsRuP/KDS17rkLIyI3vdNBnZrijUUw6Ps/jSllpnHWgGOR+tO9e1qe92+ 96jQRuDUkVqhIQc5c62WfQ0AINT3Bx2Lo9r76ltBNjMIx6nVt4ZfPfIpSE+N7ctQDLos ll2Q== 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:cc:content-type :content-transfer-encoding; bh=w4m9x6utcJx5x1Gy4JjkA9lLlXjo9NQCYcvYgErNCcE=; b=aeXgwFQoCi3k96SfhU5SHuYSXx9o7T70xIrD/+EXl1xBojCqD8txviZE2kGucBIQU9 k3Er2r/Gt1Y+P0SbMJaeWF5VtLIksENwbaOPwNACbvsh9d+N60NgwRCm50JOqGR0L+sX 5YGA1/y/WPDnz473aAdluWoaL+6IL9PLxxlxdVNXdAu18Zp/Kpw8BS9I/+MPa48poas3 lh8yFHm06uVFHhWopWpnXjTUbWimVISWr+Kflm5rUbNO932/5NkgsYyF+OqGBxZQoJ69 qYumjw9Sw2KLp5BSBAo9C23tnoWLG7IpxhMgYWh+NhgOJbYrvYC40eQvSnJ/HIuOiNQC 874Q== X-Gm-Message-State: ALoCoQkH7RZ34M7aTXRtVfAGZz5XtXyw/PZgV04mO3B+1Inqswp9cW1m0M/qg4C7+9mlmh4RyCBV MIME-Version: 1.0 X-Received: by 10.31.151.9 with SMTP id z9mr7618156vkd.38.1447589817069; Sun, 15 Nov 2015 04:16:57 -0800 (PST) Received: by 10.31.132.147 with HTTP; Sun, 15 Nov 2015 04:16:56 -0800 (PST) In-Reply-To: <201511142127.53255.luke@dashjr.org> References: <201511132228.47815.luke@dashjr.org> <201511142111.24046.luke@dashjr.org> <201511142127.53255.luke@dashjr.org> Date: Sun, 15 Nov 2015 13:16:56 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Luke Dashjr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 Cc: Bitcoin Dev , John Sacco Subject: Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M 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: Sun, 15 Nov 2015 12:17:01 -0000 On Sat, Nov 14, 2015 at 10:11 PM, Luke Dashjr wrote: > On Saturday, November 14, 2015 10:52:12 AM Jorge Tim=C3=B3n via bitcoin-d= ev wrote: >> Currently bip99 recommends 95% miner upgrade confirmation with version b= its >> (bip9) for uncontroversial hardforks just like it does for uncontroversi= al >> softforks. It is true that in the case of hardforks miners don't decide = and >> it's the whole economy who has to upgrade before activation, but "the wh= ole >> economy" and "all users" includes miners, so why not use the only upgrad= e >> confirmation mechanism that we have available? > > Actually, the economy does not necessarily include miners, and in fact th= e > present miner community for the most part does not overlap significantly = with > economic activity. Maybe we should define "the bitcoin economy" is first. In my definition, miners are definitely part of the economy (and also users of the system). On Sat, Nov 14, 2015 at 10:27 PM, Luke Dashjr wrote: > On Saturday, November 14, 2015 9:15:07 PM Angel Leon wrote: >> "the economy does not necessarily include miners" >> so the money supply isn't part of the economy? > > Not in the context of economic majority deciding hardforks. After all, th= e > outcome of the hardfork *determines* the money supply. So the former mone= y > supply not supporting the change would just mean they cease to be involve= d in > that capacity. But even aside from that, the more relevant factor in term= s of > economic involvement is /acceptance/ of bitcoins as payment for real good= s. Miners accept bitcoins as payment for a real service (with real costs like electricity) to the network: extending the longest valid chain with their proof of work. In the context of BIP99, there's no concept of "an economic majority" deciding hardforks. Hardforks are either uncontroversial, in which case BIP99 recommends 95% miner upgrade confirmation in addition to a time threshold, or are schism hardforks (for example, an anti-miner hardfork), in which case BIP99 recommends using a time threshold alone. But no majority can force the dissenting users to use one validation rule set or the other: users will always be free to run whatever free software they like. > And at the same time, miners also have a tendency to > upgrade at a different rate than the economy. That alone seems like a very good reason in favor to confirm that miners have upgraded in addition to a minimal activation block median time, not a reason against it > It might make sense to > incorporate a miner-trigger, but *only if* the flag is enabled in nodes b= y an > option disabled by default, and the BIP clearly specifies that miners mus= t not > enable it until they perceive complete economic adoption of the change. I'm not sure I understand this. The trigger mechanism must be uniform for each rule change, it cannot be optionally different or consensus can fail. How are miners supposed to "perceive" adoption? The time threshold must be set enough in the future to give users time to upgrade. But we can perceive miners' adoption, so if the system knows they haven't upgraded, it should wait for them to upgrade (it would be nice to have an equivalent mechanism to wait for the rest of the users, but unfortunately there's none). Please, remember that this is in the context of uncontroversial hardforks for which all users (including all miners) are expected to upgrade to. To reiterate, schism hardforks are treated differently and the miner upgrade confirmation becomes completely irrelevant.