1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E6714C48
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Nov 2017 11:40:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f176.google.com (mail-ua0-f176.google.com
[209.85.217.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6890414F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Nov 2017 11:40:55 +0000 (UTC)
Received: by mail-ua0-f176.google.com with SMTP id q13so5504902uaq.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Nov 2017 03:40:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=BaCMpPnMIjXfVmtLSo/aeoWktMPCvbJS7dXgeOxxoTY=;
b=LUnYTVPySOuIUq4m1g5uXnqJtFUs/2QU0WL+G7UGvzEyztsV4IT19N0k7GKS9dB9hH
F6sNl1qCeFTtam+P6dCDDOoNkj+4HBqdFEQ9Jn7/B81hSez4w7lCLE2b1XTTAnAakbtW
sP5QArsHbtV7vGA1DoOcuXQECNoOGwwBFaPH1RN8n19Q3cQx9gDPwsypLfm7hITpBTac
7/IcVqdtnPQUbgI3TT3IOsN8DIiQGNuTPBna72JQa3HOMVdrsLUZtFjwK4uWoLVonJP6
3YsJDCmByTGwVMXaQfHbDMI2n7CPHVlu0Kd2NwI6Ox1dI3PZRSaKydybkvdiiyojJ26N
euKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=BaCMpPnMIjXfVmtLSo/aeoWktMPCvbJS7dXgeOxxoTY=;
b=IPuhpGBXVO97pTyZztopcdYqRVZAc+FNs1pVzxdwK+laEg3WYbvAra20FiQIkmI3YP
g/awXw1YsNs4wTP3BE9GjlDUPDO6b6Bj5bAB/02BP9TmBq5bPcZuVFcjQP2OMIGHM4nQ
HeEg8AVaqvUHYufGn4TZnkMtAcGlsqXgl/GBZuYYRdXeuNTBVMYrEwgvDtPhzPPl5PL5
FvRCxG36tR8zrWEwbeagyy/U1Wri56nigiD+2/sRCBq3yNMrLXp+Gj2qBT0tmZSJ+Vlv
V4/BUSuCI+udb+27xbjEqRyMIsdPVIC0+Pb8hM+LIoVmwZ7eHnpHCc/X96kkXA6v1Gk5
ocKA==
X-Gm-Message-State: AKGB3mLf4nJ/tip3oa9Ee3DMbLlMIRZA4OD4CEA6a81AMto+ClXIJLam
Yh/RZo0fTP0wLiS9ZTT7cxqMP5hoS7OI478+Hwg09w==
X-Google-Smtp-Source: AGs4zMajN3Z5wMcHGtC2t7yofD6STqFMO51QnRGQ/v19sZCr15HnQ6ixhohnXCwNXgUPdZbCgILk3OHAHGWrBbf9CGU=
X-Received: by 10.176.16.67 with SMTP id g3mr1788249uab.109.1512042054416;
Thu, 30 Nov 2017 03:40:54 -0800 (PST)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.85.148 with HTTP; Thu, 30 Nov 2017 03:40:54 -0800 (PST)
In-Reply-To: <CADpM8jq_-JxCmLiCPMG2ZVuYxZH7KOCyyMaQnBay18PQLPvmRg@mail.gmail.com>
References: <CADpM8jr_RrbPXLx6Up8HMW-fv=noFLjy817dfsFdYTg216Pu7w@mail.gmail.com>
<CANgJ=T8ZHbC4R3Rs5kZG8HfGs8810jj01WN4Ssiketej0md4kA@mail.gmail.com>
<CADpM8jq_-JxCmLiCPMG2ZVuYxZH7KOCyyMaQnBay18PQLPvmRg@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Thu, 30 Nov 2017 11:40:54 +0000
X-Google-Sender-Auth: ADBUjG8YpSZJrIX7nwFhMC6qGhc
Message-ID: <CAAS2fgRbEeUa-CB3NTN-kSZBPBbzax+72iou1uShcJ6=i7mJ2g@mail.gmail.com>
To: William Morriss <wjmelements@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP Idea: Marginal Pricing
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Nov 2017 11:40:56 -0000
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.
|
