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
192
193
194
195
196
197
198
199
200
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1Y0NeM-0005Fs-7I
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Dec 2014 04:52:50 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.100 as permitted sender)
client-ip=62.13.148.100; envelope-from=pete@petertodd.org;
helo=outmail148100.authsmtp.co.uk;
Received: from outmail148100.authsmtp.co.uk ([62.13.148.100])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Y0NeK-0004jH-Hv for bitcoin-development@lists.sourceforge.net;
Mon, 15 Dec 2014 04:52:50 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBF4qfU3017544;
Mon, 15 Dec 2014 04:52:41 GMT
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBF4qaCh057817
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 15 Dec 2014 04:52:39 GMT
Date: Sun, 14 Dec 2014 23:52:36 -0500
From: Peter Todd <pete@petertodd.org>
To: Gareth Williams <gacrux@gmail.com>
Message-ID: <20141215045236.GB23859@savin.petertodd.org>
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>
<548C3FE6.9090508@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="UHN/qo2QbUvPLonB"
Content-Disposition: inline
In-Reply-To: <548C3FE6.9090508@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 329f37dd-8416-11e4-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwcUHFAXAgsB AmIbW1BeVV97XWM7 bA9PbARUfEhLXhtr
VklWR1pVCwQmQm53 Al9PIUFycgJOeXk+ Z0ZqXXgVX0ZzI0V6
FhpJHWkHY3phaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDJTMg WxEEEn0zHUBNXSg4
KAYqYkUABk8QPUUu eVwnOxogKRgVBEhZ EQR1HSVdJlIIWyss C2sA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1Y0NeK-0004jH-Hv
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: Mon, 15 Dec 2014 04:52:50 -0000
--UHN/qo2QbUvPLonB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Dec 14, 2014 at 12:32:22AM +1100, Gareth Williams wrote:
> 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 the
> > whole thing.
>=20
> 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.
>=20
> (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.)
I covered this in my original post: 1-way-pegs allow the creation of new
valuable tokens without those tokens being useful for speculation.
To recap, a 1-way-peg allows the conversion of Bitcoins to another token
by provably destroying the Bitcoins, thus capping the maximum possible
value of that token and ensuring the token can-not become an investment.
For owners of these tokens they can convert them back to Bitcoin by
selling them at a discount to buyers who would otherwise be able to
purchase them via provable destruction. A pragmatic implementation may
wish to make obtaining the token via destruction option unattractive
compared to obtaining them through trade by incorporating a time delay
into the destruction process to encourage liquidity. (interestingly a
natural outcome of an announce-commit sacrifice-to-fees scheme)
Of course even without 1-way-pegs there's a much more important issue
with your objection: worrying about creating new artificial scarcity
races while innovating is fundementally a *moralistic* and *regulatory*
concern that has no little if any bearing on whether or not the systems
created are useful and secure. It's also an objection that raises
serious questions about conflicts of interest between giving accurate
and honest technical advice and promoting ways of using Bitcoin that
will drive the price up.
> > 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.
>=20
> 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.
A number of mechanisms for detecting divergence are possible in embedded
consensus systems, some of them even natural outcomes. For instance
transactions can contain a hash of the previous consensus state, thereby
creating an indicator of consensus measured in terms of economic stake.
Extending that idea many anti-censorship proposals are to use such state
hashes as encryption keys - if you are out of consensus you won't even
see the transaction. (and you can't be double-spent either if
implemented correctly; see my other reply to this thread today)
> 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 :)
FWIW usually Satoshi's solution is described as a hack, sometimes as an
elegant hack.
> 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.
Indeed I did, which is why I worked out a better way to do upgrades
almost a year ago:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06=
578.html
> (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.)
The quality of Counterparty's software engineering has no bearing on
whether or not the underlying idea is a good one; you wouldn't say ring
signatures are an inherently bad idea just because the CryptoNote
implementation of them is atrocious.
--=20
'peter'[:-1]@petertodd.org
00000000000000000681f4e5c84bc0bf7e6c5db8673eef225da652fbb785a0de
--UHN/qo2QbUvPLonB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJUjmkPXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNjgxZjRlNWM4NGJjMGJmN2U2YzVkYjg2NzNlZWYyMjVk
YTY1MmZiYjc4NWEwZGUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfs0XAf/Z1zlK33od+r1n9SWggG/8YJT
3MvtMJbjbKNJlA3ACcSBRATM4yieBdfXBh0rbnD0CBgI/v5d0idENjEQ/Hgxbl9I
gVmM72lGYsB3Oq+ChCo0IV3CN3fJXeMG5Zj1GfCwYJCB6f5lNs73J/lma4wf14uX
R1GVYQrcUBZ61s1RP3FtY/UBtiV8AlqTQDUIjDyVoSmhmib55j3I3DZaZpuhF144
qJXL4TxGWGvuXlNUDFwqJx7ZAcDHCowBWPUppzovuf3bNAt6iACi86qWIwXciOY+
2WSr4No1e8+IWXRdWTtDEpE70xwNOaJTks3jO2tb2HmFCG8sydv5WjJeZDIXkw==
=L8Hx
-----END PGP SIGNATURE-----
--UHN/qo2QbUvPLonB--
|
