Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.171 as permitted sender)
	client-ip=209.85.220.171;
	envelope-from=stephencalebmorse@gmail.com;
	helo=mail-qk0-f171.google.com; 
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Stephen <stephencalebmorse@gmail.com>
In-Reply-To: <20150612181153.GB19199@muck>
Date: Sun, 14 Jun 2015 00:16:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B60EFC7-60C9-470A-9022-F6FA5566CF11@gmail.com>
References: <20150612181153.GB19199@muck>
To: Peter Todd <pete@petertodd.org>
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] User vote in blocksize through fees
Precedence: list

While this idea is theoretically interesting because it involves many stakeh=
olders, rather than just miners, I think in practice this would not work ver=
y 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 su=
pply, these fees are marginal compared to the block size subsidy. If this pr=
oposal were actually implemented, I think miners would vote for whatever the=
y think is best, and users would not contradict them with their votes to ens=
ure a fast confirmation time. Users are incentivized to be in agreement with=
 miners because the miners provide them with the confirmations they need, bu=
t fees do not provide a great incentive for miners to be in agreement with u=
sers, and likely won't for some time.=20

Best,=20
Stephen=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
> --=20
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
> --------------------------------------------------------------------------=
----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development