From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Alex Mizrahi Message-ID: <20141215041714.GA23859@savin.petertodd.org> References: <20141212090551.GA8259@muck> <548ADED1.6060300@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: 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 , Mark Friedenbach 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--