Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y0NeM-0005Fs-7I for bitcoin-development@lists.sourceforge.net; Mon, 15 Dec 2014 04:52:50 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.100 as permitted sender) client-ip=62.13.148.100; envelope-from=pete@petertodd.org; helo=outmail148100.authsmtp.co.uk; Received: from outmail148100.authsmtp.co.uk ([62.13.148.100]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Y0NeK-0004jH-Hv for bitcoin-development@lists.sourceforge.net; Mon, 15 Dec 2014 04:52:50 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBF4qfU3017544; Mon, 15 Dec 2014 04:52:41 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 sBF4qaCh057817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 15 Dec 2014 04:52:39 GMT Date: Sun, 14 Dec 2014 23:52:36 -0500 From: Peter Todd To: Gareth Williams Message-ID: <20141215045236.GB23859@savin.petertodd.org> References: <20141212090551.GA8259@muck> <548ADED1.6060300@gmail.com> <548C3FE6.9090508@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UHN/qo2QbUvPLonB" Content-Disposition: inline In-Reply-To: <548C3FE6.9090508@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 329f37dd-8416-11e4-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwcUHFAXAgsB AmIbW1BeVV97XWM7 bA9PbARUfEhLXhtr VklWR1pVCwQmQm53 Al9PIUFycgJOeXk+ Z0ZqXXgVX0ZzI0V6 FhpJHWkHY3phaTUb 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: 1Y0NeK-0004jH-Hv Cc: Bitcoin Dev 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:52:50 -0000 --UHN/qo2QbUvPLonB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 14, 2014 at 12:32:22AM +1100, Gareth Williams wrote: > On 13/12/14 04:04, Alex Mizrahi wrote: > > Well, client-side validation is mathematically secure, while SPV is > > economically secure. > > I.e. it is secure if you make several assumptions about economics of the > > whole thing. >=20 > Comparisons with the SPV security of sidechains are fallacious. The > alternative to a proof-of-publication system reliant on client-side > validation is a blockchain. The question of whether the token used on > said blockchain should be two-way-pegged to BTC is completely orthogonal. >=20 > (ie. yes, sidechains are "economically secure", in that you're reduced > to balancing economic incentives to avoid peg theft. But sidechains also > give us something unique in return - the ability to innovate without > needing to start new artificial scarcity races. Nothing else can do that.) I covered this in my original post: 1-way-pegs allow the creation of new valuable tokens without those tokens being useful for speculation. To recap, a 1-way-peg allows the conversion of Bitcoins to another token by provably destroying the Bitcoins, thus capping the maximum possible value of that token and ensuring the token can-not become an investment. For owners of these tokens they can convert them back to Bitcoin by selling them at a discount to buyers who would otherwise be able to purchase them via provable destruction. A pragmatic implementation may wish to make obtaining the token via destruction option unattractive compared to obtaining them through trade by incorporating a time delay into the destruction process to encourage liquidity. (interestingly a natural outcome of an announce-commit sacrifice-to-fees scheme) Of course even without 1-way-pegs there's a much more important issue with your objection: worrying about creating new artificial scarcity races while innovating is fundementally a *moralistic* and *regulatory* concern that has no little if any bearing on whether or not the systems created are useful and secure. It's also an objection that raises serious questions about conflicts of interest between giving accurate and honest technical advice and promoting ways of using Bitcoin that will drive the price up. > > You know, The Great Fork of 2013 was resolved through human > > intervention, Bitcoin nodes were not smart enough to detect that > > something is going awry on their own. >=20 > I hate to think what the outcome would've been on a proof-of-publication > system. You don't even have a fork. You just have a whole bunch of nodes > who sort-of-mostly agree on a shared history, except where they don't. > Maybe they just disagree on the validity of a single transaction. > They'll slowly diverge over time (as bad transactions are used as input > to other transactions.) You have no reliable way to detect this lapse in > consensus, nor any mechanism to incentivse convergence. Indeed, you have > no consensus mechanism in the first place. A number of mechanisms for detecting divergence are possible in embedded consensus systems, some of them even natural outcomes. For instance transactions can contain a hash of the previous consensus state, thereby creating an indicator of consensus measured in terms of economic stake. Extending that idea many anti-censorship proposals are to use such state hashes as encryption keys - if you are out of consensus you won't even see the transaction. (and you can't be double-spent either if implemented correctly; see my other reply to this thread today) > Bitcoin is where it is today because of Satoshi's elegant solution to > exactly such problems. Which some people now appear to be in a hurry to > discard :) FWIW usually Satoshi's solution is described as a hack, sometimes as an elegant hack. > Peter Todd might disagree with the wisdom of that :) He wrote an > excellent email to this list not long ago warning of the dangers of > centralisation. IIRC one point he made was that scheduled, regular > hardforks were a real threat - if a single entity (eg. the Bitcoin > Foundation) were to become politically established as the coordinator of > such forks, they would have de-facto control over the protocol. Indeed I did, which is why I worked out a better way to do upgrades almost a year ago: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06= 578.html > (Also worth noting: all such systems are effectively "mandatory > updating" due to the risk of subtle consensus bugs of the type I > described above. Your only assurance that your view of the world is the > same as everyone elses' is that you're running the exact same software. > I played with Counterparty a while ago and quickly learned - the hard > way - to do a 'git pull' before any important operation.) 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 'peter'[:-1]@petertodd.org 00000000000000000681f4e5c84bc0bf7e6c5db8673eef225da652fbb785a0de --UHN/qo2QbUvPLonB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJUjmkPXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNjgxZjRlNWM4NGJjMGJmN2U2YzVkYjg2NzNlZWYyMjVk YTY1MmZiYjc4NWEwZGUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfs0XAf/Z1zlK33od+r1n9SWggG/8YJT 3MvtMJbjbKNJlA3ACcSBRATM4yieBdfXBh0rbnD0CBgI/v5d0idENjEQ/Hgxbl9I gVmM72lGYsB3Oq+ChCo0IV3CN3fJXeMG5Zj1GfCwYJCB6f5lNs73J/lma4wf14uX R1GVYQrcUBZ61s1RP3FtY/UBtiV8AlqTQDUIjDyVoSmhmib55j3I3DZaZpuhF144 qJXL4TxGWGvuXlNUDFwqJx7ZAcDHCowBWPUppzovuf3bNAt6iACi86qWIwXciOY+ 2WSr4No1e8+IWXRdWTtDEpE70xwNOaJTks3jO2tb2HmFCG8sydv5WjJeZDIXkw== =L8Hx -----END PGP SIGNATURE----- --UHN/qo2QbUvPLonB--