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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gacrux@gmail.com>) id 1XzmoG-0006el-6J
for bitcoin-development@lists.sourceforge.net;
Sat, 13 Dec 2014 13:32:36 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.180 as permitted sender)
client-ip=209.85.192.180; envelope-from=gacrux@gmail.com;
helo=mail-pd0-f180.google.com;
Received: from mail-pd0-f180.google.com ([209.85.192.180])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XzmoE-0004sP-Be
for bitcoin-development@lists.sourceforge.net;
Sat, 13 Dec 2014 13:32:36 +0000
Received: by mail-pd0-f180.google.com with SMTP id w10so8863000pde.11
for <bitcoin-development@lists.sourceforge.net>;
Sat, 13 Dec 2014 05:32:28 -0800 (PST)
X-Received: by 10.68.69.37 with SMTP id b5mr34866969pbu.102.1418477548599;
Sat, 13 Dec 2014 05:32:28 -0800 (PST)
Received: from [192.168.1.10] (60-240-212-53.tpgi.com.au. [60.240.212.53])
by mx.google.com with ESMTPSA id be3sm4283687pbc.33.2014.12.13.05.32.26
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 13 Dec 2014 05:32:27 -0800 (PST)
Message-ID: <548C3FE6.9090508@gmail.com>
Date: Sun, 14 Dec 2014 00:32:22 +1100
From: Gareth Williams <gacrux@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <20141212090551.GA8259@muck> <548ADED1.6060300@gmail.com> <CAE28kUR-PLzMGC23ETesc2Bz1_F1JfgcqyMW4qFvV5Vjk+ubbg@mail.gmail.com> <CAOG=w-v3qjG3zd_WhfFU-OGnsHZEuYvY82eL4GqcdgY6np5bvA@mail.gmail.com>
<CAE28kUSZcGrFL3OMf=uOJ2=NQ89M54FOhR_iOXkEubrb6qqVAg@mail.gmail.com>
In-Reply-To: <CAE28kUSZcGrFL3OMf=uOJ2=NQ89M54FOhR_iOXkEubrb6qqVAg@mail.gmail.com>
OpenPGP: id=378E4544
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="URKjGmjk80pF96KUQUBUQGAQ6dx8KE3F3"
X-Spam-Score: -1.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
(gacrux[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1XzmoE-0004sP-Be
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: Sat, 13 Dec 2014 13:32:36 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--URKjGmjk80pF96KUQUBUQGAQ6dx8KE3F3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 13/12/14 04:04, Alex Mizrahi wrote:
> 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 th=
e
> whole thing.
Comparisons with the SPV security of sidechains are fallacious. The
alternative to a proof-of-publication system reliant on client-side
validation is a blockchain. The question of whether the token used on
said blockchain should be two-way-pegged to BTC is completely orthogonal.=
(ie. yes, sidechains are "economically secure", in that you're reduced
to balancing economic incentives to avoid peg theft. But sidechains also
give us something unique in return - the ability to innovate without
needing to start new artificial scarcity races. Nothing else can do that.=
)
<snip>
> 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.
I hate to think what the outcome would've been on a proof-of-publication
system. You don't even have a fork. You just have a whole bunch of nodes
who sort-of-mostly agree on a shared history, except where they don't.
Maybe they just disagree on the validity of a single transaction.
They'll slowly diverge over time (as bad transactions are used as input
to other transactions.) You have no reliable way to detect this lapse in
consensus, nor any mechanism to incentivse convergence. Indeed, you have
no consensus mechanism in the first place.
Bitcoin is where it is today because of Satoshi's elegant solution to
exactly such problems. Which some people now appear to be in a hurry to
discard :)
Alex Mizrahi wrote:
> Using scheduled updates: client simply stops working at a certain block=
,
> and user is required to download an update.
<snip>
> An alternative to this is to make updates mandatory. You will no longer=
> need to maintain compatibility with version 0.1 (which is impossible)
> and you can also evolve consensus rules over time.
Peter Todd might disagree with the wisdom of that :) He wrote an
excellent email to this list not long ago warning of the dangers of
centralisation. IIRC one point he made was that scheduled, regular
hardforks were a real threat - if a single entity (eg. the Bitcoin
Foundation) were to become politically established as the coordinator of
such forks, they would have de-facto control over the protocol.
Even in that dark scenario, I would feel a measure of confidence that
past transactions I had received could not be tampered with. The fact
that those transactions happened, and that there was (and is) consensus
they were valid, is publicly documented in the blockchain. I trust any
reasonable person would not accept a client that ignored validated data
in the blockchain as "Bitcoin" any more.
Your proof-of-publication system with mandatory updates is another
matter entirely. No public record of transactions I have received with
that system exists, anywhere. If tomorrow's mandatory update has the
effect of zeroing my account balance (by happening to now interpret one
or more transactions I received, or their inputs, as invalid) then I
have no recourse. I won't find sympathy with the majority of users, who
are unaffected and just accept the update.
In short, what you describe doesn't sound very decentralised :) Do you
want transactions you receive validated by distributed consensus and
burried under PoW, or validated by some guy's mandatory-updating python
script?
(Also worth noting: all such systems are effectively "mandatory
updating" due to the risk of subtle consensus bugs of the type I
described above. Your only assurance that your view of the world is the
same as everyone elses' is that you're running the exact same software.
I played with Counterparty a while ago and quickly learned - the hard
way - to do a 'git pull' before any important operation.)
--URKjGmjk80pF96KUQUBUQGAQ6dx8KE3F3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUjD/mAAoJEEY5w2E3jkVEZXoIAIsSWprMJ5cKt093sSVlxB/+
0SpfEgsx6wGnr7O5c3MY2SG+/KKB3IF8L8v2Truc0e8P2aa8tepB0Yk1f2vbwcY5
mJRfYgDA5fOH4PYX7Khq36PdaAuFjDvtJNTwhxVN5Q5bz3WLlDzd3IEZqSp/7NiP
hhhUa4BuI4Vdz3EpEPbhgCQVd1qXsfxGe6nNwMrZZi/eMQE10StibHKfQOPpxmrf
1T0fc1QfRVMPpU04xTB8f4n9tlxKqSinEvQ/9hRdGDEWyuw0BuHiv9YDeZaogcqO
rGgBIvts8tX06EsXBx2IVkX9FMbGux9t/ncanbVljk4Qdl9aU7E3RMq3qKU9Gwc=
=IKbX
-----END PGP SIGNATURE-----
--URKjGmjk80pF96KUQUBUQGAQ6dx8KE3F3--
|
