path: root/5f/04d5f94f063c2efeded47c8f2848d45e0da419

Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 474B9405
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 14 Nov 2015 10:52:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com
	[209.85.213.44])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1029A90
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 14 Nov 2015 10:52:14 +0000 (UTC)
Received: by vkbq142 with SMTP id q142so5434665vkb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 14 Nov 2015 02:52:13 -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;
	bh=s/dLvO/lRbxpW6PPouCKZ/EoyHxd1GyoONH27FQ0rZw=;
	b=N5k/5NAUXG6wyC0Vmr0iX9zGWg7DruWs4N7+QzcMvzXQEC2IqnBl3sD9CI7YdCZEJJ
	uV6h7vNyusi/eOHDEYcIrwr7OWtOwmBqjxZitlkEBLHcIeYVbtVgP2MU4eg0ZRMV5h8C
	HLcOsWuyvbo1XQEGd6/I9OKLRtMyUAzqmfxq5R59za60iAALc46k0yuS6TQz1Bb/mCtc
	QAXMGeOqopEk12BLQvHYdjIaZwjCBFO0uMtSjQGZ0JIbvRaMhw6gl8areWuODxihgfXs
	4XtkvfNyiXx5t1wqcGPRcOot02TJUZ4Ap+3VudZPFaKAAi0hjPEudp0srL5BsagikElj
	NYZg==
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;
	bh=s/dLvO/lRbxpW6PPouCKZ/EoyHxd1GyoONH27FQ0rZw=;
	b=cIxP9UTaz63h9Hu8cqCcdI1RJsYQSaKTgQv6zlHdqwinPhPDN/C5/Y4e2RslEMPlwc
	ZFmtoE7xe8bJoaIvzK8u0JvOlq6v/11teUXd8rP7F8vWLNSaRydD8tOTvBoulb34E56/
	YkAeB8HpPDYfa3g4LpmmkTMPaEFZNjgOSOx+W8k/7wuxDnTwJdh855tvJoeMJT6rliTR
	SKKJY7G4LmmAZ9z9eN/xTjxY3dsAvDUE7cCBfMpjp34Z3DdpgDfxYPB0ytntyBqncGtm
	l/4nod4gjqofU5qT/IF6JvCYFmeR5uqx53HVickB0lGvzXKTMJxsW0BAnceChTe0jEpV
	yDEg==
X-Gm-Message-State: ALoCoQlZ7/dhOLruMD3PZ0jIx+xFMYOeVClKW3bMQr85tAbHQB9x/sMiWi4qpYKOMVUOPhWMUmpH
MIME-Version: 1.0
X-Received: by 10.31.11.197 with SMTP id 188mr2367697vkl.2.1447498333233; Sat,
	14 Nov 2015 02:52:13 -0800 (PST)
Received: by 10.31.132.147 with HTTP; Sat, 14 Nov 2015 02:52:12 -0800 (PST)
Received: by 10.31.132.147 with HTTP; Sat, 14 Nov 2015 02:52:12 -0800 (PST)
In-Reply-To: <CALqxMTFE9W0nxGHvcJN_Wz88b00o-K29GRTbHJv+VSpYAJKUNQ@mail.gmail.com>
References: <201511132228.47815.luke@dashjr.org>
	<1447459320911.325f57c8@Nodemailer>
	<CALqxMTFE9W0nxGHvcJN_Wz88b00o-K29GRTbHJv+VSpYAJKUNQ@mail.gmail.com>
Date: Sat, 14 Nov 2015 11:52:12 +0100
Message-ID: <CABm2gDo7D1rrsjRef173HVkwBrDQ0uJAhtWKk0SmRFaqzX5VTw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=001a1144211af736aa05247df704
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	John Sacco <johnsock@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Nov 2015 10:52:15 -0000

--001a1144211af736aa05247df704
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Currently bip99 recommends 95% miner upgrade confirmation with version bits
(bip9) for uncontroversial hardforks just like it does for uncontroversial
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 whole
economy" and "all users" includes miners, so why not use the only upgrade
confirmation mechanism that we have available?

