To: Lucas Clemente Vella <lvella@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Nathan Parker <icesby24@gmail.com>
References: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
	<CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com>
From: Eric Voskuil <eric@voskuil.org>
Message-ID: <807a2661-b83e-1fc7-3db0-35ee120745bd@voskuil.org>
Date: Sun, 28 Jan 2018 16:46:51 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
	Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="nlOhHaQaIAx3ERUjxEHs5df9ukLH5unD1"
Subject: Re: [bitcoin-dev] Proposal: rewarding fees to next block miner
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--nlOhHaQaIAx3ERUjxEHs5df9ukLH5unD1
Content-Type: multipart/mixed; boundary="5Ssgj5mPhwKCbjwzPVSu2fbXZxNiEfGGY";
 protected-headers="v1"
From: Eric Voskuil <eric@voskuil.org>
To: Lucas Clemente Vella <lvella@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Nathan Parker <icesby24@gmail.com>
Message-ID: <807a2661-b83e-1fc7-3db0-35ee120745bd@voskuil.org>
Subject: Re: [bitcoin-dev] Proposal: rewarding fees to next block miner
References: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
 <CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com>
In-Reply-To: <CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com>

--5Ssgj5mPhwKCbjwzPVSu2fbXZxNiEfGGY
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Miners accept less than the optimal (i.e. highest net fee) set of
transactions all the time. The reason is that it takes too much time to
compute the optimal set. All other things being equal, the miner who is
more efficient at computing a set is more profitable.

Intentionally not accepting the most optimal set possible is a cost, not
a source of increased returns. Miners can raise the historical fee level
by paying this real cost, just as can any other person (by submitting a
competitive-fee transaction). They cannot "recover" this cost. They have
no place of advantage in terms of competing for block space.

Finally, historical prices do not determine future prices. Current
competition for block space determines future prices.

e

On 01/28/2018 08:54 AM, Lucas Clemente Vella via bitcoin-dev wrote:
> If the miner wants to force fees up, why would he fill up a block with
> placeholder high fee transactions, instead of simply cutting off
> transactions paying less fee than he is willing to take? Is there any
> evidence someone is doing such a thing for whatever reason?
>
> 2018-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>>:
>=20
>     Miners can fill their blocks with transactions paying very high fee=
s
>     at no cost because they get the fees back to themselves. They can d=
o
>     this for different purposes, like trying to increase the recommende=
d
>     fee. Here I propose a backwards-compatible solution to this problem=
=2E
>=20
>     The solution would be to reward the fees of the current block to th=
e
>     miner of the next block (or X blocks after the current one). That
>     way, if a miner floods its own block with very high fee
>     transactions, those fees are no longer given back to itself, but to=

>     the miner of future blocks which could potentially be anyone.
>     Flooding blocks with fake txs is now discouraged. However, filling
>     blocks with real transactions paying real fees is still encouraged
>     because you could be the one to mine the block that would claim thi=
s
>     reward.
>=20
>     The way to implement this in a backwards-compatible fashion would b=
e
>     to enforce miners to set an anyone-can-spend output in the coinbase=

>     transaction of the block (by adding this as a rule for verifying ne=
w
>     blocks). The miner of 100 blocks after the current one can add a
>     secondary transaction spending this block's anyone-can-spend
>     coinbase transaction (due to the coinbase needing 100 blocks to
>     mature) and thus claiming the funds. This way, the block reward of =
a
>     block X is always transferred to the miner of block X+100.
>=20
>     Implementing this would require a soft-fork. Since that secondary
>     transaction needs no signature whatsoever, the overhead caused by
>     that extra transaction is negligible.
>=20
>     Possible Downside: When the fork is activated, the miners won=E2=80=
=99t get
>     any reward for mining blocks for a period of 100 blocks. They could=

>     choose to power off the mining equipment for maintenance or to save=

>     power over that period, so the hashrate could drop temporarily.
>     However, if the hashrate drops too much, blocks would take much
>     longer to mine, and miners wouldn=E2=80=99t want that either since =
they want
>     to go through those 100 reward-less blocks as soon as possible so
>     they can start getting rewards from mining again.
>=20
>=20
>=20
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20
>=20
>=20
>=20
> --=20
> Lucas Clemente Vella
> lvella@gmail.com <mailto:lvella@gmail.com>
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20


--5Ssgj5mPhwKCbjwzPVSu2fbXZxNiEfGGY--

--nlOhHaQaIAx3ERUjxEHs5df9ukLH5unD1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJabm77AAoJEDzYwH8LXOFOd3UH/RvS7XbH58gMGzz2qN4SUicN
YaiNqcVOVo6a3jjhKFqhvMawEzh5jNwY0nDglm1JsZicGyByr349NYjuiD7IslOn
VWv/ExpF9THheMfWO1hOFXK5sKPpCFsYggjtZm/JPWEdYWUY0d6L6AHRcAoGm0WM
+yHH17HC6Jg3Y5laD4aYHrHrZdIJsU9ty1uDqW69MaY+7Bq5ydUb3BbZrBMMDuwI
exqBZlRjPR2QcaAFPiLaZiaXRTw2t1PoIxdD0fuHNIfyNuErKL4iarUKEdkkVWxc
L0iv6vmBv4lZXtoDQ0udAZmmm94GyLQYlONtZmTRTyItyAa58nKZLBbUNBUZvpI=
=2xab
-----END PGP SIGNATURE-----

--nlOhHaQaIAx3ERUjxEHs5df9ukLH5unD1--