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
|
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E66728A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Jan 2017 10:36:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com
[209.85.161.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A81B288
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Jan 2017 10:36:17 +0000 (UTC)
Received: by mail-yw0-f182.google.com with SMTP id u68so31720513ywg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Jan 2017 02:36:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=821aY9B5JOBzOJ/DI8cqODdfOw3jHSqDumxyKUIgyY0=;
b=dK6Xo9NazFljBZdSAmfnfFpBDP1lk0ZnNlH+FS1PL+Ca/ad+pY/ErpA8eTDB9MGwup
PmyDzmqh2fHisWDfLa9KkizE1p0bi76BNQ6/nnAw/qmhPHUJCwouhdzFnC1RFo2CIgl9
mHkMBIPm4DmbT/EJLOI7Kv5wcRAa2F1H9gvRSS55qHaX+XQOGV7h7B2GmEkjqCAudF+e
tacS9OJs9Ok/nkfRWFJJ0H4GdXDvp55If7TClpNRxEB9U6NUcKuIyqxe37ZE2w0jdrGM
cQzlhNBa1HFKh3grETm+TBuS6VjQu2RsCadhoCYE/tXsqWY8+bJYBAQR4hNKrf+9KaSc
/TiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=821aY9B5JOBzOJ/DI8cqODdfOw3jHSqDumxyKUIgyY0=;
b=hixnnNoJgmuB1TPt4dijYGDSY9T99CpZx7R1DqxjNbTfCAtx0b++i3bodW4WxQQ8yY
Qag6ywgvwgJFFCllbdNtyZOfMILJe/rI+nK+yyqoijgoqqShB1l0xHMcYZzT11zSrUO8
LYVXDPwJilbv0jD2XRD3VSynviaN4MGbFGm+Fd9++0UQHzLK0dUeFGIBZkOgnNyEw4Xv
JyRoLxnzgwg9UPrsZpgs+dQbyUcYu8XjIpr+kySmDtDGTDpRyKhZhlJArzH1bEjK+Ll7
CbT5gtOzZS4KLd4dYNzL59WJqWc3kNZttoe1FRazsxHQ9HGuJGYFo06T6XMXMAE1Iw+j
QHgg==
X-Gm-Message-State: AIkVDXJ1OFlZdx072kGlvDujBN0juIeztG0fWcGKMbllRXHegDzbT4vmPVMHS6fexIjhhL5XfxdBQji0yMF0SQ==
X-Received: by 10.13.222.68 with SMTP id h65mr8139323ywe.197.1485599776940;
Sat, 28 Jan 2017 02:36:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.75.67 with HTTP; Sat, 28 Jan 2017 02:36:16 -0800 (PST)
Received: by 10.37.75.67 with HTTP; Sat, 28 Jan 2017 02:36:16 -0800 (PST)
In-Reply-To: <201701280403.05558.luke@dashjr.org>
References: <201701270107.01092.luke@dashjr.org> <20170127212810.GA5856@nex>
<CAAy62_KUSNTjivwJT87K9f1c=k-6gdaLXEBJjcy2KK+uLSTWDA@mail.gmail.com>
<201701280403.05558.luke@dashjr.org>
From: Natanael <natanael.l@gmail.com>
Date: Sat, 28 Jan 2017 11:36:16 +0100
Message-ID: <CAAt2M183=L=9N3HKVgGbsFbug4LWkGfMQzzcDQu9xxMJL+L1oA@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c07cfc0fbaa92054725269e
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
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, 28 Jan 2017 10:36:19 -0000
--94eb2c07cfc0fbaa92054725269e
Content-Type: text/plain; charset=UTF-8
Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
Satoshi envisioned a system where full nodes could publish proofs of invalid
blocks that would be automatically verified by SPV nodes and used to ensure
even they maintained the equivalent of full node security so long as they
were
not isolated. But as a matter of fact, this vision has proven impossible,
and
there is to date no viable theory on how it might be fixed. As a result, the
only way for nodes to have full-node-security is to actually be a true full
node, and therefore the plan of only having full nodes in datacenters is
simply not realistic without transforming Bitcoin into a centralised system.
Beside Zero-knowledge proofs, which is capable of proving much so more than
just validity, there are multi types of fraud proofs that only rely on the
format of the blocks. Such as publishing the block header + the two
colliding transactions included in it (in the case of double spending), or
if the syntax or logic is broken then you just publish that single
transaction.
There aren't all that many cases where fraud proofs are unreasonably large
for a networked system like in Bitcoin. If Zero-knowledge proofs can be
applied securely, then I can't think of any exceptions at all for when the
proofs would be unmanageable. (Remember that full Zero-knowledge proofs can
be chained together!)
--94eb2c07cfc0fbaa92054725269e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div clas=
s=3D"gmail_quote">Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoi=
n-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi=
tcoin-dev@lists.linuxfoundation.org</a>>:<blockquote class=3D"quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Satosh=
i envisioned a system where full nodes could publish proofs of invalid<br>
blocks that would be automatically verified by SPV nodes and used to ensure=
<br>
even they maintained the equivalent of full node security so long as they w=
ere<br>
not isolated. But as a matter of fact, this vision has proven impossible, a=
nd<br>
there is to date no viable theory on how it might be fixed. As a result, th=
e<br>
only way for nodes to have full-node-security is to actually be a true full=
<br>
node, and therefore the plan of only having full nodes in datacenters is<br=
>
simply not realistic without transforming Bitcoin into a centralised system=
.<br>
<div class=3D"quoted-text"></div></blockquote></div></div><div dir=3D"auto"=
><br></div><div dir=3D"auto">Beside Zero-knowledge proofs, which is capable=
of proving much so more than just validity, there are multi types of fraud=
proofs that only rely on the format of the blocks. Such as publishing the =
block header + the two colliding transactions included in it (in the case o=
f double spending), or if the syntax or logic is broken then you just publi=
sh that single transaction.=C2=A0</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">There aren't all =C2=A0that many cases where fraud proofs are=
unreasonably large for a networked system like in Bitcoin. If Zero-knowled=
ge proofs can be applied securely, then I can't think of any exceptions=
at all for when the proofs would be unmanageable. (Remember that full Zero=
-knowledge proofs can be chained together!)=C2=A0</div><div class=3D"gmail_=
extra" dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v class=3D"quoted-text"></div></blockquote></div><br></div></div>
--94eb2c07cfc0fbaa92054725269e--
|
