Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.102 as permitted sender)
	client-ip=62.13.148.102; envelope-from=pete@petertodd.org;
	helo=outmail148102.authsmtp.net; 
Date: Thu, 27 Feb 2014 20:37:19 -0500
From: Peter Todd <pete@petertodd.org>
To: Jorge =?iso-8859-1?Q?Tim=F3n?= <jtimon@monetize.io>
Message-ID: <20140228013719.GA5786@savin>
References: <20140209180458.GB20126@savin> <20140209204434.GA11488@savin>
	<20140210193247.GC17359@savin> <20140211175919.GV3180@nl.grid.coop>
	<20140214052159.GF31437@savin> <20140217054751.GY3180@nl.grid.coop>
	<CAC1+kJNTq2sMbORAU-HBSpTVE3ohzsxHrxXw9JOXZp5ux32Gtw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o"
Content-Disposition: inline
In-Reply-To: <CAC1+kJNTq2sMbORAU-HBSpTVE3ohzsxHrxXw9JOXZp5ux32Gtw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Decentralized digital asset exchange with
 honest pricing and market depth
Precedence: list


--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 28, 2014 at 12:48:33AM +0100, Jorge Tim=F3n wrote:
> First of all, sorry for the delayed answer.
>=20
> On 2/10/14, Peter Todd <pete@petertodd.org> wrote:
> > Got this:
> [...]
> Thank you, I knew this wasn't new for us but I doubted we had written
> it anywhere.
> As said in those mails, being only able to offer AAA for BTC and not
> BTC for AAA nor AAA for BBB is enough of a limitation to justify a
> hardfork IMO.

As usual, you don't need a hardfork.

Anyway, one-sided trade is sufficient to get a functioning marketplace
up and running and test out the many other issues with this stuff prior
to forking anything.

> On 2/14/14, Peter Todd <pete@petertodd.org> wrote:
> > You're assuming the seller cares about fairness - why should they? They
> > offered a price for an asset and someone bought it; exactly which buyer
> > willing to buy at that price was able to complete the trade is
> > irrelevant to them. What they do care about is being sure that at
> > whatever given price they offered 100% of the buyers willing to buy at
> > that price actually see the offer in a reasonable amount of time - at
> > the best price the seller will get there will be only a single buyer
> > after all so you need that solid proof that said buyer was actually able
> > to get the offer.
>=20
> In fact, I don't think the seller will care enough about this to pay
> the proof of publication fee either. Assuming sellers can either
> broadcast the order on a bitmessage-like network or use your proof of
> publication scheme, the later will be always be more expensive. So my
> prediction is that most people will just use the simplest, fastest and
> cheapest method, but I guess only time can tell.

You can make the same argument against Bitcoin itself you know...

A Bitmessage-like network would be trivial to front-run via a sybil
attack. It's the fundemental problem with marketplaces - the data
they're trying to publish has to be public.

> I don't think this will be a tragedy, because like we discussed on
> IRC, I don't think the primary goal of markets is price discovery, but
> trade itself.
>
> About historic data, the actual trades are always public, and some
> kind of "archivers" could collect and maintain old orders for historic
> bid and asks, etc.

And again, how do you know that record is honest? Fact is without
proof-of-publication you just don't.

> As an aside, nLockTime would be nice not to always have to
> double-spend the inputs of an order to cancel it.

You mean a reverse nLockTime that makes a transaction invalid after a
certain amount of time - that's dangerous in a reorg unfortunately as it
can make transactions permenantly invalid.

--=20
'peter'[:-1]@petertodd.org
0000000000000000b52709f0485161e764ac0198960885ccab019a978322cc6e

--IS0zKkzwUGydFO0o
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQGrBAEBCACVBQJTD+hPXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDBiOTdhYjgzMWE1MzBhOWEwNGY1MDAwZWI1YTIzOWYwYjJm
MzBiNmRkMDE2M2VkYTMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfverQf6A4ae7LCT4wq3B7/R7ZXZy145
04KO9b+bO45hkw3FIqM7CS94gND7StvJeYzQHQ42DMl0bmYmQzONdNgL9zeDjgRY
aGbLwiOkK4lRE3jVALbbluGExTv6T3iab3v0F0pqyQxXdm3C8GIfyu0t/j+k5Tul
KHF5dcOb0LE4mvXohCeOzedg5f/h1i0n3qeqtUcgKdEQ9GpeaSjxoZj1w+qL17gE
uRk3KI8MYPaaATWxnzFRIewy2popJA0t9ENbS2MoEsLeZD1cMrTiplP1IKzix8PO
kv7abuZUmYdTRl5vpUvva6DrbAERXpd7JHfbz0K+DNEpAcGGzkrqODB+Hw2tAQ==
=ymTa
-----END PGP SIGNATURE-----

--IS0zKkzwUGydFO0o--