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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y1DCZ-00030C-GY for bitcoin-development@lists.sourceforge.net; Wed, 17 Dec 2014 11:55:35 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.176 as permitted sender) client-ip=209.85.213.176; envelope-from=gacrux@gmail.com; helo=mail-ig0-f176.google.com; Received: from mail-ig0-f176.google.com ([209.85.213.176]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Y1DCY-0007TH-Da for bitcoin-development@lists.sourceforge.net; Wed, 17 Dec 2014 11:55:35 +0000 Received: by mail-ig0-f176.google.com with SMTP id l13so9197885iga.3 for ; Wed, 17 Dec 2014 03:55:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.17.38 with SMTP id z38mr38877305ioi.29.1418817329067; Wed, 17 Dec 2014 03:55:29 -0800 (PST) Received: by 10.64.152.134 with HTTP; Wed, 17 Dec 2014 03:55:28 -0800 (PST) In-Reply-To: <20141215045236.GB23859@savin.petertodd.org> References: <20141212090551.GA8259@muck> <548ADED1.6060300@gmail.com> <548C3FE6.9090508@gmail.com> <20141215045236.GB23859@savin.petertodd.org> Date: Wed, 17 Dec 2014 22:55:28 +1100 Message-ID: From: Gareth Williams To: Bitcoin Dev Content-Type: text/plain; charset=UTF-8 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: 1Y1DCY-0007TH-Da 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: Wed, 17 Dec 2014 11:55:35 -0000 On Mon, Dec 15, 2014 at 3:52 PM, Peter Todd wrote: >> 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. >> >> (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. I stand corrected. A permanent 1-way-peg is sufficient to preserve scarcity; "nothing else can do that" WRT 2-way-pegs was overreaching. 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. 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. Arguments in favour of embedded consensus - and I feel I'm being generous with the term "consensus" here - should surely stand on their own merit against blockchain consensus, if they're to be convincing. > 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. 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. 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. > 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) > 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/msg06578.html > 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. 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 know what my own node considers valid transaction history; how can I be confident that everyone else takes the same view? For contrast, with blockchain consensus, I can be confident that there is consensus on the longest chain observed. If I receive a new transaction, simply waiting for it to be buried under N blocks of PoW provides a high level of confidence that everyone else considers it valid. 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. > I prefer to make robust arguments; if I can start with accepting that > 95% of what my opponents say is true, yet still end up being correct, > all the better! Indeed :) To avoid wasting time it's only ever worth arguing against the strongest opposing position you're aware of (whether your opponent is aware of it or not.) https://en.wikipedia.org/wiki/Principle_of_charity