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 1Y2mM7-0005BO-8C for bitcoin-development@lists.sourceforge.net; Sun, 21 Dec 2014 19:39:55 +0000 Received: from mail-wi0-f174.google.com ([209.85.212.174]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Y2mM4-0001sr-HA for bitcoin-development@lists.sourceforge.net; Sun, 21 Dec 2014 19:39:55 +0000 Received: by mail-wi0-f174.google.com with SMTP id h11so6336878wiw.7 for ; Sun, 21 Dec 2014 11:39:46 -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 :content-transfer-encoding; bh=yfnicUkxLGvGNGD7q85EdZShPf1Cey7p0+BphJVfBDc=; b=GKylqH5xp7ZVJVqzVGx9KW/Hfs14zadOPFdAG8yTmXyJyTyWQ54qYMoBHtLeaW3r+p VLqkH2hr+FBTHidLyu3lFNHYFpU7gDXn0scWanlhG+jGeXlAP+gyUnr/beHEmhesoTcc V16EBpVn3La1AEYUVGemeY1d/H8VUpZOLyhbzUMMMtTrt3qObeDlSriyBN2g6Zuya1wh Bi18fvTlTdiQJB1tpgJt6nup/Ou4lUECNObt8MfP4HUUgic0bk92Npi2q9q8rs4zxPNk C2BYtdM+fGZ+PCgAZmviNu4vLodC3pTxmJbAPNby8e/ho2StXig3sRrSs3sScmIdZhLo yiSw== X-Gm-Message-State: ALoCoQnV04AzmqZ7IEtipbXzKP8Wob1Xiacy1pyF9osNCL3uHbDI1z3Y1ALSi/hoBxihYRFHN8Vs MIME-Version: 1.0 X-Received: by 10.180.98.138 with SMTP id ei10mr25151533wib.32.1419190786467; Sun, 21 Dec 2014 11:39:46 -0800 (PST) Received: by 10.194.19.38 with HTTP; Sun, 21 Dec 2014 11:39:46 -0800 (PST) X-Originating-IP: [85.59.61.159] In-Reply-To: <20141221160713.GD3927@savin.petertodd.org> References: <20141212090551.GA8259@muck> <20141220144800.GA26284@savin.petertodd.org> <20141221055220.GB8255@savin.petertodd.org> <20141221160713.GD3927@savin.petertodd.org> Date: Sun, 21 Dec 2014 20:39:46 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Peter Todd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: 1Y2mM4-0001sr-HA 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 19:39:55 -0000 On Sun, Dec 21, 2014 at 5:07 PM, Peter Todd wrote: > On Sun, Dec 21, 2014 at 12:25:36PM +0100, Jorge Tim=C3=B3n wrote: >> 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. > > Incidentally, SIGHASH_SINGLE is just as usable in embedded consensus; > it's not specific to native assets. > >> 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? > > Like I said the last time this issue was discused on the mailing list, > it's silly to think the seller of an asset starts off with a specific > price they want to sell it at and is happy no matter what happens or how > it gets fufilled. In the real world sellers and buyers want to know > they're connected to actual sellers and buyers - not sybil attackers > trying to shave off a margin for themselves - and are willing to pay a > premium for that. Note all the hatred and vitrol directed towards > high-frequency traders... And like last time we discussed this on the mailing list my opinion differs from yours. You talk about "real world sellers and buyers" but ignore Alice the seller and Bob the buyer in my example. You failed to explain how sybil attackers (Carol) get all those margins. In my example I claim miners get them, what am I missing? How is the same example with a proof-of-publication market any better? Miners can reorder the orders with proof of publication too. If getting orders into mined blocks faster has an advantage miners can charge privileged traders for privileged connections (just like it happens today with "perfectly fair" centralized markets today that feature the high-frequency trading you mention). They could even charge for moving transactions around within the same block if that has any effect on the execution rules. I prefer that miners can get the difference between bids and asks directly to compensate for their hashing power. > How *much* of a premium is an interesting question, and depends a lot on > the specific scenario. For instance I fully expect to see a whole > variety of mediums become used for the proof-of-publication needed, > ranging from directly on a major blockchain to minor/less secure > blockchains like Bitmessage over treechains to centralized-but-audited > proof-of-publication schemes - AKA centralized exchanges - to standard > exchanges. Point is, the concept of proof-of-publication makes these > tradeoffs and options available and lets end-users pick the right one > for their needs. The point is that there's more models for p2p markets beyond those that require proof of publication for their orders, and you're claiming that only those using proof of publication are secure. That's incorrect. > Accurate unbiased price information is worth money. Can you define "Accurate unbiased price information"? > In systems that > allow third-parties to republish asset bids and offers we'll even see > third-parties republishing bids and offers from less secure systems to > more secure systems to get better price discovery. Traders want to trade. The primary function of markets is exchange, not price discovery. >> 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. > > I gotta ask, have you actually run the design and tradeoffs of > Friemarket's past actual finance types? I have, and it's remarkable how > excited many of them are about cryptographically provable fair price > discovery. "Provably fair price discovery" is probably impossible. But I can imagine how many people could get excited about such a technology. Can you formally define what you mean by this? You see, "fair" implies morality and therefore it's a very subjective term, so it's not obvious to me what you may mean by that. > -- > 'peter'[:-1]@petertodd.org > 000000000000000002661192e72bdc83e6c8101371520159531301aa1437cc2c