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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y2j2W-00068N-Hq for bitcoin-development@lists.sourceforge.net; Sun, 21 Dec 2014 16:07:28 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.75 as permitted sender) client-ip=62.13.149.75; envelope-from=pete@petertodd.org; helo=outmail149075.authsmtp.net; Received: from outmail149075.authsmtp.net ([62.13.149.75]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Y2j2V-0000Oo-Cm for bitcoin-development@lists.sourceforge.net; Sun, 21 Dec 2014 16:07:28 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id sBLG7I9n030648; Sun, 21 Dec 2014 16:07:18 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 sBLG7Euh010769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 21 Dec 2014 16:07:16 GMT Date: Sun, 21 Dec 2014 11:07:13 -0500 From: Peter Todd To: Jorge =?iso-8859-1?Q?Tim=F3n?= Message-ID: <20141221160713.GD3927@savin.petertodd.org> References: <20141212090551.GA8259@muck> <20141220144800.GA26284@savin.petertodd.org> <20141221055220.GB8255@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Hf61M2y+wYpnELGG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 6f63a61f-892b-11e4-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAMUHFAXAgsB AmIbWlJeUFp7WGQ7 bA9PbARUfEhLXhtr VklWR1pVCwQmQm59 cRlrF0FydgVBfnc+ ZE9jWXIVWhJ8dhd7 QxhJHWQEN3phaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDIj4x DwoPGTwzHEoDXCUy N1QsJ0IDEUsXUA0K K1wmVxcfPVoqFwda HkpEHC5eIREIQSZj JAVGXAskHSVZSDYU JQchKRtFGVQI 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: 1Y2j2V-0000Oo-Cm 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 16:07:28 -0000 --Hf61M2y+wYpnELGG Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 21, 2014 at 12:25:36PM +0100, Jorge Tim=F3n wrote: > So let's go through an example to see in which ways > non-proof-of-publication orders are "insecure". >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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... 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. Accurate unbiased price information is worth money. 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. > 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. --=20 'peter'[:-1]@petertodd.org 000000000000000002661192e72bdc83e6c8101371520159531301aa1437cc2c --Hf61M2y+wYpnELGG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJUlvAsXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxYjcwMzYxNzE0NzkwMTA5MDQ0YzBhMTMxYzljYzU5MGIx ZjViNWVmZWZkZTg1NDgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuoPQf/XYwYrhP+/qY3aA3tH9xevil+ C/DxE8/Qs2oZx8Db5DAVFQcPF5IlzENQfCijSpsXEVNTmcrfaP33fRHYuJbVSDmo +O9QZhKIa6yNUWVlWkr3NOc/dxpJTPbH9x62ML6tmBhSSrWajrRjyapTSwtJaESB ib75u+gGrvKBG6z4X5ede22OEsorrghwYjRueB4Xtnwrq6fWOvY8v3lQgstDs1AG E2xlDVqfkBtk8v8M+TABhSpDtJncAlOGjKPCTMSzQZvrChbb5nROsUcBxSneiLZx 1VKQwnFrqrhG3Ys8na+D64lG2bv1USwXqqrekUaSoGtAxlgBBMd81jJ0jqTtPA== =jiyz -----END PGP SIGNATURE----- --Hf61M2y+wYpnELGG--