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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <voisine@gmail.com>) id 1Z2lXL-0003ZV-57
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Jun 2015 19:19:43 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.171 as permitted sender)
client-ip=209.85.220.171; envelope-from=voisine@gmail.com;
helo=mail-qk0-f171.google.com;
Received: from mail-qk0-f171.google.com ([209.85.220.171])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z2lXK-0006Jz-0J
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Jun 2015 19:19:43 +0000
Received: by qkhq76 with SMTP id q76so30240966qkh.2
for <bitcoin-development@lists.sourceforge.net>;
Wed, 10 Jun 2015 12:19:36 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.109.34 with SMTP id k31mr6156436qgf.94.1433963976544;
Wed, 10 Jun 2015 12:19:36 -0700 (PDT)
Received: by 10.140.91.37 with HTTP; Wed, 10 Jun 2015 12:19:36 -0700 (PDT)
In-Reply-To: <CAFdHNGgtgWGu8gnnJfM0EcVn2m_Wff5HPwAe-9FBvjR++q0Q-Q@mail.gmail.com>
References: <CAFdHNGgtgWGu8gnnJfM0EcVn2m_Wff5HPwAe-9FBvjR++q0Q-Q@mail.gmail.com>
Date: Wed, 10 Jun 2015 12:19:36 -0700
Message-ID: <CACq0ZD5=EunMZJJMKfFUGkR=Ye_8nmV0qLkJJ997gbWk1MTC9w@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Nathan Wilcox <nathan@leastauthority.com>
Content-Type: multipart/alternative; boundary=001a113a7d0a7157bf05182ec163
X-Spam-Score: -0.6 (/)
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
(voisine[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1Z2lXK-0006Jz-0J
Cc: Bitcoin Development <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: Wed, 10 Jun 2015 19:19:43 -0000
--001a113a7d0a7157bf05182ec163
Content-Type: text/plain; charset=UTF-8
It could be done by agreeing on a data format and encoding it in an
op_return output in the coinbase transaction. If it catches on it could
later be enforced with a soft fork.
For real up-to-the-minute fee calculations you're also going to want to
look at the current mempool, how many transactions are waiting, what fees
they're paying, etc, but of course that information is susceptible to sybil
attack.
In practice what we're doing for now is using services like blockcypher
who's business is improving reliability of zero-conf to tell us what
fee-per-kb is needed, and then putting a hard coded range around it to
protect against the service being compromised. This is also the kind of
thing being done for exchange rate data which is probably the bigger
security risk until bitcoin becomes the standard unit of account for the
planet.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, Jun 10, 2015 at 10:37 AM, Nathan Wilcox <nathan@leastauthority.com>
wrote:
> [I'm currently wading through bitcoin-development. I'm still about a month
> behind, so I apologize in advance for any noisy redundancy in this post.]
>
> While reading about blocksize, I've just finished Mike Hearn's blog post
> describing expected systemic behavior as actual blocks approach the current
> limit (with or without non-protocol-changing implementation improvements):
>
> https://medium.com/@octskyward/crash-landing-f5cc19908e32
>
>
> One detail Mike uses to argue against the "fee's will save us" line of
> reasoning is that wallets have no good way to learn fee information.
>
> So, here's a proposal to fix that: put fee and (and perhaps block size,
> UTXO, etc...) statistics into the locally-verifiable data available to SPV
> clients (ie: block headers).
>
>
> It's easy to imagine a hard fork that places details like per-block total
> fees, transaction count, fee variance, UTXO delta, etc... in a each block
> header. This would allow SPV clients to rely on this data with the same
> PoW-backed assurances as all other header data.
>
> This mechanism seems valuable regardless of the outcome of blocksize
> debate. So long as fees are interesting or important, SPV clients should
> know about them. (Same for other stats such as UTXO count.)
>
> Upgrading the protocol without a hard-fork may be possible and is left as
> an exercise for the reader. ;-)
>
> --
> Nathan Wilcox
> Least Authoritarian
>
> email: nathan@leastauthority.com
> twitter: @least_nathan
> PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a113a7d0a7157bf05182ec163
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It could be done by agreeing on a data format and encoding=
it in an op_return output in the coinbase transaction. If it catches on it=
could later be enforced with a soft fork.<div><br></div><div>For real up-t=
o-the-minute fee calculations you're also going to want to look at the =
current mempool, how many transactions are waiting, what fees they're p=
aying, etc, but of course that information is susceptible to sybil attack.<=
/div><div><br></div><div>In practice what we're doing for now is using =
services like blockcypher who's business is improving reliability of ze=
ro-conf to tell us what fee-per-kb is needed, and then putting a hard coded=
range around it to protect against the service being compromised. This is =
also the kind of thing being done for exchange rate data which is probably =
the bigger security risk until bitcoin becomes the standard unit of account=
for the planet.</div><div class=3D"gmail_extra"><div><div class=3D"gmail_s=
ignature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><br>Aaron Voisine</di=
v><div>co-founder and CEO<br><a href=3D"http://breadwallet.com" target=3D"_=
blank">breadwallet.com</a></div></div></div></div></div></div>
<br><div class=3D"gmail_quote">On Wed, Jun 10, 2015 at 10:37 AM, Nathan Wil=
cox <span dir=3D"ltr"><<a href=3D"mailto:nathan@leastauthority.com" targ=
et=3D"_blank">nathan@leastauthority.com</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div>[I'm currently wading throug=
h bitcoin-development. I'm still about a month behind, so I apologize i=
n advance for any noisy redundancy in this post.]<br><br></div>While readin=
g about blocksize, I've just finished Mike Hearn's blog post descri=
bing expected systemic behavior as actual blocks approach the current limit=
(with or without non-protocol-changing implementation improvements):<br><d=
iv><br><a href=3D"https://medium.com/@octskyward/crash-landing-f5cc19908e32=
" target=3D"_blank">https://medium.com/@octskyward/crash-landing-f5cc19908e=
32</a><br><br><br></div><div>One detail Mike uses to argue against the &quo=
t;fee's will save us" line of reasoning is that wallets have no go=
od way to learn fee information.<br><br></div><div>So, here's a proposa=
l to fix that: put fee and (and perhaps block size, UTXO, etc...) statistic=
s into the locally-verifiable data available to SPV clients (ie: block head=
ers).<br><br></div><br><div>It's easy to imagine a hard fork that place=
s details like per-block total fees, transaction count, fee variance, UTXO =
delta, etc... in a each block header. This would allow SPV clients to rely =
on this data with the same PoW-backed assurances as all other header data.<=
br><br></div><div><div>This mechanism seems valuable regardless of the outc=
ome of=20
blocksize debate. So long as fees are interesting or important, SPV=20
clients should know about them. (Same for other stats such as UTXO=20
count.)<br><br></div><div>Upgrading the protocol without a hard-fork may be=
possible and is left as an exercise for the reader. ;-)<span class=3D"HOEn=
Zb"><font color=3D"#888888"><br></font></span></div><span class=3D"HOEnZb">=
<font color=3D"#888888"><br>-- <br><div>Nathan Wilcox<br>Least Authoritaria=
n<br><br>email: <a href=3D"mailto:nathan@leastauthority.com" target=3D"_bla=
nk">nathan@leastauthority.com</a><br>twitter: @least_nathan<br>PGP: 1116999=
3 / AAAC 5675 E3F7 514C 67ED =C2=A0E9C9 3BFE 5263 1116 9993<br></div>
</font></span></div></div>
<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></div></div>
--001a113a7d0a7157bf05182ec163--
|
