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 1Y2gsv-0004uQ-KJ for bitcoin-development@lists.sourceforge.net; Sun, 21 Dec 2014 13:49:25 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.43 as permitted sender) client-ip=209.85.215.43; envelope-from=snow.paul@gmail.com; helo=mail-la0-f43.google.com; Received: from mail-la0-f43.google.com ([209.85.215.43]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Y2gsu-0002Rg-I8 for bitcoin-development@lists.sourceforge.net; Sun, 21 Dec 2014 13:49:25 +0000 Received: by mail-la0-f43.google.com with SMTP id s18so2898802lam.30 for ; Sun, 21 Dec 2014 05:49:18 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.95.133 with SMTP id dk5mr17205866lbb.55.1419169758181; Sun, 21 Dec 2014 05:49:18 -0800 (PST) Received: by 10.112.50.107 with HTTP; Sun, 21 Dec 2014 05:49:17 -0800 (PST) Received: by 10.112.50.107 with HTTP; Sun, 21 Dec 2014 05:49:17 -0800 (PST) In-Reply-To: <20141220144800.GA26284@savin.petertodd.org> References: <20141212090551.GA8259@muck> <20141220144800.GA26284@savin.petertodd.org> Date: Sun, 21 Dec 2014 07:49:17 -0600 Message-ID: From: paul snow To: Peter Todd Content-Type: multipart/alternative; boundary=001a11360ef64fff29050aba35e7 X-Spam-Score: -0.6 (/) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (snow.paul[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Y2gsu-0002Rg-I8 Cc: bitcoin-development@lists.sourceforge.net 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 13:49:25 -0000 --001a11360ef64fff29050aba35e7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Dec 20, 2014 8:49 AM, "Peter Todd" 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=C2=B3. How does proof of publication prove who is in possession of that message? Or of any message at all? 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 the rules of the meaning of the data (if I am following your description correctly). Obviously you can publish the same data as many times as you like in a proof-of-publication system; the interpretation of what that data means would be the responsibility of the observers, not the "publishing vehicle". Repeated entries thus can be written, and the user of PoP can validate and prove they did so. 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). 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 publishable 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 has 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. --001a11360ef64fff29050aba35e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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 im= plement proof-of-publication. Knowing that no conflicting message exists sa= ys nothing about who be in posession of that message, or indeed, any messag= e at all. Thus anti-replay is not sufficient to implement other uses of pro= of-of-publication such as decentralized exchange=C2=B3.

How does proof of publication prove who is in possession of = that message?=C2=A0 Or of any message at all?=C2=A0 The data written in an = anti-replay system and the data written in a proof of publication system di= ffers in that you can't repeat data in an anti-replay system according = to some understanding of the rules of the meaning of the data (if I am foll= owing your description correctly).=C2=A0

Obviously you can publish the same data as many times as yo= u like in a proof-of-publication system; the interpretation of what that da= ta means would be the responsibility of the observers, not the "publis= hing vehicle".=C2=A0 Repeated entries thus can be written, and the use= r of PoP can=C2=A0 validate and prove they did so.

If the data itself defines possession, the "ownership o= f the message" (it isn't even clear to me what you mean by that ph= rase) isn't defined by either proof, but by the message itself.=C2=A0 A= nd the message itself isn't constrained by either to prohibit proving o= wnership (what ever you mean by that).

Of course, I do assume I can test a message (or a set of mes= sages sharing some feature like a particular input on a transaction) as bei= ng publishable in an anti-replay system without actually publishing it.=C2= =A0 That does allow one to prove non-publishing.=C2=A0 You can determine if= a message exists that would preclude the publishing of a message; the very= purpose of an anti-replay proof.=C2=A0

And I would assert that such a search (i.e. the idea that su= ch a search has meaning in a anti-replay system) is already incorporating t= he assumption that such a search is possible and must be possible for an an= ti-replay system.

--001a11360ef64fff29050aba35e7--