public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luzius Meisser <luzius.meisser@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Fee smoothing
Date: Tue, 26 Jan 2016 18:42:25 +0100	[thread overview]
Message-ID: <CAMuv0Z2gjNKc52UFV2n3H1ckt30chS7=fEUwO8OpfU1Vg7Ayzw@mail.gmail.com> (raw)

This post serves to convince you of the economic benefits of smoothing
the payout of fees across blocks. It incentivizes decentralization and
supports the establishment of a fee market.

Idea: currently, the total amount of fees collected in a block is paid
out in full to whoever mined that block. I propose to only pay out,
say, 10% of the collected fees, and to add the remaining 90% to the
collected fees of the next block. Thus, the payout to the miner
constitutes a rolling average of collected fees from the current and
past blocks. This reduces the marginal benefit of including an
additional transaction into a block by an order of magnitude and thus
aligns the incentives of individual miners better with those of the
whole network. As a side-effect, the disadvantage of mining with a
slow connection is reduced.

Example: currently, given a transaction with a fee of 1000 Satoshis
and global processing cost per transaction of 5000 Satoshis, an
individual miner would still include the transaction if it costs him
500 Satoshis to do so, as the remaining burden of 4500 Satoshis is
carried by others (a classic externality). However, with fee
smoothing, the immediate benefit of including that particular
transaction is reduced to 100 Satoshis, aligning the economic
incentives of the miner better with the whole network and leading the
miner to skip it. Generally, the fraction that is paid out immediately
(here 10%) can be used to adjust the incentive, but not arbitrarily.

Benefits:
1. The disadvantage of mining with a slow connection is reduced by an
order of magnitude. If it takes 30 seconds to download the latest
block, a miner loses 5% of the potential income from fees as he does
not know yet which transactions to include in the next block. With fee
smoothing, that loss is reduced to 0.5% as he would still earn 90% of
the average fees per block by mining an empty one based on the latest
header.
2. This is a step towards a free fee market. In an ideal market,
prices form where supply and demand meet, with the fees asymptotically
approaching the marginal costs of a transaction. Currently, supply is
capped and only demand can adjust. Should we ever consider to let
miners decide about supply, it is essential that their marginal
benefit of including an additional transaction is aligned with the
global marginal cost incurred by that additional transaction. Fee
smoothing is a step in this direction.
3. The incentive to form mining pools is reduced. Currently,
solo-mining yields a very volatile income stream due to the random
nature of mining, leading to the formation of pools. This volatility
will increase to even higher levels once the amount of Bitcoins earned
per block is dominated by (volatile) collected fees and not by
(constant) freshly minted coins, thus increasing the economic pressure
to join a large pool. Fee smoothing reduces that volatility and
pressure.

Problems: touching anything related to fee distribution is a political
minefield. This proposal probably requires a hard fork. Its technical
feasibility was only superficially verified.

This is my first post to this list and I am looking forward to your
comments. In case this proposal is received well, I plan to
specify/implement the idea more formally in order to kick off the
usual process for improvements.

-- 
Luzius Meisser
President of Bitcoin Association Switzerland
MSc in Computer Science and MA in Economics


             reply	other threads:[~2016-01-26 17:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-26 17:42 Luzius Meisser [this message]
2016-01-27  2:45 ` [bitcoin-dev] Fee smoothing Warren Togami Jr.
2016-01-27 10:12   ` Luzius Meisser
2016-01-27 23:11     ` Warren Togami Jr.
2016-01-28 20:16     ` Luzius Meisser

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='CAMuv0Z2gjNKc52UFV2n3H1ckt30chS7=fEUwO8OpfU1Vg7Ayzw@mail.gmail.com' \
    --to=luzius.meisser@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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