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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gacrux@gmail.com>) id 1XzPIN-000406-9M
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Dec 2014 12:26:07 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.54 as permitted sender)
client-ip=209.85.220.54; envelope-from=gacrux@gmail.com;
helo=mail-pa0-f54.google.com;
Received: from mail-pa0-f54.google.com ([209.85.220.54])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XzPIM-0005s2-E4
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Dec 2014 12:26:07 +0000
Received: by mail-pa0-f54.google.com with SMTP id fb1so7150379pad.41
for <bitcoin-development@lists.sourceforge.net>;
Fri, 12 Dec 2014 04:26:00 -0800 (PST)
X-Received: by 10.68.69.78 with SMTP id c14mr26036898pbu.68.1418387160679;
Fri, 12 Dec 2014 04:26:00 -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 h1sm1502717pat.6.2014.12.12.04.25.58
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 12 Dec 2014 04:25:59 -0800 (PST)
Message-ID: <548ADED1.6060300@gmail.com>
Date: Fri, 12 Dec 2014 23:25:53 +1100
From: Gareth Williams <gacrux@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <20141212090551.GA8259@muck>
In-Reply-To: <20141212090551.GA8259@muck>
OpenPGP: id=378E4544
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="0FjtPjXblO8RTPjs0CNDqmg1NP03Badpt"
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: 1XzPIM-0005s2-E4
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 12:26:07 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0FjtPjXblO8RTPjs0CNDqmg1NP03Badpt
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 12/12/14 20:05, Peter Todd wrote:
> Secondly using a limited-supply token in a proof-of-publicaton system i=
s
> what lets you have secure client side validation rather than the
> alternative of 2-way-pegging that requires users to trust miners not to=
> steal the pegged funds.=20
"Secure" and "client side validation" don't really belong in the same
sentence, do they?
If I am to accept a transaction with any assurance of security at all,
the important question to ask is not: "does my client consider this
valid?" but: "does the rest of the world consider this valid?"
Validated data in the blockchain is far more useful for this purpose
than unvalidated data with a mere proof of publication in the
blockchain, precisely because it records what /everybody else/ considers
valid history (and very likely will continue to consider valid history
in future.)
Pegged sidechains have their challenges, but at least they provide
distributed consensus on transaction history.
Proof-of-publication systems like Counterparty and Mastercoin require me
to trust, with zero evidence, that everybody else's client has the exact
same interpretation of transaction history as mine, and will continue to
have for the indefinite future. How is that not a horribly broken
security model? I'd use a sidechain - with reasonable parameters that
disincentivise peg theft as much as practical - over that any day.
--0FjtPjXblO8RTPjs0CNDqmg1NP03Badpt
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
iQEcBAEBAgAGBQJUit7RAAoJEEY5w2E3jkVEXeYIAMCDFUBN5fE/lrHv7k3WOA2C
ommijKVgOrV5LJGUp+d18SM/olbWUdLrULVA+XjPealTs9FKMDoX1suJ6cgcj/6L
+1SbdC5kh4U4MLXluPDyx6hDngsg2KeeahCapO5pK//p3M6ySbh7svXF/fMcf6/i
ku57j6rjQj/MOiKfE51Gqpigv5R+XZdnKzIrXSbOHdEnF92cBT8qTCDh3hWprMUw
A8LacYgg1Gcfu7bCS8PsoOm10IdG4qFK1guXP4oovdayef02lSRCDVjr0MA+1QfD
qL4iRN1xCEsuSI0Ed2AYaPkoF7khFhCAAVL/ksCwO2HUhxcLYHxlKmoWDwbUinc=
=S3TB
-----END PGP SIGNATURE-----
--0FjtPjXblO8RTPjs0CNDqmg1NP03Badpt--
|
