public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: oscar <petdog@gmail.com>
To: Damian Williamson <willtech@live.com.au>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] what do you think about having a maximum fee rate?
Date: Sun, 24 Dec 2017 14:59:23 +0100	[thread overview]
Message-ID: <CAMjoVH+qEOgMSLmoJ+1qcbiKJ0L2pcr_48Sn5AOttXg+hReHxg@mail.gmail.com> (raw)
In-Reply-To: <PS2P216MB0179A68450E8AA5E4E77915B9D000@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>

On Sun, Dec 24, 2017 at 2:13 AM, Damian Williamson <willtech@live.com.au> wrote:
> If all transactions pay the proposed max then fee there are still going to
> be an awful lot of never confirming transactions once the transaction
> bandwidth limit is surpassed

Yes obviously. That would be the unequivocal sign that it's time to
bump the block size.

Why not just bump now then? My main worry is that wasting space should
not be profitable for anybody. If it is, it's an encouragement to
waste space, and imho we have such an encouragement in place.

Fees should be allowed to get high enough as to discourage wasteful
usage of blockchain space, but not high enough as to make it
*profitable* to waste space, if you are a sufficiently big miner. The
fact that it is now profitable, and that such big miners exist, makes
me believe that a lot of blockchain space is wasted on purpose.

> This is what I have been working on as an alternative:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015371.html

I read your proposal, but the value that I see in mine is that it is
extremely simple. It would be trivial to have nodes stop propagating
transactions with fees over the max, and miners can trivially reject
blocks where coinbase > block reward + max fee rate * block size, if
they are on board.

It would also be quite simple to adapt wallets, given that the fee
range is fixed. If nodes had an rpc method giving you some mempool
statistics, it would also be simple to correctly recommend fees
according to the time expected to first confirmation.

Sure, at some point, if there is real congestion, it would just start
always recommending the max fee. Again, this means that it's time to
bump the block size. I think this is ultimately unavoidable, but I
understand the reservations, and I agree that increasing the block
size without incentivizing efficient usage would be counterproductive.
I think the current fees are certainly incentivizing efficient usage
to users, but not to miners. My (maybe naive) idea is that it would be
possible to find an appropriate maximum fee value that would move
things towards efficient usage by both users and big miners.

This would work very well if coupled with some proposals I've read to
slowly increase the block size with a process similar to difficulty
adjustment, like adding 100kb if 95% of the last 2016 blocks were
full. Without max fees, a big miner could easily destroy this strategy
by always applying just enough pressure as to always skyrocket fees
and profit, while the blocksize slowly increases.

The way I see it, unbounded fees together with small blocks and big
miners introduce a terrible flaw in the incentives equilibrium.
I would really like an open discussion on this topic.


      reply	other threads:[~2017-12-24 13:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-22  8:26 [bitcoin-dev] what do you think about having a maximum fee rate? oscar
2017-12-24  1:13 ` Damian Williamson
2017-12-24 13:59   ` oscar [this message]

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=CAMjoVH+qEOgMSLmoJ+1qcbiKJ0L2pcr_48Sn5AOttXg+hReHxg@mail.gmail.com \
    --to=petdog@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=willtech@live.com.au \
    /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