Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.106 as permitted sender)
	client-ip=62.13.148.106; envelope-from=pete@petertodd.org;
	helo=outmail148106.authsmtp.co.uk; 
Date: Sun, 21 Dec 2014 10:22:56 -0500
From: Peter Todd <pete@petertodd.org>
To: paul snow <snow.paul@gmail.com>
Message-ID: <20141221152256.GA3927@savin.petertodd.org>
References: <20141212090551.GA8259@muck>
	<20141220144800.GA26284@savin.petertodd.org>
	<CAMU7uivcB8969-R=eBtPNXyWt+ULpXWN5sDBOkRN1XRUtXU9Yg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C"
Content-Disposition: inline
In-Reply-To: <CAMU7uivcB8969-R=eBtPNXyWt+ULpXWN5sDBOkRN1XRUtXU9Yg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] The relationship between
 Proof-of-Publication and Anti-Replay Oracles
Precedence: list


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

On Sun, Dec 21, 2014 at 07:49:17AM -0600, paul snow wrote:
> On Dec 20, 2014 8:49 AM, "Peter Todd" <pete@petertodd.org> wrote:
> >
> > However the converse is not possible: anti-replay cannot be used to
> implement proof-of-publication. Knowing that no conflicting message exists
> says nothing about who be in posession of that message, or indeed, any
> message at all. Thus anti-replay is not sufficient to implement other uses
> of proof-of-publication such as decentralized exchange=B3.
>=20
> How does proof of publication prove who is in possession of that message?
> Or of any message at all?

With the blockchain you prove the message in in the blockchain; anyone
in posession of the blockchain will be in posession of the message.
Secondly determining if you are in posession of the blockchain is
possible subject to the usual considerations about attacker size,
whether or not your local clock is up-to-date, etc.

> The data written in an anti-replay system and
> the data written in a proof of publication system differs in that you can=
't
> repeat data in an anti-replay system according to some understanding of t=
he
> rules of the meaning of the data (if I am following your description
> correctly).

I'm not sure you understand what an anti-replay system is; data isn't
written to them; they're an abstract mathematical model that may be
actually implemented in a variety of ways.

Now it is true that any conceivable implementation must involve some
type of storage, but that storage can easily 100% local to the
anti-replay oracle and need not store the data itself. For instance a
trusted computer in a vault that maintains an extremely large bloom
filter of previously used keys would be a perfectly reasonable
implementation.

> If the data itself defines possession, the "ownership of the message" (it
> isn't even clear to me what you mean by that phrase) isn't defined by
> either proof, but by the message itself.  And the message itself isn't
> constrained by either to prohibit proving ownership (what ever you mean by
> that).

Wait, where did I say "ownership of the message"? What you quoted above
says *posession*, which !=3D ownership.

> Of course, I do assume I can test a message (or a set of messages sharing
> some feature like a particular input on a transaction) as being publishab=
le
> in an anti-replay system without actually publishing it.  That does allow
> one to prove non-publishing.  You can determine if a message exists that
> would preclude the publishing of a message; the very purpose of an
> anti-replay proof.
>
> And I would assert that such a search (i.e. the idea that such a search h=
as
> meaning in a anti-replay system) is already incorporating the assumption
> that such a search is possible and must be possible for an anti-replay
> system.

You're confused about what an anti-replay system actually is - you're
really talking about a specific implementation of one based on
proof-of-publication, not the concept itself.

--=20
'peter'[:-1]@petertodd.org
00000000000000001b728df6414af5ef95388557f1c3e5d29c569d7636b93681

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

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJUluXLXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMmY1NTExODMzYTEzMDRhNzJhNzU0ZGY4YWZlZjI2ZjU3
MTI0MzhiY2M0MDgyNmIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftETAf/XGXBcadr7mSw5Ne5tWDaG67d
PdOtjNXFCtmQZYmdrDuGheC9yqTjCJatqS/uGk+7GPRED2juku+RSoObNMSG9LZ+
id103F+V03dospca9F8KKoEsgzWe3Wt1/S7ZQV8XJNblRZwT3JTg+i8PHtexY320
Eg4+a6SWeb8mwCc94l3KAhICsDlGMdSyx0JkmCqMhNhlSB5GDACfGNTNtKiDxD4q
6CxcUz/WlWZOZpdFu1JNH1ndum/98Zj97ersN+70YyPU8TXVuntDY5pLXSZvGePK
xT/wPNEAhhVnqa/Pj31ytiCaFwjW//noIufHjD3m9hOd22S0GfOGhC/8gfZNxg==
=4LDc
-----END PGP SIGNATURE-----

--a8Wt8u1KmwUX3Y2C--