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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1Y0N69-00048v-3H
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Dec 2014 04:17:29 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.106 as permitted sender)
client-ip=62.13.148.106; envelope-from=pete@petertodd.org;
helo=outmail148106.authsmtp.co.uk;
Received: from outmail148106.authsmtp.co.uk ([62.13.148.106])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Y0N67-0003jE-Ce for bitcoin-development@lists.sourceforge.net;
Mon, 15 Dec 2014 04:17:29 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBF4HJsl041168;
Mon, 15 Dec 2014 04:17:19 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 sBF4HFFO055586
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 15 Dec 2014 04:17:17 GMT
Date: Sun, 14 Dec 2014 23:17:14 -0500
From: Peter Todd <pete@petertodd.org>
To: Alex Mizrahi <alex.mizrahi@gmail.com>
Message-ID: <20141215041714.GA23859@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo"
Content-Disposition: inline
In-Reply-To: <CAE28kUSZcGrFL3OMf=uOJ2=NQ89M54FOhR_iOXkEubrb6qqVAg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 42098c72-8411-11e4-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwcUHFAXAgsB AmIbW1BeUVp7WGs7 bA9PbARUfEhLXhtr
VklWR1pVCwQmQm53 AmZoJGZycgBDcHg+ ZE9lXXYVWEZ6fE4u
RUxJHWkHZHphaTUb 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: 1Y0N67-0003jE-Ce
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Mark Friedenbach <mark@friedenbach.org>
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:17:29 -0000
--envbJBWh7q8WU6mo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Dec 12, 2014 at 07:50:48PM +0200, Alex Mizrahi wrote:
> > I think what Gareth was getting at was that with client-side validation
> > there can be no concept of a soft-fork. And how certain are you that the
> > consensus rules will never change?
> >
>=20
> Yes, it is true that you can't do a soft-fork, but you can do a hard-fork.
> Using scheduled updates: client simply stops working at a certain block,
> and user is required to download an update.
You're quite mistaken actually. One of the first things to come out of
my research as Mastercoin's Chief Scientist - indeed after a week on the
job - was how to safely upgrade embedded consensus systems in a
decentralized fashion:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03=
890.html
To recap, where valuable scarce tokens are concerned we want to ensure
that an attacker can't use a fork caused by an upgrade to double-spend
tokens. We solve this problem by ensuring that when a token visible to
version V_i is spent in a V_{i+1} client, the token appears spent to
version V_i clients as well. This is easy to accomplish by a "split
transaction" scheme that separates all operations into separate
"increment" and "decrement" operations.
The simplest example of this principle in action is colored coins, which
are certainly an example of an embedded consensus system. Colored coin
implementations naturally ensure that all versions of the system see a
token getting spent the same way - the corresponding txout is spent! So
long as changes to the coloring rules are handled such that only one set
of rules - one version - can apply to a given txout spend we get
anti-doublespend protection.
The second aspect of the problem is the social/political implications of
upgrades - because embedded consensus systems don't outsource trust they
very clearly require the co-operation of the economic majority in an
upgrade. For instance if the community has two competing proposals for
how to upgrade version V1 of Counterparty, V2a and V2b, choosing to move
your tokens to either version becomes a vote with serious economic
consequences. In fact, it's quite possible that a community would choose
to simply fork into two different systems each offering a different set
of features. Equally in the event of such a fork someone can create a
third version, V3, that recombines the two incompatible forks. Again,
anyone who agrees with version V3 can choose to move their tokens to it,
healing the fork.
Arguably this process of handling forks by direct economic voting is
significantly *more* decentralized than Bitcoin's soft-fork mechanism as
adoption of a new version is something all participants in the system
play a part in equally. (as measured by economic stake) Of course, it
will lead to sometimes ugly political battles, but that's simply part of
the cost of having democratic systems.
> It looks like people make a cargo cult out of Bitcoin's emergent
> properties.
+1
--=20
'peter'[:-1]@petertodd.org
00000000000000000681f4e5c84bc0bf7e6c5db8673eef225da652fbb785a0de
--envbJBWh7q8WU6mo
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJUjmDDXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNjgxZjRlNWM4NGJjMGJmN2U2YzVkYjg2NzNlZWYyMjVk
YTY1MmZiYjc4NWEwZGUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuOIAf9GqXAeWQaVe3KMDJUMFIvRaQg
MoDiBJjyameAT9LCm1x21KQrTmD+bOpO7inBpEN8cuUNL0t7Q1mlAIcKbEipe70Q
0EKjxIZnVyvfClLOVlQC/APn2iJbvvqJyfYxff72t1jYWWWREWWbcdq1fcQGrr0K
DlL1FlEudVKlqGTESiZQ8G8DIkTDs8hTbq0QBL0xuJl8QKT3TDXro27G1UDvrl19
hWY/mGnkv9RbVcN0xYlK/ZbAYWeewuW/HQYucVA0xiDO2j4loEuah4gLHl6BQFlD
02hdewGftjsJhOi9eHYHOqUnTeWZdo8EyyVglil9LwdXan4ekdDlZVhHo0c/1Q==
=ZXeF
-----END PGP SIGNATURE-----
--envbJBWh7q8WU6mo--
|
