MIME-Version: 1.0
In-Reply-To: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
References: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
From: Lucas Clemente Vella <lvella@gmail.com>
Date: Sun, 28 Jan 2018 14:54:36 -0200
Message-ID: <CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com>
To: Nathan Parker <icesby24@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114364243eec330563d8fd94"
Subject: Re: [bitcoin-dev] Proposal: rewarding fees to next block miner
Precedence: list

--001a114364243eec330563d8fd94
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

> Miners can fill their blocks with transactions paying very high fees at n=
o
> cost because they get the fees back to themselves. They can do this for
> different purposes, like trying to increase the recommended fee. Here I
> propose a backwards-compatible solution to this problem.
>
> The solution would be to reward the fees of the current block to the mine=
r
> of the next block (or X blocks after the current one). That way, if a min=
er
> 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 coul=
d
> 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 clai=
m
> this reward.
>
> The way to implement this in a backwards-compatible fashion would be 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 new
> blocks). The miner of 100 blocks after the current one can add a secondar=
y
> 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 t=
he
> miner of block X+100.
>
> Implementing this would require a soft-fork. Since that secondary
> transaction needs no signature whatsoever, the overhead caused by that
> extra transaction is negligible.
>
> Possible Downside: When the fork is activated, the miners won=E2=80=99t g=
et 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 bloc=
ks
> as soon as possible so they can start getting rewards from mining again.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


--=20
Lucas Clemente Vella
lvella@gmail.com

--001a114364243eec330563d8fd94
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">If the miner wants to force fees up, why would he fill up =
a block with placeholder high fee transactions, instead of simply cutting o=
ff transactions paying less fee than he is willing to take? Is there any ev=
idence someone is doing such a thing for whatever reason?<br></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">2018-01-27 6:45 GMT-02:00=
 Nathan Parker via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">
<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:&quot;Calibri&quot;,sans-serif">Miners
 can fill their blocks with transactions paying very high fees at no=20
cost because they get the fees back to themselves. They can do this for=20
different
purposes, like trying to increase the recommended fee. Here I propose a
backwards-compatible solution to this problem.<span></span></p>

<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:&quot;Calibri&quot;,sans-serif">The solution would be t=
o reward the fees of the current
block to the miner of the next block (or X blocks after the current one). T=
hat
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 dis=
couraged.
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 =
this
reward.<span></span></p>

<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:&quot;Calibri&quot;,sans-serif">The way to implement th=
is in a backwards-compatible fashion
would be to enforce miners to set an anyone-can-spend output in the coinbas=
e
transaction of the block (by adding this as a rule for verifying new blocks=
). The
miner of 100 blocks after the current one can add a secondary transaction
spending this block&#39;s anyone-can-spend coinbase transaction (due to the=
 coinbase
needing 100 blocks to mature) and thus claiming the funds. This way, the bl=
ock
reward of a block X is always transferred to the miner of block X+100.<span=
></span></p>

<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:&quot;Calibri&quot;,sans-serif">Implementing this would=
 require a soft-fork. Since that
secondary transaction needs no signature whatsoever, the overhead caused by
that extra transaction is negligible.</p><p class=3D"MsoNormal" style=3D"ma=
rgin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:&quot;Calibri&=
quot;,sans-serif"><span></span></p>

<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:&quot;Calibri&quot;,sans-serif">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 of=
f
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, b=
locks would
take much longer to mine, and miners wouldn=E2=80=99t want that either sinc=
e they want
to go through those 100 reward-less blocks as soon as possible so they can =
start
getting rewards from mining again.</p>

<br></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature" data-smartmail=3D"gmail_signature">Lucas Clemente Vella<br><a h=
ref=3D"mailto:lvella@gmail.com" target=3D"_blank">lvella@gmail.com</a></div=
>
</div>

--001a114364243eec330563d8fd94--