From: "Warren Togami Jr." <wtogami@gmail•com>
To: Luzius Meisser <luzius.meisser@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fee smoothing
Date: Tue, 26 Jan 2016 18:45:51 -0800 [thread overview]
Message-ID: <CAEz79PrVfdy5g=XcajMvKtCMUCtG44A8N_UAM8NrzZL00cvjiA@mail.gmail.com> (raw)
In-Reply-To: <CAMuv0Z2gjNKc52UFV2n3H1ckt30chS7=fEUwO8OpfU1Vg7Ayzw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4801 bytes --]
On Tue, Jan 26, 2016 at 9:42 AM, Luzius Meisser via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.*
I do not believe your logic is correct. Reducing the marginal benefit of
including an additional transaction is problematic because it
simultaneously increases the orphan risk while it reduces the reward. 90%
of the fee going to the next block would also create new incentive problems
like mining an empty block to minimize the chance of losing 90% of the fees
from the previous block to an orphan. Another major issue with mandatory
sharing is if the miner doesn't want to share, nothing stops them from
taking payment out-of-band and confirming the transaction with little or no
fees visible in the block.
I had been thinking recently about fee deferral for a different reason. In
the future when the subsidy is much smaller in proportion to the fees,
there may be little incentive to confirm on top of someone else's block in
cases when the expected value of replacing the current tip is higher. I
think smoothing fees between the current and subsequent 5 blocks (for
example) might reduce the incentive of this type of behavior. The main
risk here might be in weakening too far the incentive of adding more
transactions to the current block, as I believe your 10% current and 90%
subsequent reward split would do. I think my idea of a mandatory split
between six blocks might also be a failure because of the high incentive to
conduct out-of-band payments.
> Benefits:
>
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.
>
While I don't agree with the rest of your logic, it is agreeable that you
care about aligning the miner's supply incentives with the global marginal
cost. If you believe that is an important goal, you might like the Flex
Cap approach as presented by Mark Friedenbach at Scaling Bitcoin Hong Kong.
Under the general idea of the Flex Cap approach block size is no longer
fixed, it can be bursted higher on a per-block basis if the miner is
willing to defer a tiny portion of the current block subsidy to pay out to
the miner of later blocks. If conditions are such that there is genuine
demand then some are willing to pay higher fees for time preference. Some
formula would balance the cost and reward in some manner like: add the
value of newly included fees, subtract the expected marginal cost of orphan
risk, then subtract the portion of subsidy deferred. Flex cap has periodic
block size retargets to allow for a temporary limit to rise or fall to
something resembling actual market demand. This temporary limit is never a
"wall" that can be hit as miners can choose to burst past it if the cost is
worth the reward.
Flex Cap is an area of ongoing research that I strongly believe would
benefit Bitcoin in the long-term. For this reason it requires careful
study and simulations to figure out specifics.
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.
>
You seem to not recognize that orphan cost is a major reason why pools are
attractive.
Warren Togami
[-- Attachment #2: Type: text/html, Size: 6027 bytes --]
next prev parent reply other threads:[~2016-01-27 2:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 17:42 Luzius Meisser
2016-01-27 2:45 ` Warren Togami Jr. [this message]
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='CAEz79PrVfdy5g=XcajMvKtCMUCtG44A8N_UAM8NrzZL00cvjiA@mail.gmail.com' \
--to=wtogami@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luzius.meisser@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