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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Vn5Z3-0005li-GK
for bitcoin-development@lists.sourceforge.net;
Sun, 01 Dec 2013 11:51:53 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vn5Z2-0004Jx-DE
for bitcoin-development@lists.sourceforge.net;
Sun, 01 Dec 2013 11:51:53 +0000
Received: by mail-ob0-f175.google.com with SMTP id uz6so11563169obc.20
for <bitcoin-development@lists.sourceforge.net>;
Sun, 01 Dec 2013 03:51:47 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.135.165 with SMTP id pt5mr34101obb.66.1385898706999;
Sun, 01 Dec 2013 03:51:46 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.3.134 with HTTP; Sun, 1 Dec 2013 03:51:46 -0800 (PST)
Date: Sun, 1 Dec 2013 12:51:46 +0100
X-Google-Sender-Auth: dyRyQo1aAsCZoYJMuLgWO0l3j-w
Message-ID: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e0112cb9e201fc304ec77b0e6
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Vn5Z2-0004Jx-DE
Subject: [Bitcoin-development] Floating fees and SPV clients
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: Sun, 01 Dec 2013 11:51:53 -0000
--089e0112cb9e201fc304ec77b0e6
Content-Type: text/plain; charset=UTF-8
Lately I was pondering how to make floating fees and SPV wallets work well
together.
I propose the following plan:
1) 0.9 ships with something dead simple, like a command to query what a
node estimates and then clients just take the average, or cross-check a
centralised estimate against the P2P network. It's fast to implement and
simple, but not very secure or decentralised. However it will allow the
feature to launch on some kind of reasonable timeframe.
2) We bump the protocol version and the tx message now gets an optional
protobuf buffer stuck on the end. The first thing put in this protobuf is a
list of the values of the inputs. Using this data, the fee paid by a
transaction can be calculated. In step 2 the data is unauthenticated.
3) Some SPV wallets already set themselves up so that they sync with the
network in the background, e.g. the Android wallet syncs at least every 24
hours. This should become more common, using scheduler capabilities built
into most operating systems. When the wallet syncs with the network, it
sets a deliberately very noisy Bloom filter on its peers and waits around
for 30-60 seconds or so. The wallet observes some of the broadcasts taking
place and records the hashes and associated fees that were paid to disk.
Next time it syncs, it includes the observed hashes into the Bloom filter
used to download the chain, and thus learns how quickly they confirmed. It
can calculate its own fee estimate from that.
4) Finally, when we next hard fork, we make v2 transactions include the
output value in the signature, same as the output script (this proposal has
been on the forums for a while now). That allows the fee data added in step
2 to be cross-checked against the signatures on the inputs, thus
authenticating it.
I think this is a small and easy set of steps that would make it quite hard
to attack - malicious nodes could make it appear that some transactions
never confirmed thus seeming to force the price up, but it's easy to simply
exclude transactions which never confirm at all from the calculations. Plus
of course you can cross-check nodes against each other to try and catch
nodes that are failing to match transactions properly.
One obvious concern is what to do if nodes don't converge on very similar
estimates. Wallets will always want to pay the lowest fee possible, so that
means they'll always be riding the very edge of what's acceptable, opening
up tx propagation to random flaky failures if fee estimates change whilst a
transaction is in progress, or if some nodes don't calculate the same
estimates as others.
If a wallet gets a reject message for a tx that has a fee that are by its
own estimates acceptable, what should it do? What if only some nodes report
that and others don't?
--089e0112cb9e201fc304ec77b0e6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Lately I was pondering how to make floating fees and SPV w=
allets work well together.<div><br></div><div>I propose the following plan:=
</div><div><br></div><div>1) 0.9 ships with something dead simple, like a c=
ommand to query what a node estimates and then clients just take the averag=
e, or cross-check a centralised estimate against the P2P network. It's =
fast to implement and simple, but not very secure or decentralised. However=
it will allow the feature to launch on some kind of reasonable timeframe.<=
/div>
<div><br></div><div>2) We bump the protocol version and the tx message now =
gets an optional protobuf buffer stuck on the end. The first thing put in t=
his protobuf is a list of the values of the inputs. Using this data, the fe=
e paid by a transaction can be calculated. In step 2 the data is unauthenti=
cated.</div>
<div><br></div><div>3) Some SPV wallets already set themselves up so that t=
hey sync with the network in the background, e.g. the Android wallet syncs =
at least every 24 hours. This should become more common, using scheduler ca=
pabilities built into most operating systems. When the wallet syncs with th=
e network, it sets a deliberately very noisy Bloom filter on its peers and =
waits around for 30-60 seconds or so. The wallet observes some of the broad=
casts taking place and records the hashes and associated fees that were pai=
d to disk. Next time it syncs, it includes the observed hashes into the Blo=
om filter used to download the chain, and thus learns how quickly they conf=
irmed. It can calculate its own fee estimate from that.</div>
<div><br></div><div>4) Finally, when we next hard fork, we make v2 transact=
ions include the output value in the signature, same as the output script (=
this proposal has been on the forums for a while now). That allows the fee =
data added in step 2 to be cross-checked against the signatures on the inpu=
ts, thus authenticating it.</div>
<div><br></div><div><br></div><div>I think this is a small and easy set of =
steps that would make it quite hard to attack - malicious nodes could make =
it appear that some transactions never confirmed thus seeming to force the =
price up, but it's easy to simply exclude transactions which never conf=
irm at all from the calculations. Plus of course you can cross-check nodes =
against each other to try and catch nodes that are failing to match transac=
tions properly.</div>
<div><br></div><div>One obvious concern is what to do if nodes don't co=
nverge on very similar estimates. Wallets will always want to pay the lowes=
t fee possible, so that means they'll always be riding the very edge of=
what's acceptable, opening up tx propagation to random flaky failures =
if fee estimates change whilst a transaction is in progress, or if some nod=
es don't calculate the same estimates as others.</div>
<div><br></div><div>If a wallet gets a reject message for a tx that has a f=
ee that are by its own estimates acceptable, what should it do? What if onl=
y some nodes report that and others don't?</div><div><br></div><div>
<br></div></div>
--089e0112cb9e201fc304ec77b0e6--
|
