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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1XGXXE-00076a-Dy
for Bitcoin-development@lists.sourceforge.net;
Sun, 10 Aug 2014 18:08:00 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.174 as permitted sender)
client-ip=209.85.223.174; envelope-from=pieter.wuille@gmail.com;
helo=mail-ie0-f174.google.com;
Received: from mail-ie0-f174.google.com ([209.85.223.174])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XGXXD-0002gw-GJ
for Bitcoin-development@lists.sourceforge.net;
Sun, 10 Aug 2014 18:08:00 +0000
Received: by mail-ie0-f174.google.com with SMTP id rp18so8786384iec.33
for <Bitcoin-development@lists.sourceforge.net>;
Sun, 10 Aug 2014 11:07:54 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.49.114 with SMTP id t18mr7810955ign.19.1407694074095;
Sun, 10 Aug 2014 11:07:54 -0700 (PDT)
Received: by 10.50.156.135 with HTTP; Sun, 10 Aug 2014 11:07:54 -0700 (PDT)
In-Reply-To: <20140810140719.GA20493@mcelrath.org>
References: <53E776D1.1010503@bitwatch.co>
<20140810140719.GA20493@mcelrath.org>
Date: Sun, 10 Aug 2014 20:07:54 +0200
Message-ID: <CAPg+sBhPaO3oxXhuKN=YDZZZmW5pAaC2ay0uVHhTOB1UirUMaA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bob McElrath <bob_bitcoin@mcelrath.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1XGXXD-0002gw-GJ
Cc: Bitcoin Dev <Bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Synchronization: 19.5 % orphaned blocks
at height 197'324
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, 10 Aug 2014 18:08:00 -0000
On Sun, Aug 10, 2014 at 4:07 PM, Bob McElrath <bob_bitcoin@mcelrath.org> wrote:
> I had the same problem (repeatedly) which came down a hardware problem.
This is actually an independent problem (though something to be aware
of). Flaky hardware can make synchronization fail completely - as it
relies on being able to exactly assess the validity of everything in
the blockchain.
Stilll...
> mbde@bitwatch.co [mbde@bitwatch.co] wrote:
>> Hello all,
>>
>> I'm currently synchronizing a new node and right now, at a progress of a
>> height of 197'324 blocks, I count in my debug.log an aweful amount of
>> 38'447 orphaned blocks which is about 19.5 %.
>>
>> It has been I while since I watched the synchronization process closely,
>> but this number seems pretty high to me.
Orphan blocks during synchronization are unfortunately very common,
and the result of a mostly broken download logic in the client. They
are blocks that are further ahead in the chain than the point where
you're currently synchronized to, and thus can't be validated yet.
Note that 'orphan' here means 'we do not know the parent'; it doesn't
just mean 'not in the main chain'. They are blocks that are received
out of order.
As Jeff mentions, headers-first synchronization fixes this problem
(and many other download-logic related things), by first verifying the
headers in the chain (thus already having partially validated
everything), and then downloading the blocks (in not necessarily the
right order) anymore, from multiple peers in parallel. There is
currently a pull request for it, but it's not production ready
(#4468).
>> I'm wondering about the following: would it be possible for a malicious
>> party to generate chains of blocks with low difficulity which are not
>> part of the main chain to slow down the sync process?
Yes and no. While you're still synchronization, and don't actually
know the best chain, a peer could send you stale branches (with valid
proof of work), which you would accept, store and process. But it has
to be done very early, as once you learn of a good-enough chain, a
branch with more proof of work would be requires due to some
heuristics designed to exactly prevent such an attack.
--
Pieter
|
