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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y2edx-0000dR-Hf for bitcoin-development@lists.sourceforge.net; Sun, 21 Dec 2014 11:25:49 +0000 Received: from mail-wg0-f48.google.com ([74.125.82.48]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Y2edq-0004RS-Pj for bitcoin-development@lists.sourceforge.net; Sun, 21 Dec 2014 11:25:49 +0000 Received: by mail-wg0-f48.google.com with SMTP id y19so4707339wgg.35 for ; Sun, 21 Dec 2014 03:25:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EN8z1NenNTJpxl82YgCl+hPU0ZUPyyKDsS2HITa/A9Q=; b=kFgPh3q7uytnYqSTbwljNJS50OQMZQDqTdFdheYhFP7EK01GawsafRwoejgBwuwKeu /ZrvzamKBrbYEUy4bIBRy3fZQ6WpCnsJJJSP9gr7AacJF+72rXdOLJ5uXpN4iL8EX6qL /tR/CGpeILPaECp2DjRiMVIOFpXNlnAmoeHwZb6K5uaUYsatV81y7Zc95Xhj2uNFmZeq sZg5coPkrYC0KHAW6IRoBmRX3EIo1fG4cOOVoTnKIR1DbXHcONijFfzGZKIOy5XbyYaC zx+ZXgbIfWsRlPQNnFswS9jvIsflmNUxpiLt4mCsCLvTUGqfqbIoE/OjERWSwcAqp2Tn 2D/w== X-Gm-Message-State: ALoCoQl+uLv3TUjhLbJg2U2BqABMEskWqPo+w4YQGL4ScYJrTAv77a8eK1VtPs80Xhcvr7eoGLKm MIME-Version: 1.0 X-Received: by 10.180.72.33 with SMTP id a1mr21857156wiv.18.1419161136697; Sun, 21 Dec 2014 03:25:36 -0800 (PST) Received: by 10.194.19.38 with HTTP; Sun, 21 Dec 2014 03:25:36 -0800 (PST) X-Originating-IP: [85.59.61.159] In-Reply-To: <20141221055220.GB8255@savin.petertodd.org> References: <20141212090551.GA8259@muck> <20141220144800.GA26284@savin.petertodd.org> <20141221055220.GB8255@savin.petertodd.org> Date: Sun, 21 Dec 2014 12:25:36 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Peter Todd Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1Y2edq-0004RS-Pj Cc: Bitcoin Development , Mark Friedenbach Subject: Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles 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 11:25:49 -0000 st On Sun, Dec 21, 2014 at 6:52 AM, Peter Todd wrote: > On Sun, Dec 21, 2014 at 11:57:51AM +0800, Mark Friedenbach wrote: >> I think you are trying to say something more specific / limited than that, >> and I suggest you adjust your wording accordingly. Decentralized exchange >> would be possible today with vanilla bitcoin using SIGHASH_SINGLE if only >> the protocol supported multiple validated assets (which it could, but >> doesn't). Rather straightforward further extensions to the protocol would >> enable market participants to use a wider class of orders, as well as >> enable the buyer rather than the seller to dictate order sizes via partial >> redemption, as we demonstrate in our Freimarkets paper. > > Do you realise that all those Freimarket's uses are either based on > proof-of-publication, or insecure due to sybil attacks? So let's go through an example to see in which ways non-proof-of-publication orders are "insecure". Alice the seller wants to sell 1 unit of A for 100 units of B. Bob is willing to pay up to 200 Bs for 1 A. Let's assume a proof of publication system first, in which the execution price is the mean between bid and ask. Alice publishes her order. Bob could publish his order at price 200 Bs and the order would execute at 150 Bs. But after seeing Alice's order he knows he doesn't need to pay that much, so he publishes and order buying for 100 Bs. Alice gets 100 Bs (what she signed she wanted) and Bob pays less than he was wiling to pay, he pays 100 Bs. Everybody happy. Now let's assume native assets and sighash_single. Alice publishes her order (out of band, using various channels). Bob could publish his order at price 200 Bs and then a miner would execute at 100 Bs for Alice, at 200 Bs for Bob and pocket 100 Bs as mining fees. But after seeing Alice's order he knows he doesn't need to pay that much, so he publishes and order buying for 100 Bs. Again, Alice gets 100 Bs (what she signed she wanted) and Bob pays pays 100 Bs. The main difference is that Alice didn't had to pay a fee to publish her binding order. Now let's try to articulate your concerns. Your concern is that Carol, isolates Bob preventing him from seeing Alice's order. Then maybe Bob publishes his own order at 200 Bs. If Carol sees both orders while preventing the other participants from seeing them, she can build a tx in which Alice sells at 100, Bob buys at 200, and Carol pockets the difference. But...any smart miner will replace Carol's address with his own when processing the trade, so Carol cannot win this way. Another thing Carol can do is to buy the A herself for 100 Bs, leaving Bob without them. If Alice cares about Bob getting the deal instead of Carol she can do two things: 1) Establish a direct communication channel with Bob 2) Move to a proof of publication system and start paying fees for publishing binding orders. So again, what's the advantage that proof-of-publication provides TO ALICE so that she will be so eager to pay the higher costs to get the same deal? If this example is not enough to be able to explain the advantage of proof-of-publication markets feel free to write a more complex one.