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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1Y2Zkn-0000Wc-Rd
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Dec 2014 06:12:33 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.93 as permitted sender)
client-ip=62.13.148.93; envelope-from=pete@petertodd.org;
helo=outmail148093.authsmtp.net;
Received: from outmail148093.authsmtp.net ([62.13.148.93])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Y2Zkl-0005xO-94 for bitcoin-development@lists.sourceforge.net;
Sun, 21 Dec 2014 06:12:33 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id sBL6CO6c073389;
Sun, 21 Dec 2014 06:12:24 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 sBL6CL9g017874
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sun, 21 Dec 2014 06:12:23 GMT
Date: Sun, 21 Dec 2014 01:12:20 -0500
From: Peter Todd <pete@petertodd.org>
To: Gareth Williams <gacrux@gmail.com>
Message-ID: <20141221061220.GC8255@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>
<20141215045236.GB23859@savin.petertodd.org>
<CALohRkgbHvLCwAY0+2zpd-LwRxnntzcpPuUjU4zDEz=oODaK1w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="R+My9LyyhiUvIEro"
Content-Disposition: inline
In-Reply-To: <CALohRkgbHvLCwAY0+2zpd-LwRxnntzcpPuUjU4zDEz=oODaK1w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 5485b6a6-88d8-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAMUHFAXAgsB AmIbW1JeUV97W2c7 bA9PbARUfEhLXhtr
VklWR1pVCwQmQm59 AG1iW05ydgJOf3o+ ZEFlXnkVWUBycBR7
E0hJHWVSbXphaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDJTMg WxEEEn0zHUBNXSg4
KAYqYkUABk8QPUUu eVwnOxogKRgVBEhZ EQR1HSVdJlIIWyss C2sA
X-Authentic-SMTP: 61633532353630.1024: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: 1Y2Zkl-0005xO-94
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: Sun, 21 Dec 2014 06:12:33 -0000
--R+My9LyyhiUvIEro
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Dec 17, 2014 at 10:55:28PM +1100, Gareth Williams wrote:
> > I covered this in my original post: 1-way-pegs allow the creation of new
> > valuable tokens without those tokens being useful for speculation.
>=20
> I stand corrected. A permanent 1-way-peg is sufficient to preserve
> scarcity; "nothing else can do that" WRT 2-way-pegs was overreaching.
Yup.
> I still don't see what "2-way-peg vs. 1-way-peg" has to do with
> "embedded consensus vs. blockchain consensus" though, and feel it
> disingenious to conflate them.
1-way-pegs don't require the Bitcoin protocol to change; 2-way-pegs do.
> Blockchain consensus (eg. sidechains) can utilise either mechanism,
> 1-way-peg or 2-way-peg. Arguments in favour of 1-way-peg are
> interesting, but they're ultimatley just arguments in favour of one
> type of sidechain over another.
No, they're in favor of systems that are client-side validatable vs.
systems that either allow anyone with sufficient hashing power to steal
coins *or* require "moon-math" that isn't yet available to production
systems.
> IMO the question of whether scarcity can be preserved while enabling
> innovation bears heavily on the liklihood of longterm viability of
> said innovations - and perhaps of Bitcoin itself.
>=20
> FWIW I'll happily declare that I hold a modest amount of BTC and have
> an interest in the price appreciating. I'm sure you'll admit you're
> hardly an impartial party in this discussion yourself Peter :) But it
> really shouldn't matter. I'm not here today to make it, but I think
> the argument for preservation of scarcity stands quite well on its own
> merits - as rightly it should, regardless of anybody's interests.
But again, all these discussions about scarcity are fundementally
*moral* arguments that have no bearing on what's actually the most
appropriate solution for an *individual* problem.
In a decentralized system filled with anonymous actors telling people
"stop doing that! it's bad!" on reddit has pretty severe limitations in
trying to convince people to act against their own best interests.
> > 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
> Very interesting. I admit I hadn't come across these ideas before; I
> really must search the archive before posting :) They certainly offer
> a measure of robustness over the naive approach. I'm not sure they
> address my primary concerns however, WRT how consensus is demonstrated
> and incentivised.
I think you think consensus in Bitcoin is more "magical" than it really
is; Bitcoin is just code running on computers; consensus isn't really
incentivised at the protocol level beyond "screw it up and you'll lose
money"
Embedded consensus systems are no different: screw up consensus and
you'll lose money in a variety of ways.
> The obvious "embedded consensus" answer of "wait until N other
> transactions have occurred that include a hash of system state that
> includes your transaction" doesn't provide me with any confidence; it
> could be simulated with a Sybil attack.
No it can't - the transactions are in the blockchain so the sybil attack
has to attack the host system as well.
In any case, keep in mind all of this is in the context of tradeoffs:
for a different and sometimes more fragile consensus mechanism embedded
consensus gets immunity to attack by miners. You're trading off one type
of fragility for another - I'd much rather take the "one-time" fragility
inherent in having to write really solid software than the ongoing
fragility of always being vulnerable to miners.
Notably this is the exact same tradeoff taken elsewhere by the majority
of the crypto world.
--=20
'peter'[:-1]@petertodd.org
000000000000000017d70ee98f4cee509d95c4f31d5b998bae6deb09df1088fc
--R+My9LyyhiUvIEro
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJUlmTAXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxN2Q3MGVlOThmNGNlZTUwOWQ5NWM0ZjMxZDViOTk4YmFl
NmRlYjA5ZGYxMDg4ZmMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvNUAf/ZodoAZad5LS1qi8udjf6Md1u
xs3ZOQLSwXIV5I9itW6JWvmc9ZkmxQQvYFqngJFjjVF5fzhUIs2qM6qSa4A06yVh
rqER98LlAFyzSzMVRHIQbThSwIGHho+1HeXxN97+6LZSPoY9laBu9M7RDSPurxeH
5gZWwRn964D/E9TnUutTl2U07XygHG3S7E+SOSrSVHHK4iNCng2i5jMLcDnY4kXZ
kzJWyN8tc3QXrKzeGjQtUvhL3o3m+n2zIsrL4LlG7NtlpHHx/a/JoeFvMPqfdMvY
idm7k/78bCGwdqPmodYPUm4AsxP0pNb0cwiWCR8+e8ipH5nHOzXOzPSBpkUEuw==
=cDHW
-----END PGP SIGNATURE-----
--R+My9LyyhiUvIEro--
|
