From: Anthony Towns <aj@erisian•com.au>
To: Mark Friedenbach <mark@friedenbach•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets
Date: Fri, 29 Sep 2017 14:45:56 +1000 [thread overview]
Message-ID: <20170929044556.GA3996@erisian.com.au> (raw)
In-Reply-To: <359FFE85-86AF-4FBD-9491-3528382E5002@friedenbach.org>
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.
I think CPFP allows this to break: a miner getting paid out of band
would just make the block look like:
(1) 100kB of 5s/byte transactions
(2) 850kB of 35s/byte transactions
(3) 50kB of 95s/byte transactions, miner paying themselves
As long as every transaction in (1) has an output spent in (3), that seems
like it would be perfectly legitimate for CPFP.
I think it would be cheaper overall than the fee refund transactions
as well. People making arrangements with miners directly would have to
pay for block space to cover:
out:
30-40B dest address
30-40B change address
10B cpfp link
in:
36B cpfp txid
then to actual spend their change:
in:
36B+70B txid+idx + witness for change
for a total of 142-162B plus 70B witness, as well as some sort of out of
band payment to the miner (paying fees directly to miners via a lightning
channel, comes to mind).
If I understand your suggestion correctly, it would look like:
coinbase:
30-40B fee overflow payment back to transactor
out:
30-40B dest address
30-40B change address
30-40B fee-overflow output marker
and to spend their change:
in:
36B+70B txid+idx + witness for change
36B+70B txid+idx + witness for fee overflow
for a total of 192-232B plus 140B witness; so that's 40%-50% more block
weight used. The fee overflow would probably be pretty small amounts,
as well, so kind of annoying to actually collect.
If you end up with two change addresses per tx generally, that also seems
like it might it annoyingly easy to link your transactions together
(unless fees end up getting coinjoined or run through satoshidice or
something). If you end up sending lots of fee overflows to a single
address, that links your txes too of course.
A miner might be willing to do that in order to charge a two-part tariff:
ie, a very high "subscription" fee that's paid once a year or similar,
along with very low per-tx fees. The only reason I can think of why
someone would buy a subscription is if the miner's effectively a monopoly
and submitting transactions via the p2p network isn't reliable enough;
the whole point of a two-part tariff is to be as expensive as each user
can bear, so it won't ever be any cheaper.
FWIW, I think reliability-based-price-discrimination might allow higher
mining revenue via having txes with differing fee rates in the same
block: eg if people are happy to pay 100s/byte for confirmation within
30 minutes, and likewise willing to pay 10s/byte for confirmation within
3 hours, and there aren't enough transactions of either type to hit the
block size limit, then a monopoly miner / mining cartel would do better
by accepting 100s/byte txes at any time, while accepting 10s/byte txes
in any given block, but only with about a 1-in-7 chance for any given tx.
Looking at estimatefee.com, there's currently apparently ~200kB of 82s/B
or more transactions, while to fill a 1MB block you'd have to go all the
way down to 2.1s/B -- so if you have to charge all txes at the marginal
fee rate, that's 200kB at 82s/B for 0.16 BTC rather than 1MB at 2.1s/B
for 0.021 BTC.
I think ideally, it would probably be better to let the block weight
limit adjust to deal with high-frequency components to changes in demand,
and have fee rates adjust more slowly to address the long-term trends
in changes to demand: if fee rates only adjust slowly, then they're
(by definition) easily predictable and you don't *have* to have much
concern about getting them wrong. (You'd still need to add the correct
fee at the time you want to publish a pre-signed transaction that was
very old, but CPFP isn't too bad at that).
Cheers,
aj
next prev parent reply other threads:[~2017-09-29 4:46 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
2017-09-29 4:45 ` Anthony Towns [this message]
[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=20170929044556.GA3996@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--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