public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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 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$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=icesby24@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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