Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.77 as permitted sender)
	client-ip=62.13.149.77; envelope-from=pete@petertodd.org;
	helo=outmail149077.authsmtp.com; 
Date: Fri, 12 Jun 2015 19:34:21 +0100
From: Peter Todd <pete@petertodd.org>
To: Matt Whitlock <bip@mattwhitlock.name>
Message-ID: <20150612183421.GE19199@muck>
References: <20150612181153.GB19199@muck>
 <23144512.HX7dfatEFr@crushinator>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="7mxbaLlpDEyR1+x6"
Content-Disposition: inline
In-Reply-To: <23144512.HX7dfatEFr@crushinator>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] User vote in blocksize through fees
Precedence: list


--7mxbaLlpDEyR1+x6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
>=20
> 	0 0 =3D no preference ("wildcard" vote)
> 	0 1 =3D vote for the limit to remain the same
> 	1 0 =3D vote for the limit to be halved
> 	1 1 =3D vote for the limit to be doubled
>=20
> 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, bu=
t a block voting "0 0" (no preference) could only contain transactions voti=
ng "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.

> Incidentally, I love this idea, as it addresses a concern I immediately h=
ad with Jeff's proposal, which is that it hands control exclusively to the =
miners. And your proposal here fixes that shortcoming in a economically pow=
erful way: miners lose out on fees if they don't represent the wishes of th=
e users.

Thanks! I personally expect disaster to ensue with this kind of
proposal, but I'm less concerned if the disaster is something users
explicitly allowed to happen in a consensual way.

--=20
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778

--7mxbaLlpDEyR1+x6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVeyYqXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMjdhYjFkNTc2ZGM4NTFmMzc0NDI0ZjEyNjljNDcwMGNj
YWJhMmM0MmQ5N2U3NzgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udyrFwf/eSDZZGCQ7Qv145/9S4rdxYxC
SC689T9j1Y8j5Oe8Iu6Vqcy249BgVGUnHhmBMgfobtxzlsEAS4tXs4tsxMBN4lt/
RbQAiDtWOP+ueRZvNFAipeEQFMvcjBOyUiustkon/ezfTT8ywtuVZ3hPizmEw2LE
SWSbGK9O2ougK/j6Dgopl4qMaN+Xh8ZQRq0ZwXc+icpdOXeXMmW1xyZCq60C8jcA
Sl+5/fAUKHvNCkjKe+8TorQkD8ncWWkDPojWhK6LzV6c0hv0sxgbyW/bW6LaOD2r
9Jmq9ZqdIwqEBZeapOzp7oHGyTFzLvXrVO7IrQmyv7M1yi++rz+9crkqJ5HL7Q==
=E6w2
-----END PGP SIGNATURE-----

--7mxbaLlpDEyR1+x6--