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
|
Return-Path: <nathan@z.cash>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 35419910
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 02:17:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com
[209.85.218.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 89B55D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 02:17:06 +0000 (UTC)
Received: by mail-oi0-f52.google.com with SMTP id u130so5357096oib.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Sep 2017 19:17:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=z.cash; s=google;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=ob/tVo7hfkiMjkdzXY2cSj6BwJm1e5B9qnvVE1Yp5wA=;
b=FUPyAoqmYH9NwY4GCeeu2mIZ0TU5oCgoBmhaizxS5jL6nj6jwgMLHjoxsGh2c87My+
NU+ZzLdsYL54c3nlYhAnMDhGVJLaxEPZwikJ2V9vHhgG/dfgthEs5EJWc0IZr0/iCQRA
oOtuvVdQbJbrq7ICRb/vJCEZcFd2yWjKWWb00VwXjCyLqM7ZcyhGYF91o93s7H3Bi7r+
OtOMNwtSxyugE5yUm5xHT6XuTLbYlt1TLzTfs4CZMjp4NfDq8xO+W2wkANAQFQVsan+K
6njo3gg0WmeCEAgdL2eLE1e9CXvFPYH5pQSeIjTXByH2nMyCHzer+4UzZBz5WXzP5wU8
HJPw==
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=ob/tVo7hfkiMjkdzXY2cSj6BwJm1e5B9qnvVE1Yp5wA=;
b=t8iaV95sA9d6kxbK+Nx6Qd0TM4TMt58/cYvwWW9EQ8BKvQSoBt244EHepr0CZid22G
AqpkXPfPtSpb+Kl5vlduv4GDX6dLzKVDoMYsFXRRU3MBuG2R1cHnJa275UH2Z2vkfVuZ
NFQx6U8nXIaXPTF0M9G5bO6K+n9ZYjtTaMSyjIEQvhtglXnyWNuUUP4z9tY/ek5+cNQT
FXG/P47dv8Tec+WaTmvT8wgtytFj0fSRdrPceu9OgC3+evBQo6m03L+EGSk9Ar522R6l
Ah4q4FHeRm0iXH+21cXrhO3GqqaG+aE3Sj/vnha7BJPdTUrUtY9C4miHP5bKDnciFldA
HGOA==
X-Gm-Message-State: AMCzsaWfvh6pgy1rV/aYkBYQ83WgPS7yncx25oVwQ/pDAB/aqRFeVWQN
ceXtfojK5CgdgXUSu67BUyKbU2LEQeNpJQj8etGVHRLD
X-Google-Smtp-Source: AOwi7QD3cypa74F1RJErYOjwrecU2XAYwt/14F9XuLRA7v3Os0ZUazYzRQZ/SuZezTHCUe/eSnd1xSDhxWEh60A+2dU=
X-Received: by 10.157.51.76 with SMTP id u12mr1283763otd.113.1506651425895;
Thu, 28 Sep 2017 19:17:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.48.133 with HTTP; Thu, 28 Sep 2017 19:17:05 -0700 (PDT)
In-Reply-To: <20170929021033.GA12303@savin.petertodd.org>
References: <359FFE85-86AF-4FBD-9491-3528382E5002@friedenbach.org>
<DC1B3730-756E-4A9B-BE6E-481B78E4104D@mattcorallo.com>
<20170929021033.GA12303@savin.petertodd.org>
From: Nathan Wilcox <nathan@z.cash>
Date: Fri, 29 Sep 2017 11:17:05 +0900
Message-ID: <CAK8perBDQDN0WvOn3bVxDHCVLjn=chg9=pVoBsVa6U67Qox8GQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113e1d360a8fdf055a4a9fde"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM
autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 29 Sep 2017 03:03:47 +0000
Subject: Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets
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: Fri, 29 Sep 2017 02:17:07 -0000
--001a113e1d360a8fdf055a4a9fde
Content-Type: text/plain; charset="UTF-8"
On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Fri, Sep 29, 2017 at 01:53:55AM +0000, Matt Corallo via bitcoin-dev
> wrote:
> > I'm somewhat curious what the authors envisioned the real-world
> implications of this model to be. While blindly asking users to enter what
> they're willing to pay always works in theory, I'd imagine in such a world
> the fee selection UX would be similar to what it is today - users are
> provided a list of options with feerates and expected confirmation times
> from which to select. Indeed, in a world where users pay a lower fee if
> they paid more than necessary fee estimation could be more willing to
> overshoot and the UX around RBF and CPFP could be simplified greatly, but
> I'm not actually convinced that it would result in higher overall mining
> revenue.
>
> Note too that the fee users are willing to pay often changes over time.
>
> My OpenTimestamps service is a perfect example: getting a timestamp
> confirmed
> within 10 minutes of the previous one has little value to me, but if the
> previous completed timestamp was 24 hours ago I'm willing to pay
> significantly
> more money because the time delay is getting significant enough to affect
> the
> trustworthyness of the entire service. So the fee selection mechanism is
> nothing more than a RBF-using loop that bumps the fee every time a block
> gets
> mined w/o confirming my latest transaction.
>
> This kind of time sensitivity is probably true of a majority of Bitcoin
> use-cases, with the caveat that often the slope will be negative
> eventually:
> after a point in time completing the transaction has no value.
>
>
Wouldn't this RBF loop behave pretty much the same in the Monopolistic
Price Mechanism? (I haven't grokked RSOP yet.)
In fact, so long as RBF works, isn't it possible to raise Pay-Your-Bid fees
and Monopolistic Price fees over time to express the time curve preference?
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a113e1d360a8fdf055a4a9fde
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev <span dir=
=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><span class=3D"">On Fri, Sep 29, 2017 at 01=
:53:55AM +0000, Matt Corallo via bitcoin-dev wrote:<br>
> I'm somewhat curious what the authors envisioned the real-world im=
plications of this model to be. While blindly asking users to enter what th=
ey're willing to pay always works in theory, I'd imagine in such a =
world the fee selection UX would be similar to what it is today - users are=
provided a list of options with feerates and expected confirmation times f=
rom which to select. Indeed, in a world where users pay a lower fee if they=
paid more than necessary fee estimation could be more willing to overshoot=
and the UX around RBF and CPFP could be simplified greatly, but I'm no=
t actually convinced that it would result in higher overall mining revenue.=
<br>
<br>
</span>Note too that the fee users are willing to pay often changes over ti=
me.<br>
<br>
My OpenTimestamps service is a perfect example: getting a timestamp confirm=
ed<br>
within 10 minutes of the previous one has little value to me, but if the<br=
>
previous completed timestamp was 24 hours ago I'm willing to pay signif=
icantly<br>
more money because the time delay is getting significant enough to affect t=
he<br>
trustworthyness of the entire service. So the fee selection mechanism is<br=
>
nothing more than a RBF-using loop that bumps the fee every time a block ge=
ts<br>
mined w/o confirming my latest transaction.<br>
<br>
This kind of time sensitivity is probably true of a majority of Bitcoin<br>
use-cases, with the caveat that often the slope will be negative eventually=
:<br>
after a point in time completing the transaction has no value.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><br></=
div><div class=3D"gmail_quote">Wouldn't this RBF loop behave pretty muc=
h the same in the Monopolistic Price Mechanism? (I haven't grokked RSOP=
yet.)<br><br></div><div>In fact, so long as RBF works, isn't it possib=
le to raise Pay-Your-Bid fees and Monopolistic Price fees over time to expr=
ess the time curve preference?<br><br>=C2=A0</div><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</div></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div></div>
--001a113e1d360a8fdf055a4a9fde--
|
