From: Lucas Clemente Vella <lvella@gmail.com>
To: Nathan Parker <icesby24@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: rewarding fees to next block miner
Date: Sun, 28 Jan 2018 14:54:36 -0200 [thread overview]
Message-ID: <CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com> (raw)
In-Reply-To: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]
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 no
> 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 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
> 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 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.
>
> 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’t 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’t
> 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.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
Lucas Clemente Vella
lvella@gmail.com
[-- Attachment #2: Type: text/html, Size: 4177 bytes --]
next prev parent reply other threads:[~2018-01-28 16:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-27 8:45 [bitcoin-dev] Proposal: rewarding fees to next block miner Nathan Parker
2018-01-27 19:06 ` Gregory Maxwell
2018-01-27 23:48 ` Eric Voskuil
2018-01-28 16:54 ` Lucas Clemente Vella [this message]
2018-01-29 0:46 ` Eric Voskuil
2018-01-29 1:44 ` George Balch
2018-01-29 4:49 ` Eric Voskuil
2018-01-29 21:22 ` Gregory Maxwell
2018-01-29 23:21 ` Eric Voskuil
2018-01-30 1:59 ` Gregory Maxwell
2018-01-30 3:52 ` Eric Voskuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com \
--to=lvella@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=icesby24@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox