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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1YsUqv-0007sE-DT
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 11:29:29 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.171 as permitted sender)
client-ip=209.85.220.171; envelope-from=tier.nolan@gmail.com;
helo=mail-qk0-f171.google.com;
Received: from mail-qk0-f171.google.com ([209.85.220.171])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YsUqu-000362-G8
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 11:29:29 +0000
Received: by qku63 with SMTP id 63so25504399qku.3
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 May 2015 04:29:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.150.209 with SMTP id 200mr27153675qhw.9.1431516563136;
Wed, 13 May 2015 04:29:23 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Wed, 13 May 2015 04:29:23 -0700 (PDT)
In-Reply-To: <CAE28kURWFveC0B-WvFebMpGm1GY-8juxQ+UDpuYtOwVnbOgu-A@mail.gmail.com>
References: <5550D8BE.6070207@electrum.org>
<ce3d34c92efd1cf57326e4679550944e@national.shitposting.agency>
<CABsx9T1VgxEJWxrYTs+2hXGnGrSLGJ6mVcAexjXLvK7Vu+e3EA@mail.gmail.com>
<5551F376.4050008@electrum.org>
<CABsx9T1h7p3hDr7ty43uxsYs-oNRpndzg=dowST2tXtogxRm2g@mail.gmail.com>
<555210AF.3090705@electrum.org>
<CABsx9T3AxM3et7hgXx3+Rn3BvhQkF-Cn797sHcyztkMpD1UQmA@mail.gmail.com>
<55531E19.3090503@electrum.org>
<CAE-z3OXa8vk6Q1EBChoRYDOLKw--CXNXz4AokXCbVam_8LFFDg@mail.gmail.com>
<CAE28kURWFveC0B-WvFebMpGm1GY-8juxQ+UDpuYtOwVnbOgu-A@mail.gmail.com>
Date: Wed, 13 May 2015 12:29:23 +0100
Message-ID: <CAE-z3OVBUu=6sqNc3RUJqFPuqhPdw1Ej0RZ-tSygoQ6LowhVXg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Alex Mizrahi <alex.mizrahi@gmail.com>
Content-Type: multipart/alternative; boundary=001a11356f763caa1e0515f4ec16
X-Spam-Score: 0.9 (/)
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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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
1.5 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YsUqu-000362-G8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
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, 13 May 2015 11:29:29 -0000
--001a11356f763caa1e0515f4ec16
Content-Type: text/plain; charset=UTF-8
On Wed, May 13, 2015 at 11:31 AM, Alex Mizrahi <alex.mizrahi@gmail.com>
wrote:
>
> But this matters if a new node has access to the globally strongest chain.
>
A node only needs a path of honest nodes to the network.
If a node is connected to 99 dishonest nodes and 1 honest node, it can
still sync with the main network.
>
> In practice, Bitcoin already embraces "weak subjectivity" e.g. in form of
> checkpoints embedded into the source code. So it's hard to take PoW purists
> seriously.
>
>
That isn't why checkpoints exist. They are to prevent a disk consumption
DOS attack.
They also allow verification to go faster. Signature operations are
assumed to be correct without checking if they are in blocks before the
last checkpoint.
They do protect against multi-month forks though, even if not the reason
that they exist.
If releases happen every 6 months, and the checkpoint is 3 months deep at
release, then for the average node, the checkpoint is 3 to 9 months old.
A 3 month reversal would be devastating, so the checkpoint isn't adding
much extra security.
With headers first downloading, the checkpoints could be removed. They
could still be used for speeding up verification of historical blocks.
Blocks behind the last checkpoint wouldn't need their signatures checked.
Removing them could cause a hard-fork though, so maybe they could be
defined as legacy artifacts of the blockchain. Future checkpoints could be
advisory.
--001a11356f763caa1e0515f4ec16
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, May 13, 2015 at 11:31 AM, Alex Mizrahi <span dir=3D"ltr"><<a=
href=3D"mailto:alex.mizrahi@gmail.com" target=3D"_blank">alex.mizrahi@gmai=
l.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=
=3D""></span>But this matters if a new node has access to the globally stro=
ngest chain.</div></div></div></blockquote><div><br></div><div>A node only =
needs a path of honest nodes to the network.<br><br></div><div>If a node is=
connected to 99 dishonest nodes and 1 honest node, it can still sync with =
the main network.<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><br><div>In practice,=
Bitcoin already embraces "weak subjectivity" e.g. in form of che=
ckpoints embedded into the source code. So it's hard to take PoW purist=
s seriously.</div></div></div></div>
<br></blockquote><div><br></div><div>That isn't why checkpoints exist.=
=C2=A0 They are to prevent a disk consumption DOS attack.<br><br></div><div=
>They also allow verification to go faster.=C2=A0 Signature operations are =
assumed to be correct without checking if they are in blocks before the las=
t checkpoint.<br></div><div><br>They do protect against multi-month forks t=
hough, even if not the reason that they exist.<br><br></div><div>If release=
s happen every 6 months, and the checkpoint is 3 months deep at release, th=
en for the average node, the checkpoint is 3 to 9 months old.<br><br></div>=
<div>A 3 month reversal would be devastating, so the checkpoint isn't a=
dding much extra security.<br><br></div><div>With headers first downloading=
, the checkpoints could be removed.=C2=A0 They could still be used for spee=
ding up verification of historical blocks.=C2=A0 Blocks behind the last che=
ckpoint wouldn't need their signatures checked.<br></div><div><br></div=
><div>Removing them could cause a hard-fork though, so maybe they could be =
defined as legacy artifacts of the blockchain.=C2=A0 Future checkpoints cou=
ld be advisory.<br></div></div></div></div>
--001a11356f763caa1e0515f4ec16--
|
