From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y2idB-0008WN-4W for bitcoin-development@lists.sourceforge.net; Sun, 21 Dec 2014 15:41:17 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.51 as permitted sender) client-ip=209.85.215.51; envelope-from=snow.paul@gmail.com; helo=mail-la0-f51.google.com; Received: from mail-la0-f51.google.com ([209.85.215.51]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Y2id9-0000bH-Jn for bitcoin-development@lists.sourceforge.net; Sun, 21 Dec 2014 15:41:17 +0000 Received: by mail-la0-f51.google.com with SMTP id ms9so2953205lab.10 for ; Sun, 21 Dec 2014 07:41:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.189.10 with SMTP id ge10mr17443475lbc.23.1419176469211; Sun, 21 Dec 2014 07:41:09 -0800 (PST) Received: by 10.112.50.107 with HTTP; Sun, 21 Dec 2014 07:41:08 -0800 (PST) Received: by 10.112.50.107 with HTTP; Sun, 21 Dec 2014 07:41:08 -0800 (PST) In-Reply-To: <20141221152256.GA3927@savin.petertodd.org> References: <20141212090551.GA8259@muck> <20141220144800.GA26284@savin.petertodd.org> <20141221152256.GA3927@savin.petertodd.org> Date: Sun, 21 Dec 2014 09:41:08 -0600 Message-ID: From: paul snow To: Peter Todd Content-Type: multipart/alternative; boundary=001a11c370165231b3050abbc52b 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: 1Y2id9-0000bH-Jn 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 15:41:17 -0000 --001a11c370165231b3050abbc52b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I could play the game where I say, "You don't understand," and, like you, not address any of your points. First, there is no dependence on implementation in my arguments. If a system can prevent replay by some set of rules, it necessarily must be able to answer the question if a message is publishable. Non publishing proofs are thus possible and even required. The argument that proof of audience isn't part of an anti-replay system is not one I picked up on, but an publicly auditable anti replay system necessarily must define its audience. Again, not an issue for an auditable system. On Dec 21, 2014 9:23 AM, "Peter Todd" wrote: > On Sun, Dec 21, 2014 at 07:49:17AM -0600, paul snow wrote: > > 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 messag= e? > > 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 > the > > 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 shari= ng > > some feature like a particular input on a transaction) as being > publishable > > in an anti-replay system without actually publishing it. That does all= ow > > one to prove non-publishing. You can determine if a message exists tha= t > > 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 assumptio= n > > 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. > > -- > 'peter'[:-1]@petertodd.org > 00000000000000001b728df6414af5ef95388557f1c3e5d29c569d7636b93681 > --001a11c370165231b3050abbc52b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I could play the game where I say, "You don't under= stand," and, like you, not address any of your points.

First, there is no dependence on implementation in my argume= nts.=C2=A0 If a system can prevent replay by some set of rules, it necessar= ily must be able to answer the question if a message is publishable.=C2=A0 = Non publishing proofs are thus possible and even required.

The argument that proof of audience isn't part of an ant= i-replay system is not one I picked up on, but an publicly auditable anti r= eplay system necessarily must define its audience. Again, not an issue for = an auditable system.

On Dec 21, 2014 9:23 AM, "Peter Todd" = <pete@petertodd.org> wrote:=
On Sun, Dec 21, 201= 4 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 ex= ists
> 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 messa= ge?
> 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 o= f the
> 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 mess= age" (it
> isn't even clear to me what you mean by that phrase) isn't def= ined by
> either proof, but by the message itself.=C2=A0 And the message itself = isn't
> constrained by either to prohibit proving ownership (what ever you mea= n 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 shar= ing
> some feature like a particular input on a transaction) as being publis= hable
> in an anti-replay system without actually publishing it.=C2=A0 That do= es allow
> one to prove non-publishing.=C2=A0 You can determine if a message exis= ts 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 searc= h has
> meaning in a anti-replay system) is already incorporating the assumpti= on
> 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.

--
'peter'[:-1]@pet= ertodd.org
00000000000000001b728df6414af5ef95388557f1c3e5d29c569d7636b93681
--001a11c370165231b3050abbc52b--