From: Peter Todd <pete@petertodd•org>
To: Mark Friedenbach <mark@friedenbach•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets
Date: Thu, 28 Sep 2017 23:02:25 -0400 [thread overview]
Message-ID: <20170929030225.GA12614@savin.petertodd.org> (raw)
In-Reply-To: <FAD5BE01-52B5-49C6-B018-47BF234A5EF2@friedenbach.org>
[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]
On Thu, Sep 28, 2017 at 07:45:02PM -0700, Mark Friedenbach wrote:
>
>
> > On Sep 28, 2017, at 7:02 PM, Peter Todd <pete@petertodd•org> wrote:
> >
> >> On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin-dev wrote:
> >> Unlike other proposed fixes to the fee model, this is not trivially
> >> broken by paying the miner out of band. If you pay out of band fee
> >> instead of regular fee, then your transaction cannot be included with
> >> other regular fee paying transactions without the miner giving up all
> >> regular fee income. Any transaction paying less fee in-band than the
> >> otherwise minimum fee rate needs to also provide ~1Mvbyte * fee rate
> >> difference fee to make up for that lost income. So out of band fee is
> >> only realistically considered when it pays on top of a regular feerate
> >> paying transaction that would have been included in the block anyway.
> >> And what would be the point of that?
> >
> > This proposed fix is itself broken, because the miner can easily include *only*
> > transactions paying out-of-band, at which point the fee can be anything.
>
> And in doing so either reduce the claimable income from other transactions (miner won’t do that), or require paying more non-rebateable fee than is needed to get in the block (why would the user do that?)
>
> This is specifically addressed in the text you quoted.
I specifically outlined a scenario where that text isn't relevant: *all*
transaction in a block can be paying out of band.
> > Equally, miners can provide fee *rebates*, forcing up prices for everyone else
> > while still allowing them to make deals.
>
> Discounted by the fact rebates would not be honored by other miners. The rebate would have to be higher than what they could get from straight fee collection, making it less profitable than doing nothing.
You're making the incorrect assumption that all transactions have to be
broadcast publicly; they don't.
> > Also, remember that you can pay fees via anyone-can-spend outputs, as miners
> > have full ability to control what transactions end up spending those outputs.
>
> You’d still have to pay the minimum fee rate of the other transactions or you’d bring down the miners income. Otherwise this is nearly the same cost as the rebate fee, since they both involve explicit outputs claimed by the miner, but the rebate goes back to you. So why would you not want to do that instead?
>
> A different way of looking at this proposal is that it creates a penalty for out of band payments.
It certainly does not. It simply adds another level of complexity and overhead
to the out-of-band payment situation, which is not desirable. If we can't
eliminate out of band payments entirely, we do not want to make the playing
field of them even more unbalanced than it already is.
This is a typical academic proposal that only considers first order effects
while ignoring second order effects.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2017-09-29 3:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-29 1:06 Mark Friedenbach
2017-09-29 1:53 ` Matt Corallo
2017-09-29 2:09 ` Nathan Wilcox
2017-09-29 2:10 ` Peter Todd
2017-09-29 2:17 ` Nathan Wilcox
2017-09-29 3:30 ` Mark Friedenbach
2017-09-29 2:02 ` Peter Todd
2017-09-29 2:45 ` Mark Friedenbach
2017-09-29 3:02 ` Peter Todd [this message]
2017-09-29 4:45 ` Anthony Towns
[not found] <CAEgR2PGCZ=F85yjAbZgC6NtzhpdgBL3n4M2jowN12wJ7x-Ai1A@mail.gmail.com>
[not found] ` <CAEgR2PGrxDQE0k8WX4XXz9GN-RAL6JB51ST9Hdz=ba36gRCa6A@mail.gmail.com>
[not found] ` <CAEgR2PFjt=ihzRBhNXbHTAJz1R+3vz8o-zRZkDA3iBo39x9cTQ@mail.gmail.com>
[not found] ` <CAEgR2PFfSjJjkTYq+DAmTzmkHPxqhn6fUDoXTzrRebz+OoUgqw@mail.gmail.com>
[not found] ` <CAEgR2PG5ZueHKDXbsPDEjQG7xAYBa_JAtPZo9n1V2=STC1srpA@mail.gmail.com>
[not found] ` <CAEgR2PGPQ1e9SmoWOS3V+N9v+OWiM4g3nPN3d9urc+DfkWEJ7A@mail.gmail.com>
[not found] ` <CAEgR2PEKkHH6+Sh8cQGF83-s1tpwQZgd0fiuNz_xyWu0mUPfCA@mail.gmail.com>
[not found] ` <CAEgR2PEyWFO1RFohVEpcb-M7aM-8xjCFvDPeJPD4zF4yTCyZ0A@mail.gmail.com>
2017-09-29 10:43 ` Daniele Pinna
2017-09-29 12:50 ` Alex Morcos
2017-09-29 15:22 ` Mark Friedenbach
2017-09-30 3:53 ` Jorge Timón
2017-09-30 3:55 ` Jorge Timón
2017-09-30 8:54 ` Gregory Maxwell
2017-09-30 0:47 ` Gregory Maxwell
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=20170929030225.GA12614@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=mark@friedenbach$(echo .)org \
/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