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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alex.mizrahi@gmail.com>) id 1XzTdX-0000tH-J0
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Dec 2014 17:04:15 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.47 as permitted sender)
client-ip=74.125.82.47; envelope-from=alex.mizrahi@gmail.com;
helo=mail-wg0-f47.google.com;
Received: from mail-wg0-f47.google.com ([74.125.82.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XzTdW-0005e0-Ii
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Dec 2014 17:04:15 +0000
Received: by mail-wg0-f47.google.com with SMTP id n12so9541887wgh.6
for <bitcoin-development@lists.sourceforge.net>;
Fri, 12 Dec 2014 09:04:08 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.74.68 with SMTP id r4mr9166782wiv.33.1418403848451; Fri,
12 Dec 2014 09:04:08 -0800 (PST)
Received: by 10.27.203.198 with HTTP; Fri, 12 Dec 2014 09:04:08 -0800 (PST)
In-Reply-To: <548ADED1.6060300@gmail.com>
References: <20141212090551.GA8259@muck>
<548ADED1.6060300@gmail.com>
Date: Fri, 12 Dec 2014 19:04:08 +0200
Message-ID: <CAE28kUR-PLzMGC23ETesc2Bz1_F1JfgcqyMW4qFvV5Vjk+ubbg@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Gareth Williams <gacrux@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043d67e588fb6b050a07e18b
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: 1XzTdW-0005e0-Ii
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Setting the record straight on
Proof-of-Publication
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: Fri, 12 Dec 2014 17:04:15 -0000
--f46d043d67e588fb6b050a07e18b
Content-Type: text/plain; charset=UTF-8
>
> "Secure" and "client side validation" don't really belong in the same
> sentence, do they?
>
Well, client-side validation is mathematically secure, while SPV is
economically secure.
I.e. it is secure if you make several assumptions about economics of the
whole thing.
In my opinion the former is transfinitely more secure than the later.
But it's more of a philosophical question, sure.
The good thing about PoW-based consensus is that it is robust against
version inconsistencies and various accidents of this nature up to a
certain degree. But you hardly can depend on that:
You know, The Great Fork of 2013 was resolved through human intervention,
Bitcoin nodes were not smart enough to detect that something is going awry
on their own.
Naive proof-of-publication is very fragile in that respect, but you can
easily bring back robustness.
--f46d043d67e588fb6b050a07e18b
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">"Secure" and "client side validat=
ion" don't really belong in the same<br>
sentence, do they?<br></blockquote><div><br></div><div>Well, client-side va=
lidation is mathematically secure, while SPV is economically secure.</div><=
div>I.e. it is secure if you make several assumptions about economics of th=
e whole thing.</div><div><br></div><div>In my opinion the former is transfi=
nitely more secure than the later.</div><div>But it's more of a philoso=
phical question, sure.</div><div><br></div><div>The good thing about PoW-ba=
sed consensus is that it is robust against version inconsistencies and vari=
ous accidents of this nature up to a certain degree. But you hardly can dep=
end on that:=C2=A0</div><div>You know, The Great Fork of 2013 was resolved =
through human intervention, Bitcoin nodes were not smart enough to detect t=
hat something is going awry on their own.</div><div><br></div><div>Naive pr=
oof-of-publication is very fragile in that respect, but you can easily brin=
g back robustness.=C2=A0</div></div></div></div>
--f46d043d67e588fb6b050a07e18b--
|
