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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tamas@bitsofproof.com>) id 1WXEmO-0002tI-26
for bitcoin-development@lists.sourceforge.net;
Mon, 07 Apr 2014 19:00:24 +0000
X-ACL-Warn:
Received: from wp059.webpack.hosteurope.de ([80.237.132.66])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WXEmM-0004vi-0o
for bitcoin-development@lists.sourceforge.net;
Mon, 07 Apr 2014 19:00:24 +0000
Received: from [37.143.74.116] (helo=[192.168.2.2]); authenticated
by wp059.webpack.hosteurope.de running ExIM with esmtpsa
(TLS1.0:RSA_AES_128_CBC_SHA1:16)
id 1WXEmF-0005eU-0d; Mon, 07 Apr 2014 21:00:15 +0200
Content-Type: multipart/signed;
boundary="Apple-Mail=_11BA485A-697C-4764-97B9-BB2C17805957";
protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Tamas Blummer <tamas@bitsofproof.com>
In-Reply-To: <CAAS2fgQaJ6P4Aj2A5Zox+CiGQK6jHvF1CkLH1R6xbadYhUXO2g@mail.gmail.com>
Date: Mon, 7 Apr 2014 21:00:27 +0200
Message-Id: <8A6DEBA4-EA59-4BAE-95CF-C964C2DBB84B@bitsofproof.com>
References: <CANEZrP2rgiQHpekEpFviJ22QsiV+s-F2pqosaZOA5WrRtJx5pg@mail.gmail.com>
<5342C833.5030906@gmail.com>
<CAAS2fgTqBfEPXh2dfcL_ke6c0wfXw4qUM1rAYMkAHcAM6mYH+g@mail.gmail.com>
<6D430188-CE00-44B1-BD8C-B623CF04D466@icloudtools.net>
<CANEZrP1-9LpPw4WuY8bfsEG0OLoDECXTfQCoZsZ4tmOn2H7Omw@mail.gmail.com>
<6D6E55CE-2F04-4C34-BEE6-98AEF1478346@bitsofproof.com>
<CAAS2fgQaJ6P4Aj2A5Zox+CiGQK6jHvF1CkLH1R6xbadYhUXO2g@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
X-Mailer: Apple Mail (2.1874)
X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1396897222;
5f6558e8;
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: 1WXEmM-0004vi-0o
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Why are we bleeding nodes?
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: Mon, 07 Apr 2014 19:00:24 -0000
--Apple-Mail=_11BA485A-697C-4764-97B9-BB2C17805957
Content-Type: multipart/alternative;
boundary="Apple-Mail=_C164A8DF-69ED-421A-AD19-B74BA6117EB3"
--Apple-Mail=_C164A8DF-69ED-421A-AD19-B74BA6117EB3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Once a single transaction in pruned in a block, the block is no longer =
eligible to be served to other nodes.=20
Which transactions are pruned can be rather custom e.g. even depending =
on the wallet(s) of the node,
therefore I guess it is more handy to return some bitmap of pruned/full =
blocks than ranges.
Tamas Blummer
http://bitsofproof.com
On 07.04.2014, at 20:49, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <tamas@bitsofproof.com> =
wrote:
>> BTW, did we already agree on the service bits for an archive node?
>=20
> I'm still very concerned that a binary archive bit will cause extreme
> load hot-spotting and the kind of binary "Use lots of resources YES or
> NO" I think we're currently suffering some from, but at that point
> enshrined in the protocol.
>=20
> It would be much better to extend the addr messages so that nodes can
> indicate a range or two of blocks that they're serving, so that all
> nodes can contribute fractionally according to their means. E.g. if
> you want to offer up 8 GB of distributed storage and contribute to the
> availability of the blockchain, without having to swollow the whole
> 20, 30, 40 ... gigabyte pill.
>=20
> Already we need that kind of distributed storage for the most recent
> blocks to prevent extreme bandwidth load on archives, so extending it
> to arbitrary ranges is only more complicated because there is
> currently no room to signal it.
>=20
--Apple-Mail=_C164A8DF-69ED-421A-AD19-B74BA6117EB3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div>Once a single transaction in pruned in a block, =
the block is no longer eligible to be served to other =
nodes. </div><div>Which transactions are pruned can be rather =
custom e.g. even depending on the wallet(s) of the =
node,</div><div>therefore I guess it is more handy to return some bitmap =
of pruned/full blocks than ranges.</div><div><br></div><div =
apple-content-edited=3D"true"><span style=3D"color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; orphans: 2; widows: 2; float: none; =
display: inline !important;">Tamas Blummer</span><br style=3D"color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; orphans: 2; widows: 2;"><span =
style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span =
style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; text-align: -webkit-auto; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; orphans: 2; widows: =
2; float: none; display: inline !important;"><a =
href=3D"http://bitsofproof.com">http://bitsofproof.com</a></span>
</span></div>
<br><div><div>On 07.04.2014, at 20:49, Gregory Maxwell <<a =
href=3D"mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <<a =
href=3D"mailto:tamas@bitsofproof.com">tamas@bitsofproof.com</a>> =
wrote:<br><blockquote type=3D"cite">BTW, did we already agree on the =
service bits for an archive node?<br></blockquote><br>I'm still very =
concerned that a binary archive bit will cause extreme<br>load =
hot-spotting and the kind of binary "Use lots of resources YES or<br>NO" =
I think we're currently suffering some from, but at that =
point<br>enshrined in the protocol.<br><br>It would be much better to =
extend the addr messages so that nodes can<br>indicate a range or two of =
blocks that they're serving, so that all<br>nodes can contribute =
fractionally according to their means. E.g. if<br>you want to offer up 8 =
GB of distributed storage and contribute to the<br>availability of the =
blockchain, without having to swollow the whole<br>20, 30, 40 ... =
gigabyte pill.<br><br>Already we need that kind of distributed storage =
for the most recent<br>blocks to prevent extreme bandwidth load on =
archives, so extending it<br>to arbitrary ranges is only more =
complicated because there is<br>currently no room to signal =
it.<br><br></blockquote></div><br></body></html>=
--Apple-Mail=_C164A8DF-69ED-421A-AD19-B74BA6117EB3--
--Apple-Mail=_11BA485A-697C-4764-97B9-BB2C17805957
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJTQvXLAAoJEPZykcUXcTkcjDIH/1G1Ma1uuO+6a2r1DqAEWiUK
Z2Zdlx6M4u53HQLj26B0uKRCIBTzNkNdg31FZJAsuRW6UMQqm147YibzYbeFg3E3
PdL/oTNtH+zEWyGgzyu261m4HaztraACk+IRYirRQNpA3IdtaNeOWO5QY+noKj/e
K073CGVytrjvWK94viaPUryKoYox8O6LKlNTs+kxLuxZXWhBE0U9bGVWGDJRlC38
B7AiquP30XhS+6FPGtm/CWEOSqSEYsH6fll/Efrj8MrxqRaVHnSNF0Z1vf6yGy/9
picqBnlJ3M/55Y9deROTbh3w2BbyZJKlvBnWZQWoIYgeBJlOfUVCGQJVsx+bl78=
=ykNd
-----END PGP SIGNATURE-----
--Apple-Mail=_11BA485A-697C-4764-97B9-BB2C17805957--
|
