public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <greg@xiph.org>
To: William Morriss <wjmelements@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Idea: Marginal Pricing
Date: Thu, 30 Nov 2017 11:40:54 +0000	[thread overview]
Message-ID: <CAAS2fgRbEeUa-CB3NTN-kSZBPBbzax+72iou1uShcJ6=i7mJ2g@mail.gmail.com> (raw)
In-Reply-To: <CADpM8jq_-JxCmLiCPMG2ZVuYxZH7KOCyyMaQnBay18PQLPvmRg@mail.gmail.com>

On Thu, Nov 30, 2017 at 6:13 AM, William Morriss via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I believe this OOB scenario is imaginary. Either it would be more profitable

Out of band fees are a reality even today-- and have for most of
Bitcoin's life--, without a system that has any particular incentive
for them.

> for a miner to mine fairly, or cheaper for the end-user to pay the fee
> in-band. Consider MINFEE to the the effective fee paid for the block mined
> by the OOB-incentivized miner. Consider MARKFEE to the the market fee
> collected by non-OOB-incentivized miners. Call the OOB effective tx fee OOB.
> Then,
> For a user to prefer OOB: MINFEE+OOB<MARKFEE
> For a miner to prefer OOB: MINFEE+OOB>MARKFEE
> It is impossible for both scenarios to be true. As previously argued by Mark
> Friedenbach, the system disincentivizes OOB tx fees.

This kind of analysis seems to imagine that a single decision maker is
making a globally optimal decision and that also people are somehow
forced to only make one choice. Both are untrue in this case (and most
other economic circumstances). Instead, participants can take the best
of multiple choices and will often act locally for their own best
interest even when it reduces revenue for their industry in total.

Concretely: as a user with competent wallet software, I would be
automatically drafting two transactions-- one paying OOB and one
paying min fee, at equivalent expected rates.  Miners would construct
blocks which locally maximized their revenue.   It is far from clear
that use of the minfee scheme is an equilibrium-- in fact I think it
is clearly not an equilibrium: a user that writes both transactions
will always pay equal or less fees for the transactions where they do
both (even if all users doing this causes users collectively to pay
higher fees), a miner who considers both will always make equal or
greater fee income on a block by block basis (even if it lowers miner
income collectively when all do this).

(If it were in fact preferred by users and miners alike: why doesn't
it already exist?  Since the existence of OOB fees cannot be
eliminated, as far as we know, any use of MINFEE would be inherently
voluntary-- so in one sense we already 'have' voluntary minfee, but no
one uses it.)


Ignoring the possibility of evasion, there are some other concerns
that you might want to consider:

I believe the idea converts variance in fee willingness into variance
in capacity for the network.  If rich uncle bill wants to waste money
with uneconomically high fees, with a constant flow of transactions,
he'll effectively knock out a large number of participants.  You could
argue that bill could spend those same fees in spam to displace the
same amount of transactions while also using more capacity; but I
UncleBill isn't trying to attack the capacity of the system. It's just
collateral damage.  I worry also about related strategies that arise
in that world: For example, lets imagine that world consisted of a
couple unclebill who will pay high fees, and the unwashed masses that
will not and pay a much lower consistent feerate.   Honest conformance
with your protocol would result in miners either processing only the
UncleBill txn or processing all of them at the lower rate, whichever
is more profitable.  Super-rational behavior might be for a majority
of hashpower to collude to only permit high fee-rate transactions
every other block and only permit low feerate in the others, and then
the network processes all unclebills in one block (at full rate), and
all the unwashed in the others.  From a fee perspective it arguably
isn't any worse than today, but I believe it significantly handicaps
your capacity limiting argument.

> wherein there is no penalty for arbitrarily favoring individual transactions with lower fees

Nor does a MINFEE system; since the user can near costlessly construct
as many variations of their transaction as they like.

> The hashpower of individual miners is not impressive compared to the entire network,

That is unfortunately not the reality of Bitcoin today.


  reply	other threads:[~2017-11-30 11:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-30  0:47 [bitcoin-dev] BIP Idea: Marginal Pricing William Morriss
2017-11-30  2:38 ` Ben Kloester
2017-11-30  6:13   ` William Morriss
2017-11-30 11:40     ` Gregory Maxwell [this message]
2017-11-30 12:03     ` Eric Voskuil
2017-11-30  9:37   ` Federico Tenga
2017-11-30  5:52 ` Chenxi Cai
2017-11-30  6:05   ` William Morriss
     [not found]     ` <CY4PR1201MB0197936CBE467B38DCC26DC986380@CY4PR1201MB0197.namprd12.prod.outlook.com>
2017-11-30 16:15       ` Chenxi Cai
     [not found] ` <CAAS2fgS5jiNCmdwEt3YtZMJ0SfhC8Hw1eXr_0Vo5AQhYv7bJfg@mail.gmail.com>
2017-11-30  9:12   ` Gregory Maxwell
2017-12-01  7:58 ` Ryan J Martin
2017-12-02  3:55 ` Damian Williamson

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='CAAS2fgRbEeUa-CB3NTN-kSZBPBbzax+72iou1uShcJ6=i7mJ2g@mail.gmail.com' \
    --to=greg@xiph.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=wjmelements@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