The way I see it, uncontroversial softforks are also expected to be
upgraded to by everyone eventually. The advantage of softforks is that
non-miners don't need to do it before activation like with hardforks.
That's the only important difference I see between uncontroversial
softforks and hardforks (unilateral softforks and schism hardforks are
another thing though).

Please let's discuss this generally within the context of bip99 instead of
discussing different deployment details with every proposal. There's a
couple of threads in the ml, a couple of now merged bip99 prs in
bitcoin/bips...
On Nov 14, 2015 10:31 AM, "Adam Back via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Well I'd like to think that with an economy all parts of it interact wi=
th
> > each other in ways more complex than simplistic imperative logic.
> >
> > I agree that the economic majority is essentially what matters in a har=
d
> > fork but everyone (miners,devs,public thought leaders,businesses) is
> part of
> > that economy. Additionally what miners signal as their intention affect=
s
> the
> > decision of that economic majority (and vice versa).  You can see the
> > effects of this in traditional political processes in how preliminary
> vote
> > polling results affect (reinforce) the final vote.
> > We also can see the results of this in (dare I mention) the whole XT
> affair
> > which had the signed intent of many of the economy (payment processors
> and
> > wallets and one miner pool) and the rest of the miners did not go along
> with
> > it. This experiment either means that the rest of the miners couldn't b=
e
> > 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 dev=
s
> > have some power by way of indirect influence) I would be inclined to
> believe
> > 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
> public
> > vocal opinions of any part of the Bitcoin economy does have an effect i=
n
> 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 <luke@dashjr.org> 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
> for
> >> > nothing else doesn't this make for a smoother flag day? (Because onc=
e
> >> > 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,
> because
> >> 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 co=
re
> >> > 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
> best
> >> 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
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a1144211af736aa05247df704
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Currently bip99 recommends 95% miner upgrade confirmation wi=
th version bits (bip9) for uncontroversial hardforks just like it does for =
uncontroversial softforks. It is true that in the case of hardforks miners =
don&#39;t decide and it&#39;s the whole economy who has to upgrade before a=
ctivation, but &quot;the whole economy&quot; and &quot;all users&quot; incl=
udes miners, so why not use the only upgrade confirmation mechanism that we=
 have available?</p>
<p dir=3D"ltr">The way I see it, uncontroversial softforks are also expecte=
d to be upgraded to by everyone eventually. The advantage of softforks is t=
hat non-miners don&#39;t need to do it before activation like with hardfork=
s.<br>
That&#39;s the only important difference I see between uncontroversial soft=
forks and hardforks (unilateral softforks and schism hardforks are another =
thing though).</p>
<p dir=3D"ltr">Please let&#39;s discuss this generally within the context o=
f bip99 instead of discussing different deployment details with every propo=
sal. There&#39;s a couple of threads in the ml, a couple of now merged bip9=
9 prs in bitcoin/bips...</p>
<div class=3D"gmail_quote">On Nov 14, 2015 10:31 AM, &quot;Adam Back via bi=
tcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attributi=
on"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">There is a difference between miners sig=
nalling intent (as they have<br>
been for various BIPs, which is mostly informational only - they are<br>
mostly not running the code, and in some cases it is not implemented,<br>
so they cant be) there is a difference between that and a 95% miner<br>
majority consensus rule.=C2=A0 Former can be useful information as you<br>
said, latter implies as Luke described something that is not really<br>
accurate, it is not strictly only a miner upgrade needed for basic<br>
safety as with soft-forks.=C2=A0 If you look at BIP 103 for example it is<b=
r>
flag day based, and I think this is a more accurate approach.=C2=A0 Also<br=
>
with miner votes they can be misleading - vote for one thing, but run<br>
something else; what they are running is not generally<br>
detectable/enforceable - see for example what happened with the BIP66<br>
accidental fork due to &quot;SPV mining&quot; (ie validationless mining).<b=
r>
<br>
A hard-fork is for everyone to upgrade and talk with each other to see<br>
that the vast majority is on the same plan which includes users,<br>
ecosystem companies &amp; miners.<br>
<br>
Adam<br>
<br>
On 14 November 2015 at 01:02, digitsu412 via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; wrote:<br>
&gt; Well I&#39;d like to think that with an economy all parts of it intera=
ct with<br>
&gt; each other in ways more complex than simplistic imperative logic.<br>
&gt;<br>
&gt; I agree that the economic majority is essentially what matters in a ha=
rd<br>
&gt; fork but everyone (miners,devs,public thought leaders,businesses) is p=
art of<br>
&gt; that economy. Additionally what miners signal as their intention affec=
ts the<br>
&gt; decision of that economic majority (and vice versa).=C2=A0 You can see=
 the<br>
