public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <greg@xiph.org>
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: Sat, 27 Jan 2018 19:06:41 +0000	[thread overview]
Message-ID: <CAAS2fgSzx_beEQqPOdoRJRVMSk0JNT6LGk0fHTktVSCU7sH1cA@mail.gmail.com> (raw)
In-Reply-To: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>

Not incentive compatible. Miners would prefer to include transactions
paying fees via alternative mechanisms (anyone can spend outputs,
direct pay to miner outputs, or completely out of band), if they even
paid attention to internal fees at all they would give a lot more
weight to direct payment fees. Users would accordingly pay much lower
fees if they used these alternatives instead of directly, so the
equlibrium state is almost everyone bypassing.   Bypass fee mechenisms
have been supported by miners since 2011 too, so it isn't just
conjecture.

On Sat, Jan 27, 2018 at 8:45 AM, Nathan Parker via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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
>


  reply	other threads:[~2018-01-27 19:06 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 [this message]
2018-01-27 23:48   ` Eric Voskuil
2018-01-28 16:54 ` Lucas Clemente Vella
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=CAAS2fgSzx_beEQqPOdoRJRVMSk0JNT6LGk0fHTktVSCU7sH1cA@mail.gmail.com \
    --to=greg@xiph.org \
    --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