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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1WCYpf-0007hi-8f
for bitcoin-development@lists.sourceforge.net;
Sun, 09 Feb 2014 18:10:19 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.56 as permitted sender)
client-ip=62.13.149.56; envelope-from=pete@petertodd.org;
helo=outmail149056.authsmtp.com;
Received: from outmail149056.authsmtp.com ([62.13.149.56])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WCYpe-0005vQ-8X for bitcoin-development@lists.sourceforge.net;
Sun, 09 Feb 2014 18:10:19 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s19IA99M077140;
Sun, 9 Feb 2014 18:10:09 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s19IA5lJ056274
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sun, 9 Feb 2014 18:10:07 GMT
Date: Sun, 9 Feb 2014 13:09:38 -0500
From: Peter Todd <pete@petertodd.org>
To: Luke-Jr <luke@dashjr.org>
Message-ID: <20140209180938.GC20126@savin>
References: <20140209171214.GA20126@savin> <201402091725.42306.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="TYecfFk8j8mZq+dy"
Content-Disposition: inline
In-Reply-To: <201402091725.42306.luke@dashjr.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 689934c6-91b5-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgsUHlAWAgsB AmIbWlxeUV17WWs7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrABV4 dxtCKBl3cQdBfDB3 bENhEHZTVU15cRV7
X0dVR2gbZGY1a30W VBYJagNUcgZDfk5E aVUrVz1vNG8XDQg5
AwQ0PjZ0MThBJSBS WgQAK04nCWsOFDMw Sx0OVT4oG1YIQT4u
NFQ9O0UAEUNZL109 K1ItVDBQKwUVAQBS AltAG0cf
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/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: 1WCYpe-0005vQ-8X
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Embedded consensus system upgrade
procedures
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, 09 Feb 2014 18:10:19 -0000
--TYecfFk8j8mZq+dy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Feb 09, 2014 at 05:25:41PM +0000, Luke-Jr wrote:
> On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
> > We have an embedded consensus system and we want to be able to upgrade
> > it with new rules.
>=20
> This asserts a central authority and gives developers too much power.
Please, the rule change only can happen if users accept it.
If anything my proposed mechanism makes it even harder for developers to
impose anything by fiat: the spending your digital asset under new rules
decreases the amount available of it to trade with users who chose to
accept only the old rules. Since there is no safety concern involved,
the process is safe for both groups, developers can't plea to the
community that "OMG the sky will fall and you'll be all defrauded if you
don't upgrade right now!!!" Instead they'll be forced to make it clear
that if the community doesn't accept the new rules, whatever assets
you've moved to the new system may become forever worthless.
--=20
'peter'[:-1]@petertodd.org
000000000000000075829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0
--TYecfFk8j8mZq+dy
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJS98RhXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA3NTgyOWY2MTY5Yzc5ZDdkNWFhYTIwYmZhOGRhNmU5ZWRi
MjM5M2M0Zjg2NjJiYTAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvXZQf/aDDiEKvZqp8UxBVIkX0rchGv
CjC1u4+sg5bNKqOYutcp3w216nDvfylEw42DHUEbH6xmNSQ5qVPP9AVLP0iKf7iK
ebC9TrIYsxSWsyOzUK3saxw18nTJJmkM9Y3V3kcOifZaFXjqedSeZDfy0OlH1W7l
bi80CYphSzGsZEgxFjaOLTMZo6Sc8v1o8CEr0HtDzs86kqZZE2u9JFcUnmv3Bzgo
QDgb24rdEtEOwWi9ViaRRi6SIsYCZVABfZ16rCsjWAMZtxiZSnVa9qmkR4Y5HWYL
JGwAymJsqqbj+F18uB5rKOMkueWNPTIPaGBKLL2iDLBMttQahObAlkXXwCkmCg==
=+K+N
-----END PGP SIGNATURE-----
--TYecfFk8j8mZq+dy--
|
