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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F0122109
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 12 Oct 2019 20:47:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com
[209.85.128.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5161FD0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 12 Oct 2019 20:47:18 +0000 (UTC)
Received: by mail-wm1-f42.google.com with SMTP id f22so13158491wmc.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 12 Oct 2019 13:47:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=lrOQ7goIq+GPJ91Jo11ANTPUsSHwyzWa/cv/CAQHINw=;
b=uH4C1gA0if8j4/l/psVcXlM84u78Ex7QMocgfLDQpAdT4lQW0yc1zf8LgjceC9c/FR
DJmbawDL9EWOscN14wsnuiBPNXjO5j0KTugq7DAK1/OYwPdu1NrD5Nk6l3tDt5Xzg198
Uk3ucrgKpm0zL7ibfxjQGvUU9GPuilLM3mAJC8Go3F/y7z9TKjvfmrVlajv8QMoc7opf
E1nQBq2MaNu2QMC81vgzoedXfZxZqZ+RJ4++IVT+RJhIn5tb1wCNF4w61ZHfcK9S/l7I
Eth/4WZMKvIUWXTXhE9or4RleKr3CjglI4+Da4IXaw9j2vv2bXGqUibwn4dTuON3RP5p
TZsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=lrOQ7goIq+GPJ91Jo11ANTPUsSHwyzWa/cv/CAQHINw=;
b=k2FG89lafbmZFfQ8ZyWknTRW8z+o2dBhhISlkow9k8/+mEE8PSHB8AEyrb/xIRKhDe
tcPdC3TLop7MSjw98oC4vwr/rwu6D9vb9fI0OA83baw5kIgc9b6+UHUDcbGXhvGKbQdw
h/q1jorS76p7INvI4eQE/kUkZ1GcRtCpKVx94n07QD6Xn6CUPnNJFUwfdG21nJ5yqicF
yYqSM1yLjfioX5zXVCg9yUo1Mdtbs0NSqmV422f85FLAN37+/ic8PXnkTSx15pQJtLAW
tTLF5i+zFg2TqiwgOaXNLCXEnso1lT1vxhf8WGjojWB6sSx5vRw97u9rW9pQID8ZmN54
2ePg==
X-Gm-Message-State: APjAAAU73NJOcYBStoayEkw5mU8eCV5Q19MqinbwB2c79CRE3My8BAQA
ZOKxak57oCa8/R1utF3xz0m8+uFTW9rhU3UKYJk=
X-Google-Smtp-Source: APXvYqzRkhDPvqvBnvoZA5yoN9a2neWQui5u7OZOqt7I2xsGXH0ji+lFcAIZnnIqataQ4ywDNg40s6vi/g5BzVftC/g=
X-Received: by 2002:a05:600c:40f:: with SMTP id
q15mr8340030wmb.30.1570913236857;
Sat, 12 Oct 2019 13:47:16 -0700 (PDT)
MIME-Version: 1.0
References: <42cd5ffd-63e8-b738-c4ea-13d0699b1268@purse.io>
<CAE-z3OV_LL+Jww3e=gO6t=02VW7m9PK+8EaYoEVLy9NKNMiSaQ@mail.gmail.com>
<e9c5e519-ea8a-f0e2-d8fb-c955b5c2de40@purse.io>
<CAE-z3OXyTc0aoJJVNLS5MReE7+Nhckyrjf22+yCSjXF8=bNbXQ@mail.gmail.com>
<H_Yq1W3SffFweLPPXiUiA4EeU2yU7c8LVcqw5AbajovWTWMt5hKQARKglEQwCjPpXvjiBfvmTnaXJwivkGkT8BDha8k303DNbFB-ECes0d4=@protonmail.com>
In-Reply-To: <H_Yq1W3SffFweLPPXiUiA4EeU2yU7c8LVcqw5AbajovWTWMt5hKQARKglEQwCjPpXvjiBfvmTnaXJwivkGkT8BDha8k303DNbFB-ECes0d4=@protonmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Sat, 12 Oct 2019 21:46:40 +0100
Message-ID: <CAE-z3OVqU5n8H9vKj9Pn7k80guMTsxt_CkN9qwpfCK8HB4PDgQ@mail.gmail.com>
To: =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= <joachimstr@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000074b94b0594bcbd70"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Chain width expansion
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Oct 2019 20:47:19 -0000
--00000000000074b94b0594bcbd70
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sat, Oct 12, 2019 at 6:56 PM Joachim Str=C3=B6mbergson <
joachimstr@protonmail.com> wrote:
> I like the backwards syncing idea. First you provide proof of your best
> block height via coinbase, then sync backwards. It solves lots of related
> problems. You know how much you can expect from the given peer.
>
It shows you which nodes are on the same chain too.
If you have 8 peers and you ask the 8 of them for their 8 best, then they
should all agree on most of them.
You can then ask each of the 8 to start sending you headers backwards from
one of the 8 seeds.
They will all roughly split the chain into 8 equal pieces, though the split
will be based on work rather than header height.
If there is disagreement, you can give priority to the node(s) with the
lowest headers until they have completed their download.
It requires a network protocol change to allow reverse block downloads
though (and messages to indicate lowest headers etc.)
On different note, one of the problems that I haven't seen mentioned here
> yet is the timewarp attack. It is relevant to some of the proposed
> solutions. It should be possible, IIRC, for a malicious node to generate
> much longer chain with superslow timestamp increase (~5 blocks in 1 secon=
d)
> without increasing difficulty (i.e. staying at min. diff.). This could
> produce chain that is ~2500 times longer than main chain without having
> multiple branches.
>
That is a good point. It answers my question about formula for maximum
number of blocks.
5 * 60 * 60 * 24 * 365 =3D 157,680,000
That's around 150 million blocks per year at that rate.
I assume the 5 per second limit is that it is greater that the median of
the last 11 rather than greater or equal?
The timewarp bug can be fixed by a basic soft fork. You just need to limit
the maximum difference between the timestamp for the first header in a
period and the last header in the previous period.
An alternative would be to soft fork in a maximum block rate. In addition
to the current rules, you could limit it to a maximum of 1 block every 2
mins. That rule shouldn't activate normally.
block.height <=3D (block.timestamp - genesis.timestamp) / (2 mins)
It could have some weird incentives if it actually activated though.
Miners would have to shutdown mining if they were finding blocks to fast.
--00000000000074b94b0594bcbd70
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Sat, Oct 12, 2019 at 6:56 PM Joachim Str=C3=B6mbergson <<a hre=
f=3D"mailto:joachimstr@protonmail.com">joachimstr@protonmail.com</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I like=
the backwards syncing idea. First you provide proof of your best block hei=
ght via coinbase, then sync backwards. It solves lots of related problems. =
You know how much you can expect from the given peer.<br></div></blockquote=
><div><br></div><div>It shows you which nodes are on the same chain too.</d=
iv><div><br></div><div>If you have 8 peers and you ask the 8 of them for th=
eir 8 best, then they should all agree on most of them.</div><div><br></div=
><div>You can then ask each of the 8 to start sending you headers backwards=
from one of the 8 seeds.</div><div><br></div><div>They will all roughly sp=
lit the chain into 8 equal pieces, though the split will be based on work r=
ather than header height.</div><div><br></div><div>If there is disagreement=
, you can give priority to the node(s) with the lowest headers until they h=
ave completed their download.</div><div><br></div><div>It requires a networ=
k protocol change to allow reverse block downloads though (and messages to =
indicate lowest headers etc.)<br></div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div>On different note, one of the problems th=
at I haven't seen mentioned here yet is the timewarp attack. It is rele=
vant to some of the proposed solutions. It should be possible, IIRC, for a =
malicious node to generate much longer chain with superslow timestamp incre=
ase (~5 blocks in 1 second) without increasing difficulty (i.e. staying at =
min. diff.). This could produce chain that is ~2500 times longer than main =
chain without having multiple branches. <br></div></blockquote><div><br></d=
iv><div>That is a good point.=C2=A0 It answers my question about formula fo=
r maximum number of blocks.</div><div><br></div><div>5 * 60 * 60 * 24 * 365=
=3D 157,680,000</div><div><br></div><div>That's around 150 million blo=
cks per year at that rate.</div><div><br></div><div>I assume the 5 per seco=
nd limit is that it is greater that the median of the last 11 rather than g=
reater or equal?</div><div><br></div><div>The timewarp bug can be fixed by =
a basic soft fork.=C2=A0 You just need to limit the maximum difference betw=
een the timestamp for the first header in a period and the last header in t=
he previous period.</div><div><br></div><div>An alternative would be to sof=
t fork in a maximum block rate.=C2=A0 In addition to the current rules, you=
could limit it to a maximum of 1 block every 2 mins.=C2=A0 That rule shoul=
dn't activate normally.<br></div><div><br></div><div>=C2=A0=C2=A0 block=
.height <=3D (block.timestamp - genesis.timestamp) / (2 mins) <br></div>=
<div><br></div><div>It could have some weird incentives if it actually acti=
vated though.=C2=A0 Miners would have to shutdown mining if they were findi=
ng blocks to fast.<br></div></div></div>
--00000000000074b94b0594bcbd70--
|