&gt; effects of this in traditional political processes in how preliminary =
vote<br>
&gt; polling results affect (reinforce) the final vote.<br>
&gt; We also can see the results of this in (dare I mention) the whole XT a=
ffair<br>
&gt; which had the signed intent of many of the economy (payment processors=
 and<br>
&gt; wallets and one miner pool) and the rest of the miners did not go alon=
g with<br>
&gt; it. This experiment either means that the rest of the miners couldn&#3=
9;t be<br>
&gt; bothered to signal at all (because they didn&#39;t know how) or they w=
ere<br>
&gt; affected by the influence of core devs or the opinions of others on th=
e<br>
&gt; matter and rejected the economic majority.=C2=A0 (Which would imply co=
re devs<br>
&gt; have some power by way of indirect influence) I would be inclined to b=
elieve<br>
&gt; the latter was more likely.<br>
&gt;<br>
&gt; The conclusion which this would seem to imply is that at the very leas=
t,<br>
&gt; miners matter (to what exact extent is debatable).=C2=A0 And although =
there is no<br>
&gt; direct control of any party over the other in the strict sense, the pu=
blic<br>
&gt; vocal opinions of any part of the Bitcoin economy does have an effect =
in its<br>
&gt; ability to sway the opinions of the other parts.<br>
&gt;<br>
&gt; Digitsu<br>
&gt;<br>
&gt; =E2=80=94 Regards,<br>
&gt;<br>
&gt;<br>
&gt; On Sat, Nov 14, 2015 at 7:29 AM, Luke Dashjr &lt;<a href=3D"mailto:luk=
e@dashjr.org">luke@dashjr.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Friday, November 13, 2015 4:01:09 PM <a href=3D"mailto:digitsu@=
gmail.com">digitsu@gmail.com</a> wrote:<br>
&gt;&gt; &gt; Forgive the frankness but I don&#39;t see why signaling your =
intent to<br>
&gt;&gt; &gt; support<br>
&gt;&gt; &gt; an upgrade to one side of a hard fork can be seen as a bad th=
ing. If for<br>
&gt;&gt; &gt; nothing else doesn&#39;t this make for a smoother flag day? (=
Because once<br>
&gt;&gt; &gt; you<br>
&gt;&gt; &gt; signal your intention, it makes it hard to back out on the co=
mmitment.)<br>
&gt;&gt;<br>
&gt;&gt; It isn&#39;t a commitment in any sense, nor does it make it smooth=
er, because<br>
&gt;&gt; for<br>
&gt;&gt; a hardfork to be successful, it is the *economy* that must switch<=
br>
&gt;&gt; entirely.<br>
&gt;&gt; The miners are unimportant.<br>
&gt;&gt;<br>
&gt;&gt; &gt; If miners don&#39;t have any choice in hard forks, who does? =
Just the core<br>
&gt;&gt; &gt; devs?<br>
&gt;&gt;<br>
&gt;&gt; Devs have even less of a choice in the matter. What is relevant is=
 the<br>
&gt;&gt; economy: who do people want to spend their bitcoins with? There is=
 no<br>
&gt;&gt; programmatic way to determine this, especially not in advance, so =
the best<br>
&gt;&gt; we<br>
&gt;&gt; can do is a flag day that gets called off if there isn&#39;t clear=
 consensus.<br>
&gt;&gt;<br>
&gt;&gt; Luke<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--001a1144211af736aa05247df704--