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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeanpaulkogelman@me.com>) id 1WXQOi-0003Wd-NZ
for bitcoin-development@lists.sourceforge.net;
Tue, 08 Apr 2014 07:24:44 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of me.com
designates 17.172.220.236 as permitted sender)
client-ip=17.172.220.236; envelope-from=jeanpaulkogelman@me.com;
helo=st11p02mm-asmtp001.mac.com;
Received: from st11p02mm-asmtp001.mac.com ([17.172.220.236])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WXQOh-0002M4-Mh for bitcoin-development@lists.sourceforge.net;
Tue, 08 Apr 2014 07:24:44 +0000
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from [10.0.1.102] (216-19-182-8.dyn.novuscom.net [216.19.182.8])
by st11p02mm-asmtp001.mac.com
(Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit
(built Aug
22 2013)) with ESMTPSA id <0N3P00CXYB8Y5VA0@st11p02mm-asmtp001.mac.com>
for bitcoin-development@lists.sourceforge.net; Tue,
08 Apr 2014 07:24:37 +0000 (GMT)
From: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
X-Mailer: iPhone Mail (11D167)
In-reply-to: <CAJHLa0MOB2=1JNfXCb-DY24ssTi7hVFi6H7JDaeVp5oOUUMy=A@mail.gmail.com>
Date: Tue, 08 Apr 2014 00:24:37 -0700
Message-id: <AC42883D-9D3A-49D3-9ADA-7D24AB833352@me.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>
<CAJHLa0MOB2=1JNfXCb-DY24ssTi7hVFi6H7JDaeVp5oOUUMy=A@mail.gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaEhEKTEMXGx0EGx0YBBIZBBsdEBseGh8
aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsYGmJCH2lmHEBGGXhzB
xkSGh0YHkscEQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGx0QGx4aHxsRCl5ZF2FPf0B
6EQpMRhdia2sRCkNaFxgbHAQbEwQbEhgEEhEKRFgXGREKREkXGBEKQkYXYEtmQBhZU3Jeb2cRC
kJFF2loBX5vQWtfUHx5EQpCThdscGB5QB1iUmkaYhEKQkwXaGQaH1wbWXBtZGQRCkJsF2lLZRl
SZ2xGQEdGEQpCQBdtTEB7S2QcWGdIRxEKcGcXaB9PEkJsflIFEkkRCnBoF2JfSXhkQnkBS2hiE
QpwaBd6Z2EccGxuXEcaUBEKcGgXbB9oU1tvQUNvaG0RCnBoF2kFHhxSX1xlTWlIEQpwaBdoZ2R
ceE5DE1lffhEKcH8XaUVJXGMaAQFLG0YRCnBfF2BeEhlZHUhJR1NnEQpwZxdsU0VCb3BJG0V8Y
REKcH8XYnhHExlIWVIYREMRCnBfF2N4GWViQklYfmFuEQpwfxdkQFoSBU1SfRpycxEKcGwXbEx
dHGZ4fFh9HGERCnBMF2FebxlPaFgZXwFfEQ==
X-CLX-Spam: false
X-CLX-Score: 1011
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10432:5.11.96,1.0.14,0.0.0000
definitions=2014-04-08_02:2014-04-07, 2014-04-08,
1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam
adjust=0
reason=mlx scancount=1 engine=7.0.1-1402240000
definitions=main-1404080006
X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1WXQOh-0002M4-Mh
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: Tue, 08 Apr 2014 07:24:44 -0000
Isn't that just conceding that p2p protocol A is better than p2p protocol B?
Can't Bitcoin Core's block fetching be improved to get similar performance as a torrent + import?
Currently it's hard to go wide on data fetching because headers first is still pretty 'beefy'. The headers can be compressed, which would get you about 50% savings.
Also, maybe adding a layer that groups block headers into a single hash (say, 2016 headers), and then being able to fetch those (possibly compressed) header 'blocks' from multiple sources in parallel. And fanning out block fetches even further, favoring fast nodes.
Just thinking out loud.
jp
> On Apr 7, 2014, at 8:44 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>
> Being Mr. Torrent, I've held open the "80% serious" suggestion to
> simply refuse to serve blocks older than X (3 months?).
>
> That forces download by other means (presumably torrent).
>
> I do not feel it is productive for any nodes on the network to waste
> time/bandwidth/etc. serving static, ancient data. There remain, of
> course, issues of older nodes and "getting the word out" that prevents
> this switch from being flipped on tomorrow.
>
>
>
>> On Mon, Apr 7, 2014 at 2:49 PM, 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?
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
