From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <elombrozo@gmail.com>) id 1Z3zsg-0002MF-Fz
	for bitcoin-development@lists.sourceforge.net;
	Sun, 14 Jun 2015 04:50:50 +0000
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; 
Received: from mail-pd0-f181.google.com ([209.85.192.181])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z3zsf-0007jv-9R
	for bitcoin-development@lists.sourceforge.net;
	Sun, 14 Jun 2015 04:50:50 +0000
Received: by pdjm12 with SMTP id m12so49288331pdj.3
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 13 Jun 2015 21:50:43 -0700 (PDT)
X-Received: by 10.68.136.101 with SMTP id pz5mr17978759pbb.15.1434257443604;
	Sat, 13 Jun 2015 21:50:43 -0700 (PDT)
Received: from [192.168.1.102] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202])
	by mx.google.com with ESMTPSA id c16sm8136432pdl.61.2015.06.13.21.50.41
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sat, 13 Jun 2015 21:50:42 -0700 (PDT)
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
X-Pgp-Agent: GPGMail 2.5b6
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>
X-Mailer: Apple Mail (2.2098)
X-Spam-Score: -1.1 (-)
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
	(elombrozo[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	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
	0.5 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z3zsf-0007jv-9R
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 14 Jun 2015 04:50:50 -0000


--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--