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
188
189
190
191
|
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 <alex.mizrahi@gmail.com>) id 1YsXch-0006CG-R5
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 14:26:59 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.182 as permitted sender)
client-ip=209.85.212.182; envelope-from=alex.mizrahi@gmail.com;
helo=mail-wi0-f182.google.com;
Received: from mail-wi0-f182.google.com ([209.85.212.182])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YsXcg-0000aD-MH
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 14:26:59 +0000
Received: by widdi4 with SMTP id di4so58130606wid.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 May 2015 07:26:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.78.49 with SMTP id y17mr19312056wjw.131.1431527212663;
Wed, 13 May 2015 07:26:52 -0700 (PDT)
Received: by 10.27.102.73 with HTTP; Wed, 13 May 2015 07:26:52 -0700 (PDT)
In-Reply-To: <CAE-z3OWBVjUog7m9C4P4BHeZe6dy7Dt9f3+kSa6f3v3=oNQJmQ@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>
<CAE-z3OVBUu=6sqNc3RUJqFPuqhPdw1Ej0RZ-tSygoQ6LowhVXg@mail.gmail.com>
<CAE28kUR-0ozFg6D4Es7RCm1pA5xaW-E1R_YSTRRTj3z4XXiWxw@mail.gmail.com>
<CAE-z3OWBVjUog7m9C4P4BHeZe6dy7Dt9f3+kSa6f3v3=oNQJmQ@mail.gmail.com>
Date: Wed, 13 May 2015 17:26:52 +0300
Message-ID: <CAE28kUQveZ9BVAG9XSnwxv0aGBx7sMpe7kPXvvO0Zr7Q9A3vjA@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7bfcf1deff52bb0515f766c8
X-Spam-Score: -0.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
(alex.mizrahi[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
X-Headers-End: 1YsXcg-0000aD-MH
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 14:26:59 -0000
--047d7bfcf1deff52bb0515f766c8
Content-Type: text/plain; charset=UTF-8
> I don't really see how you can protect against total isolation of a node
> (POS or POW). You would need to find an alternative route for the
> information.
>
"Alternative route for the information" is the whole point of weak
subjectivity, no?
PoS depends on weak subjectivity to prevent "long term reversals", but
using it also prevents "total isolation" attacks.
The argument that PoW is better than PoS because PoS has to depend on weak
subjectivity, but PoW doesn't is wrong.
Any practical implementation of PoW will also have to rely on weak
subjectivity to be secure against isolation attack.
And if we have to rely on weak subjectivity anyway, then why not PoS?
> Again, it is part of the security model that you can connect to at least
> one honest node.
>
This is the security model of PoW-based consensus. If you study
PoW-consensus, then yes, this is the model you have to use.
But people use Bitcoin Core as a piece of software. They do not care what
security model you use, they expect it to work.
If there are realistic scenarios in which it fails, then this must be
documented. Users should be made aware of the problem, should be able to
take preventative measures (e.g. manually check the latest block against
sources they trust), etc.
> The problem is that if everyone uses the same check, then that source can
> be compromised.
>
Yes, this problem cannot be solved in a 100% decentralized and automatic
way.
Which doesn't mean it's not worth solving, does it?
1. There are non-decentralized, trust-based solutions: refuse to work if
none of well-known nodes are accessible.
Well-known nodes are already used for bootstrapping, and this is another
point which can be attacked.
So if it's impossible to make it 100% decentralized and secure, why not
make it 99% decentralized and secure?
2. It is a common practice to check sha256sum after downloading the
package, and this is usually done manually.
Why can't checking block hashes against some source become a common
practice as well?
Also it's worth noting that these security measures are additive.
Isolating a node AND hijacking one of well-known nodes AND hijacking a
block explorer site user checks hashes against is exponentially harder than
defeating a single measure.
--047d7bfcf1deff52bb0515f766c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><span class=3D""><div></div></span><div>I don'=
;t really see how you can protect against total isolation of a node (POS or=
POW). You would need to find an alternative route for the information.=C2=
=A0</div></div></div></div></blockquote><div><br></div><div>"Alternati=
ve route for the information" is the whole point of weak subjectivity,=
no?</div><div><br></div><div>PoS depends on weak subjectivity to prevent &=
quot;<span style=3D"font-size:12.7272720336914px">long term reversals"=
, but using it also prevents "total isolation" attacks.</span></d=
iv><div><span style=3D"font-size:12.7272720336914px"><br></span></div><div>=
The argument that PoW is better than PoS because PoS has to depend on weak =
subjectivity, but PoW doesn't is wrong.</div><div>Any practical impleme=
ntation of PoW will also have to rely on weak subjectivity to be secure aga=
inst isolation attack.</div><div>And if we have to rely on weak subjectivit=
y anyway, then why not PoS?</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Again, =
it is part of the security model that you can connect to at least one hones=
t node.<br></div></div></div></div></blockquote><div><br></div><div>This is=
the security model of PoW-based consensus. If you study PoW-consensus, the=
n yes, this is the model you have to use.</div><div><br></div><div>But peop=
le use Bitcoin Core as a piece of software. They do not care what security =
model you use, they expect it to work.=C2=A0</div><div>If there are realist=
ic scenarios in which it fails, then this must be documented. Users should =
be made aware of the problem, should be able to take preventative measures =
(e.g. manually check the latest block against sources they trust), etc.</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><div>The problem is that if everyone uses t=
he same check, then that source can be compromised.<br></div></div></div></=
div></blockquote><div><br></div><div>Yes, this problem cannot be solved in =
a 100% decentralized and automatic way.</div><div>Which doesn't mean it=
's not worth solving, does it?</div><div><br></div><div>1. There are no=
n-decentralized, trust-based solutions: refuse to work if none of well-know=
n nodes are accessible.</div><div>Well-known nodes are already used for boo=
tstrapping, and this is another point which can be attacked.</div><div>So i=
f it's impossible to make it 100% decentralized and secure, why not mak=
e it 99% decentralized and secure?</div><div><br></div><div>2. It is a comm=
on practice to check sha256sum after downloading the package, and this is u=
sually done manually.</div><div>Why can't checking block hashes against=
some source become a common practice as well?<br></div><div><br></div><div=
>=C2=A0</div><div>Also it's worth noting that these security measures a=
re additive.</div><div>Isolating a node AND hijacking one of well-known nod=
es AND hijacking a block explorer site user checks hashes against is expone=
ntially harder than defeating a single measure.</div><div><br></div></div><=
/div></div>
--047d7bfcf1deff52bb0515f766c8--
|
