From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XzPIN-000406-9M for bitcoin-development@lists.sourceforge.net; Fri, 12 Dec 2014 12:26:07 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.54 as permitted sender) client-ip=209.85.220.54; envelope-from=gacrux@gmail.com; helo=mail-pa0-f54.google.com; Received: from mail-pa0-f54.google.com ([209.85.220.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XzPIM-0005s2-E4 for bitcoin-development@lists.sourceforge.net; Fri, 12 Dec 2014 12:26:07 +0000 Received: by mail-pa0-f54.google.com with SMTP id fb1so7150379pad.41 for ; Fri, 12 Dec 2014 04:26:00 -0800 (PST) X-Received: by 10.68.69.78 with SMTP id c14mr26036898pbu.68.1418387160679; Fri, 12 Dec 2014 04:26:00 -0800 (PST) Received: from [192.168.1.10] (60-240-212-53.tpgi.com.au. [60.240.212.53]) by mx.google.com with ESMTPSA id h1sm1502717pat.6.2014.12.12.04.25.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Dec 2014 04:25:59 -0800 (PST) Message-ID: <548ADED1.6060300@gmail.com> Date: Fri, 12 Dec 2014 23:25:53 +1100 From: Gareth Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <20141212090551.GA8259@muck> In-Reply-To: <20141212090551.GA8259@muck> OpenPGP: id=378E4544 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0FjtPjXblO8RTPjs0CNDqmg1NP03Badpt" X-Spam-Score: -1.6 (-) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gacrux[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XzPIM-0005s2-E4 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: Fri, 12 Dec 2014 12:26:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0FjtPjXblO8RTPjs0CNDqmg1NP03Badpt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/12/14 20:05, Peter Todd wrote: > Secondly using a limited-supply token in a proof-of-publicaton system i= s > what lets you have secure client side validation rather than the > alternative of 2-way-pegging that requires users to trust miners not to= > steal the pegged funds.=20 "Secure" and "client side validation" don't really belong in the same sentence, do they? If I am to accept a transaction with any assurance of security at all, the important question to ask is not: "does my client consider this valid?" but: "does the rest of the world consider this valid?" Validated data in the blockchain is far more useful for this purpose than unvalidated data with a mere proof of publication in the blockchain, precisely because it records what /everybody else/ considers valid history (and very likely will continue to consider valid history in future.) Pegged sidechains have their challenges, but at least they provide distributed consensus on transaction history. Proof-of-publication systems like Counterparty and Mastercoin require me to trust, with zero evidence, that everybody else's client has the exact same interpretation of transaction history as mine, and will continue to have for the indefinite future. How is that not a horribly broken security model? I'd use a sidechain - with reasonable parameters that disincentivise peg theft as much as practical - over that any day. --0FjtPjXblO8RTPjs0CNDqmg1NP03Badpt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUit7RAAoJEEY5w2E3jkVEXeYIAMCDFUBN5fE/lrHv7k3WOA2C ommijKVgOrV5LJGUp+d18SM/olbWUdLrULVA+XjPealTs9FKMDoX1suJ6cgcj/6L +1SbdC5kh4U4MLXluPDyx6hDngsg2KeeahCapO5pK//p3M6ySbh7svXF/fMcf6/i ku57j6rjQj/MOiKfE51Gqpigv5R+XZdnKzIrXSbOHdEnF92cBT8qTCDh3hWprMUw A8LacYgg1Gcfu7bCS8PsoOm10IdG4qFK1guXP4oovdayef02lSRCDVjr0MA+1QfD qL4iRN1xCEsuSI0Ed2AYaPkoF7khFhCAAVL/ksCwO2HUhxcLYHxlKmoWDwbUinc= =S3TB -----END PGP SIGNATURE----- --0FjtPjXblO8RTPjs0CNDqmg1NP03Badpt--