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
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <nathan@leastauthority.com>) id 1Z374D-0001Ol-Vu
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Jun 2015 18:19:05 +0000
X-ACL-Warn:
Received: from mail-oi0-f49.google.com ([209.85.218.49])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z3743-000429-KK
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Jun 2015 18:19:05 +0000
Received: by oiha141 with SMTP id a141so8339155oih.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 11 Jun 2015 11:18:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=ZcSyQ2vpCLR6hDI6m1xy+PwwKMJvUV0vxMXOr99tI6E=;
b=iCArYDefwGCehbDJJaY23GHJR9ScfI74cn1pqwMKfvT9IMrIhhl2KHpRvxK4Jt4f0V
sK9aLINypKpcQ1JmDGFtzidV0jUGwVhnVR3BgQgdrcS7YFED5mT5otlKmqftT6LxyiXU
/7TvTtFVIsF2VgQ4ywcA1lJoo1gUcKMOjUZuQTHV8jMTsTnWwDgsKFheGdVwPZHfOT2C
PXjuYigLv8ILO45nwe3W2JkjFfahHN6rr8kl4gb+eQi3iRRRtjlSpJy6uUUmXhRgyDeg
EMtChzPMparyOJi1m3eKx0yQHNlY7g+TgbGcglVg4w/hjAMA0CiU+Y04PcjcMImvhjtO
5hrA==
X-Gm-Message-State: ALoCoQmrYppsHuvrsj3czW/wp6U8h5UhrUp6fqrGxixxlthuBpNZPQ7IExeAL8i4FLMx0dzXOzVd
MIME-Version: 1.0
X-Received: by 10.202.170.82 with SMTP id t79mr8578263oie.40.1434046730152;
Thu, 11 Jun 2015 11:18:50 -0700 (PDT)
Received: by 10.182.47.229 with HTTP; Thu, 11 Jun 2015 11:18:50 -0700 (PDT)
In-Reply-To: <20150611131048.GA24053@savin.petertodd.org>
References: <CAFdHNGgtgWGu8gnnJfM0EcVn2m_Wff5HPwAe-9FBvjR++q0Q-Q@mail.gmail.com>
<CANEZrP3+jW3BO=Zv41CGubJL7bSZ==o=Wp83K6Q0xL4PP+0ZUQ@mail.gmail.com>
<CACq0ZD6Qr7F7_20Nfd0a8TTHEVMR0fxu-T5bO4FfN1Lp9PcGDQ@mail.gmail.com>
<20150611131048.GA24053@savin.petertodd.org>
Date: Thu, 11 Jun 2015 12:18:50 -0600
Message-ID: <CAFdHNGgtf+AuW=yMegCuFPNPpi6GgArsTkBWbdVxKNY6R7Erug@mail.gmail.com>
From: Nathan Wilcox <nathan@leastauthority.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a113c32ecf146e605184205af
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Z3743-000429-KK
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2015 18:19:06 -0000
--001a113c32ecf146e605184205af
Content-Type: text/plain; charset=UTF-8
On Thu, Jun 11, 2015 at 7:10 AM, Peter Todd <pete@petertodd.org> wrote:
> On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote:
> > The other complication is that this will tend to be a lagging indicator
> > based on network congestion from the last time you connected. If we
> assume
> > that transactions are being dropped in an unpredictable way when blocks
> are
> > full, knowing the network congestion *right now* is critical, and even
> then
> > you just have to hope that someone who wants that space more than you do
> > doesn't show up after you disconnect.
>
> Hence the need for ways to increase fees on transactions after initial
> broadcast like replace-by-fee and child-pays-for-parent.
>
>
I haven't looked closely at replace-by-fee yet, but I assume this is a
non-consensus change to mempool mechanics. To me, this seems like the
"actuator" side of fee mechanics: it provides a transaction sender a way to
influence the system. By contrast, learning about fees is the "sensor"
side of fee mechanics.
Consider how a replace-by-fee wallet makes fee decisions. When does it
replace by fee? It needs feedback in one of two forms:
a. Direct feedback from a trnasaction relay service, or:
b. Information in the blockchain, which is verified by all verifying nodes
and refined by all miners.
The first kind of information is quite acceptable and practical for many
use cases, but leave the wallet vulnerable to fabrications by that service.
This vulnerability is precisely what SPV security intends to mitigate,
right?
With only information type a, a (non-SPV) wallet can "shop around" to find
competing services, and this should work pretty well, provided the wallet
can discover those competing services. If, OTOH, the wallet has access to
information type b, it now has "perfect competition" across all such
services, even when it can't discover the low-priced services directly.
This actual-fees-in-the-actual-block-chain information of type b seem like
a powerful source of pricing information, and if SPV security is already
valuable for other reasons, then it seems natural to leverage that value.
Re: "dropped in an unpredictable way" - transactions would be dropped
> lowest fee/KB first, a completely predictable way.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000124bae79afdcee9267b4e6f8137758b8b4135455cd8e3bfd
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Nathan Wilcox
Least Authoritarian
email: nathan@leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
--001a113c32ecf146e605184205af
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Jun 11, 2015 at 7:10 AM, Peter Todd <span dir=3D"l=
tr"><<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petert=
odd.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed, Jun 10,=
2015 at 02:18:30PM -0700, Aaron Voisine wrote:<br>
> The other complication is that this will tend to be a lagging indicato=
r<br>
> based on network congestion from the last time you connected. If we as=
sume<br>
> that transactions are being dropped in an unpredictable way when block=
s are<br>
> full, knowing the network congestion *right now* is critical, and even=
then<br>
> you just have to hope that someone who wants that space more than you =
do<br>
> doesn't show up after you disconnect.<br>
<br>
</span>Hence the need for ways to increase fees on transactions after initi=
al<br>
broadcast like replace-by-fee and child-pays-for-parent.<br>
<br></blockquote><div><br></div><div>I haven't looked closely at replac=
e-by-fee yet, but I assume this is a non-consensus change to mempool mechan=
ics. To me, this seems like the "actuator" side of fee mechanics:=
it provides a transaction sender a way to influence the system.=C2=A0 By c=
ontrast, learning about fees is the "sensor" side of fee mechanic=
s.<br><br></div><div>Consider how a replace-by-fee wallet makes fee decisio=
ns. When does it replace by fee?=C2=A0 It needs feedback in one of two form=
s:<br><br></div><div>a. Direct feedback from a trnasaction relay service, o=
r:<br><br></div><div>b. Information in the blockchain, which is verified by=
all verifying nodes and refined by all miners.<br><br></div><div>The first=
kind of information is quite acceptable and practical for many use cases, =
but leave the wallet vulnerable to fabrications by that service. This vulne=
rability is precisely what SPV security intends to mitigate, right?</div><d=
iv><br></div><div>With only information type a, a (non-SPV) wallet can &quo=
t;shop around" to find competing services, and this should work pretty=
well, provided the wallet can discover those competing services. If, OTOH,=
the wallet has access to information type b, it now has "perfect comp=
etition" across all such services, even when it can't discover the=
low-priced services directly.<br><br></div><div>This actual-fees-in-the-ac=
tual-block-chain information of type b seem like a powerful source of prici=
ng information, and if SPV security is already valuable for other reasons, =
then it seems natural to leverage that value.<br></div><div><br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex">
Re: "dropped in an unpredictable way" - transactions would be dro=
pped<br>
lowest fee/KB first, a completely predictable way.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
0000000000000000124bae79afdcee9267b4e6f8137758b8b4135455cd8e3bfd<br>
</font></span><br>---------------------------------------------------------=
---------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature">Nathan Wilcox<br>Least Authoritarian<br><br>email: <a href=3D"m=
ailto:nathan@leastauthority.com" target=3D"_blank">nathan@leastauthority.co=
m</a><br>twitter: @least_nathan<br>PGP: 11169993 / AAAC 5675 E3F7 514C 67ED=
=C2=A0E9C9 3BFE 5263 1116 9993<br></div>
</div></div>
--001a113c32ecf146e605184205af--
|
