Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z3U8d-0004oJ-3R for bitcoin-development@lists.sourceforge.net; Fri, 12 Jun 2015 18:57:11 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.218.66 as permitted sender) client-ip=209.85.218.66; envelope-from=gustafsonja@gmail.com; helo=mail-oi0-f66.google.com; Received: from mail-oi0-f66.google.com ([209.85.218.66]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z3U8b-0000EQ-SL for bitcoin-development@lists.sourceforge.net; Fri, 12 Jun 2015 18:57:11 +0000 Received: by oiax69 with SMTP id x69so5317060oia.2 for ; Fri, 12 Jun 2015 11:57:04 -0700 (PDT) X-Received: by 10.202.95.198 with SMTP id t189mr12522496oib.105.1434135424458; Fri, 12 Jun 2015 11:57:04 -0700 (PDT) MIME-Version: 1.0 Sender: gustafsonja@gmail.com Received: by 10.202.194.68 with HTTP; Fri, 12 Jun 2015 11:56:34 -0700 (PDT) In-Reply-To: <1900349.Piv8ps0gCz@crushinator> References: <20150612181153.GB19199@muck> <3287607.HcH18TyfSu@crushinator> <20150612184450.GG19199@muck> <1900349.Piv8ps0gCz@crushinator> From: Aaron Gustafson Date: Fri, 12 Jun 2015 11:56:34 -0700 X-Google-Sender-Auth: RFsb8lPjvSkFXL-OKZqqXBZjRD8 Message-ID: To: Matt Whitlock Content-Type: multipart/alternative; boundary=001a113ccfa688e483051856ac6d X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gustafsonja[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z3U8b-0000EQ-SL Cc: bitcoin-dev Subject: Re: [Bitcoin-development] User vote in blocksize through fees X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 18:57:11 -0000 --001a113ccfa688e483051856ac6d Content-Type: text/plain; charset=UTF-8 For the purposes of finding the median, halve < same < double. It will only change if a majority of non-apathetic votes are for halve or a majority of non-apathetic votes are for double. On Fri, Jun 12, 2015 at 11:54 AM, Matt Whitlock wrote: > On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote: > > On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote: > > > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote: > > > > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote: > > > > > Why should miners only be able to vote for "double the limit" or > "halve" the limit? If you're going to use bits, I think you need to use two > bits: > > > > > > > > > > 0 0 = no preference ("wildcard" vote) > > > > > 0 1 = vote for the limit to remain the same > > > > > 1 0 = vote for the limit to be halved > > > > > 1 1 = vote for the limit to be doubled > > > > > > > > > > User transactions would follow the same usage. In particular, a > user vote of "0 0" (no preference) could be included in a block casting any > vote, but a block voting "0 0" (no preference) could only contain > transactions voting "0 0" as well. > > > > > > > > Sounds like a good encoding to me. Taking the median of the three > > > > options, and throwing away "don't care" votes entirely, makes sense. > > > > > > I hope you mean the *plurality* of the three options after throwing > away the "don't cares," not the *median*. > > > > Median ensures that voting "no change" is meaningful. If "double" + "no > > change" = 66%-1, you'd expect the result to be "no change", not "halve"" > > With a plurality vote you'd end up with a halving that was supported by > > a minority. > > Never mind. I think I've figured out what you're getting at, and you're > right. We wouldn't want "halve" to win on a plurality just because the > remaining majority of the vote was split between double and > remain-the-same. Good catch. :) > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- J. Aaron Gustafson Cornell University '16 | Computer Science, Engineering | Mathematics, Arts & Sciences Vice President, Kappa Delta Rho jag426@cornell.edu | Ithaca, New York --001a113ccfa688e483051856ac6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For the purposes of finding the median, halve < same &l= t; double. It will only change if a majority of non-apathetic votes are for= halve or a majority of non-apathetic votes are for double.

On Fri, Jun 12, 2015 at 11:= 54 AM, Matt Whitlock <bip@mattwhitlock.name> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On Fr= iday, 12 June 2015, at 7:44 pm, Peter Todd wrote:
> On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
> > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> > > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrot= e:
> > > > Why should miners only be able to vote for "double= the limit" or "halve" the limit? If you're going to use= bits, I think you need to use two bits:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 0 =3D no preference = ("wildcard" vote)
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 1 =3D vote for the l= imit to remain the same
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01 0 =3D vote for the l= imit to be halved
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01 1 =3D vote for the l= imit to be doubled
> > > >
> > > > User transactions would follow the same usage. In parti= cular, a user vote of "0 0" (no preference) could be included in = a block casting any vote, but a block voting "0 0" (no preference= ) could only contain transactions voting "0 0" as well.
> > >
> > > Sounds like a good encoding to me. Taking the median of the = three
> > > options, and throwing away "don't care" votes = entirely, makes sense.
> >
> > I hope you mean the *plurality* of the three options after throwi= ng away the "don't cares," not the *median*.
>
> Median ensures that voting "no change" is meaningful. If &qu= ot;double" + "no
> change" =3D 66%-1, you'd expect the result to be "no cha= nge", not "halve""
> With a plurality vote you'd end up with a halving that was support= ed by
> a minority.

Never mind. I think I've figured out what you're gettin= g at, and you're right. We wouldn't want "halve" to win o= n a plurality just because the remaining majority of the vote was split bet= ween double and remain-the-same. Good catch. :)

---------------------------------------------------------------------------= ---
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/= listinfo/bitcoin-development



--
=
=
J. Aaron Gustafson
Cornell University '16 | Computer Sc= ience, Engineering | Mathematics, Arts & Sciences
Vice President, Kappa Delta Rho
jag426@cornell.edu=C2=A0| Ithaca, New York
--001a113ccfa688e483051856ac6d--