Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.181 as permitted sender)
	client-ip=209.85.192.181; envelope-from=elombrozo@gmail.com;
	helo=mail-pd0-f181.google.com; 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_1B245B00-F31D-4FFF-9BD4-07A62E603D63";
	protocol="application/pgp-signature"; micalg=pgp-sha512
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <2B60EFC7-60C9-470A-9022-F6FA5566CF11@gmail.com>
Date: Sat, 13 Jun 2015 21:50:39 -0700
Message-Id: <A99C4EDC-8F2B-4B51-913A-BD72B90BF1A4@gmail.com>
References: <20150612181153.GB19199@muck>
	<2B60EFC7-60C9-470A-9022-F6FA5566CF11@gmail.com>
To: Stephen <stephencalebmorse@gmail.com>
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] User vote in blocksize through fees
Precedence: list


--Apple-Mail=_1B245B00-F31D-4FFF-9BD4-07A62E603D63
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

What Stephen said is very much along the same lines of my earlier =
critique. This voting mechanism would be all but unusable to most =
endusers without some pretty elaborate tools=E2=80=A6and unless users =
are willing to pay substantially higher fees than they=E2=80=99re =
currently paying, their votes will not really count all that much. And =
it=E2=80=99s not all that clear that most users would really be able to =
make very rational economic decisions even having elaborate tools. More =
likely, a small group would figure out ways to exploit this for their =
own benefit - at everyone else=E2=80=99s expense.

- Eric Lombrozo


> On Jun 13, 2015, at 9:16 PM, Stephen <stephencalebmorse@gmail.com> =
wrote:
>=20
> While this idea is theoretically interesting because it involves many =
stakeholders, rather than just miners, I think in practice this would =
not work very well. Users don't want to worry about this kind of =
technicality, they just want to be able to make a transaction and have =
it be processed.
>=20
> In addition, while this gives stakeholders some weight with the fees =
they supply, these fees are marginal compared to the block size subsidy. =
If this proposal were actually implemented, I think miners would vote =
for whatever they think is best, and users would not contradict them =
with their votes to ensure a fast confirmation time. Users are =
incentivized to be in agreement with miners because the miners provide =
them with the confirmations they need, but fees do not provide a great =
incentive for miners to be in agreement with users, and likely won't for =
some time.
>=20
> Best,
> Stephen
>=20
>=20
>=20
>=20
>> On Jun 12, 2015, at 2:11 PM, Peter Todd <pete@petertodd.org> wrote:
>>=20
>> Jeff Garzik recently proposed that the upper blocksize limit be =
removed
>> entirely, with a "soft" limit being enforced via miner vote, recorded =
by
>> hashing power.
>>=20
>> This mechanism within the protocol for users to have any influence =
over
>> the miner vote. We can add that back by providing a way for =
transactions
>> themselves to set a flag determining whether or not they can be =
included
>> in a block casting a specific vote.
>>=20
>> We can simplify Garzik's vote to say that one of the nVersion bits
>> either votes for the blocksize to be increased, or decreased, by some
>> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
>> nVersion bit in transactions themselves, also voting for an increase =
or
>> decrease. Transactions may only be included in blocks with an
>> indentical vote, thus providing miners with a monetary incentive via
>> fees to vote according to user wishes.
>>=20
>> Of course, to cast a "don't care" vote we can either define an
>> additional bit, or sign the transaction with both versions. Equally =
we
>> can even have different versions with different fees, broadcast via a
>> mechanism such as replace-by-fee.
>>=20
>>=20
>> See also John Dillon's proposal for proof-of-stake blocksize voting:
>>=20
>> =
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg=
02323.html
>>=20
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>> =
--------------------------------------------------------------------------=
----
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
> =
--------------------------------------------------------------------------=
----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--Apple-Mail=_1B245B00-F31D-4FFF-9BD4-07A62E603D63
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVfQgfAAoJEJNAI64YFENUCAwQAIdCv4X1+AHi3b7WetVCpasl
4Xgfwik9JFlTCb7Fm//ogvoBPdeH3WQtTQTCmJxBKtEdpiQcDFQcgIfa3z33HifY
DtLVXUxmU0riTdaJEGK+RCiR7uT0u/Y0UhSsAuqFYJU+TdUP1/OGJPCOu2u19SLy
q5Oz0OwpdzayyzgmkjjNeDJkh8AdFWaaNQkltTfofuUXLSPj8F8RLGhEqbHgBp/S
eMZ2GMqyhBhTTLgsyq82qNX+cGOdrtqmAQnc7KdpykiQKeDUVHfzWvbxRY3i/WSt
R82iMJGz+I3V0GwXzzM+Rkd3X7YIyak/lUFQQTRW06GxFtU0BjnEyTjNXAcuCfSR
XaHhK9EWNAw+CuOQi0eZeigUr5aaJWA59qeMAYy+VZxEv18oX8reZUMRxpHgEUIZ
lnHLeaWLLYOXg9uuYYCis7j3vcrT4n/ocNYCoOumU0rSU4kA8XyKVgnj8UDDHYJk
hu7cUah6E2e/tUdz9A40siX8nBVRx0/ocecY6waJCVWqAZANc5NeRD8A80bqlTUG
4OgD+pNteinmaw3HEDAbpTBt/rXEOHNF1nF6G355cHRoUb+nPzeqpoK/MEo3DoUJ
G7XX+3MgNf9KY6iMlwMDcoeZ2oomJlrESq8wk9VIxKAxsbvdf30FjexczKS+kW2i
yuafT8YzEa/V1UsSo39e
=/Hxu
-----END PGP SIGNATURE-----

--Apple-Mail=_1B245B00-F31D-4FFF-9BD4-07A62E603D63--