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
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
Return-Path: <wjmelements@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BC2F2BBD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Nov 2017 06:13:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb0-f179.google.com (mail-yb0-f179.google.com
[209.85.213.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1123EE4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Nov 2017 06:13:16 +0000 (UTC)
Received: by mail-yb0-f179.google.com with SMTP id s46so2305457ybi.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Nov 2017 22:13:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=RlA2SZO8eXPu7Fn6hrVkVhhOSJUd66sVQ8gm3KztAcY=;
b=cqynYev9JJ2teeHgQzOHlHzHYLt6YTiAbiz0esrQ1sa3VRXb/V7LpCWw160w66YQE6
g8aDxNaTzQ7CkVFf+EuYBHQ5JwI0HdBC8FSn2BcmLCtmZbSv6gZSXE53FnYcrMvrgCGp
9oPLiNFFXp/baQmbAuEmHgerY40UmpTv+87SHpjCSgNhy5ncgIOSYE8QtXXr8SlkC+Ul
quQN8GXG+nKuSGIpW+zLUwtV2eVyghlLo6MugH7HczjbAglNAYSfhD8PvH8YJFgsuiN3
JoPwT0WevUxsMfJmHpxZs6w/xtApaJjEEflfL9U90jPaAhsv+5jbWB5QMOBI+JraC9mO
jKxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=RlA2SZO8eXPu7Fn6hrVkVhhOSJUd66sVQ8gm3KztAcY=;
b=fJZni9bswQ9E3UsEHoJnq//tKYd8G00vp1EE89Nk+3l68NoA1h8hdEYGf2CdpOqPsh
/P/JvGc4r4vxfznvaxfmQKNxCGH5+247tc6dvC2MakFsjKem62NFP2sCGA4vi3ms4qGD
euiPbvv+jihRubFKJzON2gS74+pP+iw8DK/T55wzH2JmU5bZTBCy0ZZOFsfOCzdVQ2/t
sDvmVwZBHJVP1oJFLIcBpYjgyNo8WDYqo82xC09Vbr3K6ZnvuuFdwryYWXrAnWLgJtOp
gmODZLbTd8ekY58j3DaWUuikTpkeYzclMPIllH9rFoD6BW09b/phyW167/mbhSna1Nn8
SNKQ==
X-Gm-Message-State: AJaThX75QmryvL2th2pnDD690VcoMUMWHgxN5za+OWJyJT+3ofinguNt
o7a2d2nmaGey3XwhpHqYQrcX0b3t9WyFCGOfUUE=
X-Google-Smtp-Source: AGs4zMack4F5kTWYJJoRYyMf1OgMOxaZbfejiVN+xaTZ4u0qVVy062RmJ8ilLq0ciOfYGJhMmbmUXq1YRcWqmE6mPus=
X-Received: by 10.37.87.67 with SMTP id l64mr824038ybb.415.1512022396190; Wed,
29 Nov 2017 22:13:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.43.195 with HTTP; Wed, 29 Nov 2017 22:13:15 -0800 (PST)
In-Reply-To: <CANgJ=T8ZHbC4R3Rs5kZG8HfGs8810jj01WN4Ssiketej0md4kA@mail.gmail.com>
References: <CADpM8jr_RrbPXLx6Up8HMW-fv=noFLjy817dfsFdYTg216Pu7w@mail.gmail.com>
<CANgJ=T8ZHbC4R3Rs5kZG8HfGs8810jj01WN4Ssiketej0md4kA@mail.gmail.com>
From: William Morriss <wjmelements@gmail.com>
Date: Wed, 29 Nov 2017 22:13:15 -0800
Message-ID: <CADpM8jq_-JxCmLiCPMG2ZVuYxZH7KOCyyMaQnBay18PQLPvmRg@mail.gmail.com>
To: Ben Kloester <benkloester@gmail.com>
Content-Type: multipart/alternative; boundary="001a113e7f38d146e1055f2d259e"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
HTML_OBFUSCATE_05_10,
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
X-Mailman-Approved-At: Thu, 30 Nov 2017 11:02:19 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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 06:13:17 -0000
--001a113e7f38d146e1055f2d259e
Content-Type: text/plain; charset="UTF-8"
On Wed, Nov 29, 2017 at 6:38 PM, Ben Kloester <benkloester@gmail.com> wrote:
> Something similar to this has been proposed in this article by Ron Lavi,
> Or Sattath, and Aviv Zohar, and discussed in this bitcoin-dev thread
> https://lists.linuxfoundation.org/pipermail/bitcoin-
> dev/2017-September/015093.html
>
> They only discussed changing the fee structure, not removing the block
> size limit, as far as I know.
>
> "Redesigning Bitcoin's fee market"
> https://arxiv.org/abs/1709.08881
>
> *Ben Kloester*
>
Thanks. Marginal pricing is equivalent to the "Monopolistic Price
Mechanism" discussed in https://arxiv.org/abs/1709.08881. The mechanism is
the same, including the block size adjustment, but as you noted the prior
discussion only concerns the fee structure.
It looks like the prior proposal broke down because of Peter Todd's concern
with out-of-band payments (https://lists.linuxfoundation.org/pipermail/
bitcoin-dev/2017-September/015103.html). Restated, miners can circumvent
the system through out of band payments. Mark Friedenbach argues that
out-of-band payments are penalized in part because the end-user could have
just as easily bid higher instead of paying OOB. Peter Todd argues that a
miner could mine only out-of-band transactions. Such transactions could
have no on-chain fees and thus be disregarded by other miners.
I believe this OOB scenario is imaginary. Either it would be more
profitable 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.
I don't think there is any more centralization pressure with marginal fees
than before. What prevents miners from colluding to move tx fees OOB is the
value of the on-band pending tx fees. The hashpower of individual miners is
not impressive compared to the entire network, so individual miners could
not offer a service to speed up confirmation that would be superior to
simply doing a RBP. OOB fees are perhaps a symptom of the current setup,
wherein there is no penalty for arbitrarily favoring individual
transactions with lower fees.
--001a113e7f38d146e1055f2d259e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On Wed, Nov 29, 2017 at 6:38 PM=
, Ben Kloester <span dir=3D"ltr"><<a href=3D"mailto:benkloester@gmail.co=
m" target=3D"_blank">benkloester@gmail.com</a>></span> wrote:<br><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr">Something similar to this has been proposed=C2=A0 in t<span sty=
le=3D"font-size:12.8px">his article by Ron Lavi, Or Sattath, and Aviv Zohar=
, and discussed in this bitcoin-dev thread=C2=A0<a href=3D"https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2017-September/015093.html" target=
=3D"_blank">https://lists.linuxfoun<wbr>dation.org/pipermail/bitcoin-<wbr>d=
ev/2017-September/015093.html</a></span><div><br></div><div>They only discu=
ssed changing the fee structure, not removing the block size limit, as far =
as I know.<br style=3D"font-size:12.8px"><br style=3D"font-size:12.8px"><sp=
an style=3D"font-size:12.8px">=C2=A0 =C2=A0 "Redesigning=C2=A0</span><=
span class=3D"m_7355356485751430742gmail-m_2648373878203727864gmail-il" sty=
le=3D"font-size:12.8px;background-color:rgb(255,255,255)">Bitcoin</span><sp=
an style=3D"font-size:12.8px">'s=C2=A0</span><span class=3D"m_735535648=
5751430742gmail-m_2648373878203727864gmail-il" style=3D"font-size:12.8px;ba=
ckground-color:rgb(255,255,255)">fee</span><span style=3D"font-size:12.8px"=
>=C2=A0mar<wbr>ket"</span><br style=3D"font-size:12.8px"><span style=
=3D"font-size:12.8px">=C2=A0 =C2=A0=C2=A0</span><a href=3D"https://arxiv.or=
g/abs/1709.08881" rel=3D"noreferrer" style=3D"font-size:12.8px" target=3D"_=
blank">https://arxiv.org/abs/1709.0<wbr>8881</a><br><div class=3D"gmail_ext=
ra"><br clear=3D"all"><div><div class=3D"m_7355356485751430742gmail-m_26483=
73878203727864gmail_signature"><p><b>Ben Kloester</b></p></div></div></div>=
</div></div></blockquote><div><br></div><div><div>Thanks. Marginal pricing =
is equivalent to the "Monopolistic Price=20
Mechanism" discussed in <a href=3D"https://arxiv.org/abs/1709.08881" t=
arget=3D"_blank">https://arxiv.org/abs/1709.<wbr>08881</a>. The mechanism=
=20
is the same, including the block size adjustment, but as you noted the prio=
r discussion only concerns the fee structure.<br></div><div><br></div><div>=
It
looks like the prior proposal broke down because of Peter Todd's=20
concern with out-of-band payments=20
(<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Se=
ptember/015103.html" target=3D"_blank">https://lists.<wbr>linuxfoundation.o=
rg/pipermail/<wbr>bitcoin-dev/2017-September/<wbr>015103.html</a>).
Restated, miners can circumvent the system through out of band=20
payments. Mark Friedenbach argues that out-of-band payments are=20
penalized in part because the end-user could have just as easily bid=20
higher instead of paying OOB. Peter Todd argues that a miner could mine=20
only out-of-band transactions. Such transactions could have no on-chain=20
fees and thus be disregarded by other miners.</div><div><br></div><div>I
believe this OOB scenario is imaginary. Either it would be more=20
profitable for a miner to mine fairly, or cheaper for the end-user to=20
pay the fee in-band. Consider MINFEE to the the effective fee paid for=20
the block mined by the OOB-incentivized miner. Consider MARKFEE to the=20
the market fee collected by non-OOB-incentivized miners. Call the OOB=20
effective tx fee OOB. Then,<br></div><div>For a user to prefer OOB: MINFEE+=
OOB<MARKFEE</div><div>For a miner to prefer OOB: MINFEE+OOB>MARKFEE</=
div><div>It
is impossible for both scenarios to be true. As previously argued by=20
Mark Friedenbach, the system disincentivizes OOB tx fees.</div><div><br></d=
iv>I
don't think there is any more centralization pressure with marginal=20
fees than before. What prevents miners from colluding to move tx fees=20
OOB is the value of the on-band pending tx fees. The hashpower of=20
individual miners is not impressive compared to the entire network, so=20
individual miners could not offer a service to speed up confirmation that w=
ould be superior to simply doing a RBP.=20
OOB fees are perhaps a symptom of the current setup, wherein there is no
penalty for arbitrarily favoring individual transactions with lower fees.<=
br></div></div></div></div>
--001a113e7f38d146e1055f2d259e--
|
