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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y2Zkn-0000Wc-Rd for bitcoin-development@lists.sourceforge.net; Sun, 21 Dec 2014 06:12:33 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.93 as permitted sender) client-ip=62.13.148.93; envelope-from=pete@petertodd.org; helo=outmail148093.authsmtp.net; Received: from outmail148093.authsmtp.net ([62.13.148.93]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Y2Zkl-0005xO-94 for bitcoin-development@lists.sourceforge.net; Sun, 21 Dec 2014 06:12:33 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id sBL6CO6c073389; Sun, 21 Dec 2014 06:12:24 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 sBL6CL9g017874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 21 Dec 2014 06:12:23 GMT Date: Sun, 21 Dec 2014 01:12:20 -0500 From: Peter Todd To: Gareth Williams Message-ID: <20141221061220.GC8255@savin.petertodd.org> References: <20141212090551.GA8259@muck> <548ADED1.6060300@gmail.com> <548C3FE6.9090508@gmail.com> <20141215045236.GB23859@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R+My9LyyhiUvIEro" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 5485b6a6-88d8-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAMUHFAXAgsB AmIbW1JeUV97W2c7 bA9PbARUfEhLXhtr VklWR1pVCwQmQm59 AG1iW05ydgJOf3o+ ZEFlXnkVWUBycBR7 E0hJHWVSbXphaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDJTMg WxEEEn0zHUBNXSg4 KAYqYkUABk8QPUUu eVwnOxogKRgVBEhZ EQR1HSVdJlIIWyss C2sA X-Authentic-SMTP: 61633532353630.1024: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: 1Y2Zkl-0005xO-94 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: Sun, 21 Dec 2014 06:12:33 -0000 --R+My9LyyhiUvIEro Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 17, 2014 at 10:55:28PM +1100, Gareth Williams wrote: > > I covered this in my original post: 1-way-pegs allow the creation of new > > valuable tokens without those tokens being useful for speculation. >=20 > I stand corrected. A permanent 1-way-peg is sufficient to preserve > scarcity; "nothing else can do that" WRT 2-way-pegs was overreaching. Yup. > I still don't see what "2-way-peg vs. 1-way-peg" has to do with > "embedded consensus vs. blockchain consensus" though, and feel it > disingenious to conflate them. 1-way-pegs don't require the Bitcoin protocol to change; 2-way-pegs do. > Blockchain consensus (eg. sidechains) can utilise either mechanism, > 1-way-peg or 2-way-peg. Arguments in favour of 1-way-peg are > interesting, but they're ultimatley just arguments in favour of one > type of sidechain over another. No, they're in favor of systems that are client-side validatable vs. systems that either allow anyone with sufficient hashing power to steal coins *or* require "moon-math" that isn't yet available to production systems. > IMO the question of whether scarcity can be preserved while enabling > innovation bears heavily on the liklihood of longterm viability of > said innovations - and perhaps of Bitcoin itself. >=20 > FWIW I'll happily declare that I hold a modest amount of BTC and have > an interest in the price appreciating. I'm sure you'll admit you're > hardly an impartial party in this discussion yourself Peter :) But it > really shouldn't matter. I'm not here today to make it, but I think > the argument for preservation of scarcity stands quite well on its own > merits - as rightly it should, regardless of anybody's interests. But again, all these discussions about scarcity are fundementally *moral* arguments that have no bearing on what's actually the most appropriate solution for an *individual* problem. In a decentralized system filled with anonymous actors telling people "stop doing that! it's bad!" on reddit has pretty severe limitations in trying to convince people to act against their own best interests. > > 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 > Very interesting. I admit I hadn't come across these ideas before; I > really must search the archive before posting :) They certainly offer > a measure of robustness over the naive approach. I'm not sure they > address my primary concerns however, WRT how consensus is demonstrated > and incentivised. I think you think consensus in Bitcoin is more "magical" than it really is; Bitcoin is just code running on computers; consensus isn't really incentivised at the protocol level beyond "screw it up and you'll lose money" Embedded consensus systems are no different: screw up consensus and you'll lose money in a variety of ways. > The obvious "embedded consensus" answer of "wait until N other > transactions have occurred that include a hash of system state that > includes your transaction" doesn't provide me with any confidence; it > could be simulated with a Sybil attack. No it can't - the transactions are in the blockchain so the sybil attack has to attack the host system as well. In any case, keep in mind all of this is in the context of tradeoffs: for a different and sometimes more fragile consensus mechanism embedded consensus gets immunity to attack by miners. You're trading off one type of fragility for another - I'd much rather take the "one-time" fragility inherent in having to write really solid software than the ongoing fragility of always being vulnerable to miners. Notably this is the exact same tradeoff taken elsewhere by the majority of the crypto world. --=20 'peter'[:-1]@petertodd.org 000000000000000017d70ee98f4cee509d95c4f31d5b998bae6deb09df1088fc --R+My9LyyhiUvIEro Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJUlmTAXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxN2Q3MGVlOThmNGNlZTUwOWQ5NWM0ZjMxZDViOTk4YmFl NmRlYjA5ZGYxMDg4ZmMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvNUAf/ZodoAZad5LS1qi8udjf6Md1u xs3ZOQLSwXIV5I9itW6JWvmc9ZkmxQQvYFqngJFjjVF5fzhUIs2qM6qSa4A06yVh rqER98LlAFyzSzMVRHIQbThSwIGHho+1HeXxN97+6LZSPoY9laBu9M7RDSPurxeH 5gZWwRn964D/E9TnUutTl2U07XygHG3S7E+SOSrSVHHK4iNCng2i5jMLcDnY4kXZ kzJWyN8tc3QXrKzeGjQtUvhL3o3m+n2zIsrL4LlG7NtlpHHx/a/JoeFvMPqfdMvY idm7k/78bCGwdqPmodYPUm4AsxP0pNb0cwiWCR8+e8ipH5nHOzXOzPSBpkUEuw== =cDHW -----END PGP SIGNATURE----- --R+My9LyyhiUvIEro--