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
|
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 <nathan@leastauthority.com>) id 1Z2kxh-0001XW-Bn
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Jun 2015 18:42:53 +0000
X-ACL-Warn:
Received: from mail-oi0-f42.google.com ([209.85.218.42])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z2kxf-0004TL-Ld
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Jun 2015 18:42:53 +0000
Received: by oiha141 with SMTP id a141so38185991oih.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 10 Jun 2015 11:42:46 -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:date:message-id:subject:from:to
:content-type;
bh=32+07YryTQCleNinhxqVlrL570Kkv62L+nzkGc9XDg8=;
b=RjrPACjjcHSVPAVLZnYp/EbEAlpQon6IC6db0sVBuujFQRvQAhohxtSqg59ssnlJtP
ssn0icdbVNPy97ijzb29isMHTZ5m6Zv0SvSw8HusFPoCPML/CROw7moadVy1JvZZT1mn
NBOS1rVMfztc0oif1mLnUUVESu32DvMwyMzN9Yke79i87IKJIHfm58l7PWFwrzvnvrgB
j7/FBHXzcOc7FqpMIwOQSyOwjsdSjWCu2OSNH0Rd1DvFJOwsuPUFKbXlqFuPZBL4M3R9
4mwD30zoheDsdThW1HTWTw9Rhi2Si/ih3TiT1d+YHhybxa4Or7C1DK73169qtru/A6oa
HL0A==
X-Gm-Message-State: ALoCoQl9kLbPG5oe5c9BH4dF5LvBOhhm+cH8QNY4a9Mg3T/NteE8dzOvOwC1trkbp4XT+LXega2h
MIME-Version: 1.0
X-Received: by 10.60.35.42 with SMTP id e10mr3790804oej.26.1433957879378; Wed,
10 Jun 2015 10:37:59 -0700 (PDT)
Received: by 10.182.47.229 with HTTP; Wed, 10 Jun 2015 10:37:59 -0700 (PDT)
Date: Wed, 10 Jun 2015 11:37:59 -0600
Message-ID: <CAFdHNGgtgWGu8gnnJfM0EcVn2m_Wff5HPwAe-9FBvjR++q0Q-Q@mail.gmail.com>
From: Nathan Wilcox <nathan@leastauthority.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=089e013d04ee060cd505182d56a6
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: 1Z2kxf-0004TL-Ld
Subject: [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 18:42:53 -0000
--089e013d04ee060cd505182d56a6
Content-Type: text/plain; charset=UTF-8
[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
--089e013d04ee060cd505182d56a6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>[I'm currently wading through bitcoin-development=
. I'm still about a month behind, so I apologize in advance for any noi=
sy redundancy in this post.]<br><br></div>While reading about blocksize, I&=
#39;ve just finished Mike Hearn's blog post describing expected systemi=
c behavior as actual blocks approach the current limit (with or without non=
-protocol-changing implementation improvements):<br><div><br><a href=3D"htt=
ps://medium.com/@octskyward/crash-landing-f5cc19908e32">https://medium.com/=
@octskyward/crash-landing-f5cc19908e32</a><br><br><br></div><div>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.<br><br=
></div><div>So, here's a proposal to fix that: put fee and (and perhaps=
block size, UTXO, etc...) statistics into the locally-verifiable data avai=
lable to SPV clients (ie: block headers).<br><br></div><br><div>It's ea=
sy to imagine a hard fork that places details like per-block total fees, tr=
ansaction count, fee variance, UTXO delta, etc... in a each block header. T=
his would allow SPV clients to rely on this data with the same PoW-backed a=
ssurances as all other header data.<br><br></div><div><div>This mechanism s=
eems valuable regardless of the outcome 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. ;-)<br></div><br>-- <b=
r><div class=3D"gmail_signature">Nathan Wilcox<br>Least Authoritarian<br><b=
r>email: <a href=3D"mailto:nathan@leastauthority.com" target=3D"_blank">nat=
han@leastauthority.com</a><br>twitter: @least_nathan<br>PGP: 11169993 / AAA=
C 5675 E3F7 514C 67ED =C2=A0E9C9 3BFE 5263 1116 9993<br></div>
</div></div>
--089e013d04ee060cd505182d56a6--
|
