Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 18F348FC for ; Sat, 14 Nov 2015 09:31:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C8D7109 for ; Sat, 14 Nov 2015 09:31:20 +0000 (UTC) Received: from mail-io0-f180.google.com ([209.85.223.180]) by mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id 0MVc7t-1Ztp3w0S0F-00ZAYJ for ; Sat, 14 Nov 2015 10:31:19 +0100 Received: by iofh3 with SMTP id h3so119821383iof.3 for ; Sat, 14 Nov 2015 01:31:18 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.85 with SMTP id g82mr23067296ioe.144.1447493478345; Sat, 14 Nov 2015 01:31:18 -0800 (PST) Received: by 10.36.49.200 with HTTP; Sat, 14 Nov 2015 01:31:18 -0800 (PST) In-Reply-To: <1447459320911.325f57c8@Nodemailer> References: <201511132228.47815.luke@dashjr.org> <1447459320911.325f57c8@Nodemailer> Date: Sat, 14 Nov 2015 10:31:18 +0100 X-Gmail-Original-Message-ID: Message-ID: From: Adam Back To: digitsu@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:89Lax6em2z/db+AsS8YGOGGOgr4FGcp4B/VTERHdiiQfaGV4FgW yaApLW4hrikWJC0ndv1edFagprpBm5wDvz8v5yXNpfP4AYfAf0cO9xcta9oQR227+7B6j/D JlicPImDnsMwT22v9rgZIzb2c/BbAQBei3lPUsPLb4ywk0DA6EDgWoNsLm61WNl/Nmy++g9 FUHnVSYq+QqiUo5iR1vVg== X-UI-Out-Filterresults: notjunk:1;V01:K0:xsJozWVIOWE=:TvkjTpQ9PHhUbXK7dU6x9X fJa/O2/dB8caE1lX3wW6szAn+NrM4Ladj5ue+vyirTyka6Nd7D+9bg38vFF2VzkoqG+OlNKPh TdZDoQzlQixm8nv+yS81QhRyXAkBs2/VA8BCq8J8XdoVEHtbQuIYyV/9QlpWhFb+1v6B1EamQ tP4XjP4ydBl2awRca65Ll8JpqLLIrcvQ4hsrQHMGEY55XK5wEcEgCPMdjmSm+AtT9FlsdR5yt d62Kq/OWHyE0oShrGVB2Xk3Ae0i0Mkcvf3buyD/Lm+UBOhRIaIxzpP/7DeBuRWojwkqEsXaNV Ro/X7VRKnjbv8s94jDJJDl3ut/4wTGPdcnA/gN6mZoy+HiLQyd8RnkxoJUMXFSVcoFF0JDYT+ i1Cp3Aa7JRg4VCWEllivV1Q77ecysnN/1qhBCxsS88ubn/yBEbx0X3p7AXZwhQH7BZl0rS6yK ZSX7VmaJhUDQ4QPsa+Rf7rYtISaR1pBM8hdDIALJsnB1hzqcaEkBKYT1vJUMS/29WBwjehBzt 60kLSMIqcTH/wgATtLyPgLD59vQO0dsqBrZ5GSih2eZgFaImq6h4EPvFVy+T7j2aAqPGUjYTm 39dIrDq8E/nGnQzHMchbszKrRnJU4VcYN40BOCo0Ro0g+jrQi9SQPhdqXsi2VQ2ZdQpnmN/pO plSb1gsYykat4FUQWnCI2xQ9uY/jPOraZCnijYOl6rE1d06pbPb91fAf1onuSAlH0YHPpm/o/ m3KxHwOe0reGuGuG X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 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: Sat, 14 Nov 2015 09:31:21 -0000 There is a difference between miners signalling intent (as they have been for various BIPs, which is mostly informational only - they are mostly not running the code, and in some cases it is not implemented, so they cant be) there is a difference between that and a 95% miner majority consensus rule. Former can be useful information as you said, latter implies as Luke described something that is not really accurate, it is not strictly only a miner upgrade needed for basic safety as with soft-forks. If you look at BIP 103 for example it is flag day based, and I think this is a more accurate approach. Also with miner votes they can be misleading - vote for one thing, but run something else; what they are running is not generally detectable/enforceable - see for example what happened with the BIP66 accidental fork due to "SPV mining" (ie validationless mining). A hard-fork is for everyone to upgrade and talk with each other to see that the vast majority is on the same plan which includes users, ecosystem companies & miners. Adam On 14 November 2015 at 01:02, digitsu412 via bitcoin-dev wrote: > Well I'd like to think that with an economy all parts of it interact with > each other in ways more complex than simplistic imperative logic. > > I agree that the economic majority is essentially what matters in a hard > fork but everyone (miners,devs,public thought leaders,businesses) is part= of > that economy. Additionally what miners signal as their intention affects = the > decision of that economic majority (and vice versa). You can see the > effects of this in traditional political processes in how preliminary vot= e > polling results affect (reinforce) the final vote. > We also can see the results of this in (dare I mention) the whole XT affa= ir > which had the signed intent of many of the economy (payment processors an= d > wallets and one miner pool) and the rest of the miners did not go along w= ith > it. This experiment either means that the rest of the miners couldn't be > bothered to signal at all (because they didn't know how) or they were > affected by the influence of core devs or the opinions of others on the > matter and rejected the economic majority. (Which would imply core devs > have some power by way of indirect influence) I would be inclined to beli= eve > the latter was more likely. > > The conclusion which this would seem to imply is that at the very least, > miners matter (to what exact extent is debatable). And although there is= no > direct control of any party over the other in the strict sense, the publi= c > vocal opinions of any part of the Bitcoin economy does have an effect in = its > ability to sway the opinions of the other parts. > > Digitsu > > =E2=80=94 Regards, > > > On Sat, Nov 14, 2015 at 7:29 AM, Luke Dashjr wrote: >> >> On Friday, November 13, 2015 4:01:09 PM digitsu@gmail.com wrote: >> > Forgive the frankness but I don't see why signaling your intent to >> > support >> > an upgrade to one side of a hard fork can be seen as a bad thing. If f= or >> > nothing else doesn't this make for a smoother flag day? (Because once >> > you >> > signal your intention, it makes it hard to back out on the commitment.= ) >> >> It isn't a commitment in any sense, nor does it make it smoother, becaus= e >> for >> a hardfork to be successful, it is the *economy* that must switch >> entirely. >> The miners are unimportant. >> >> > If miners don't have any choice in hard forks, who does? Just the core >> > devs? >> >> Devs have even less of a choice in the matter. What is relevant is the >> economy: who do people want to spend their bitcoins with? There is no >> programmatic way to determine this, especially not in advance, so the be= st >> we >> can do is a flag day that gets called off if there isn't clear consensus= . >> >> Luke > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >