path: root/0a/527766732e67b2182aa59d0527f5dde0b61643

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 <snow.paul@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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>
	<CAMU7uivcB8969-R=eBtPNXyWt+ULpXWN5sDBOkRN1XRUtXU9Yg@mail.gmail.com>
	<20141221152256.GA3927@savin.petertodd.org>
Date: Sun, 21 Dec 2014 09:41:08 -0600
Message-ID: <CAMU7uitBBm58iNH6QXP4K+PQzn9Uw=JaYvv5vGgvSM-dCFZZig@mail.gmail.com>
From: paul snow <snow.paul@gmail.com>
To: Peter Todd <pete@petertodd.org>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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" <pete@petertodd.org> wrote:

> 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=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

<p dir=3D"ltr">I could play the game where I say, &quot;You don&#39;t under=
stand,&quot; and, like you, not address any of your points.</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">The argument that proof of audience isn&#39;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.</p>
<div class=3D"gmail_quote">On Dec 21, 2014 9:23 AM, &quot;Peter Todd&quot; =
&lt;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wrote:=
<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Dec 21, 201=
4 at 07:49:17AM -0600, paul snow wrote:<br>
&gt; On Dec 20, 2014 8:49 AM, &quot;Peter Todd&quot; &lt;<a href=3D"mailto:=
pete@petertodd.org">pete@petertodd.org</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; However the converse is not possible: anti-replay cannot be used =
to<br>
&gt; implement proof-of-publication. Knowing that no conflicting message ex=
ists<br>
&gt; says nothing about who be in posession of that message, or indeed, any=
<br>
&gt; message at all. Thus anti-replay is not sufficient to implement other =
uses<br>
&gt; of proof-of-publication such as decentralized exchange=C2=B3.<br>
&gt;<br>
&gt; How does proof of publication prove who is in possession of that messa=
ge?<br>
&gt; Or of any message at all?<br>
<br>
With the blockchain you prove the message in in the blockchain; anyone<br>
in posession of the blockchain will be in posession of the message.<br>
Secondly determining if you are in posession of the blockchain is<br>
possible subject to the usual considerations about attacker size,<br>
whether or not your local clock is up-to-date, etc.<br>
<br>
&gt; The data written in an anti-replay system and<br>
&gt; the data written in a proof of publication system differs in that you =
can&#39;t<br>
&gt; repeat data in an anti-replay system according to some understanding o=
f the<br>
&gt; rules of the meaning of the data (if I am following your description<b=
r>
&gt; correctly).<br>
<br>
I&#39;m not sure you understand what an anti-replay system is; data isn&#39=
;t<br>
written to them; they&#39;re an abstract mathematical model that may be<br>
actually implemented in a variety of ways.<br>
<br>
Now it is true that any conceivable implementation must involve some<br>
type of storage, but that storage can easily 100% local to the<br>
anti-replay oracle and need not store the data itself. For instance a<br>
trusted computer in a vault that maintains an extremely large bloom<br>
filter of previously used keys would be a perfectly reasonable<br>
implementation.<br>
<br>
&gt; If the data itself defines possession, the &quot;ownership of the mess=
age&quot; (it<br>
&gt; isn&#39;t even clear to me what you mean by that phrase) isn&#39;t def=
ined by<br>
&gt; either proof, but by the message itself.=C2=A0 And the message itself =
isn&#39;t<br>
&gt; constrained by either to prohibit proving ownership (what ever you mea=
n by<br>
&gt; that).<br>
<br>
Wait, where did I say &quot;ownership of the message&quot;? What you quoted=
 above<br>
says *posession*, which !=3D ownership.<br>
<br>
&gt; Of course, I do assume I can test a message (or a set of messages shar=
ing<br>
&gt; some feature like a particular input on a transaction) as being publis=
hable<br>
&gt; in an anti-replay system without actually publishing it.=C2=A0 That do=
es allow<br>
&gt; one to prove non-publishing.=C2=A0 You can determine if a message exis=
ts that<br>
&gt; would preclude the publishing of a message; the very purpose of an<br>
&gt; anti-replay proof.<br>
&gt;<br>
&gt; And I would assert that such a search (i.e. the idea that such a searc=
h has<br>
&gt; meaning in a anti-replay system) is already incorporating the assumpti=
on<br>
&gt; that such a search is possible and must be possible for an anti-replay=
<br>
&gt; system.<br>
<br>
You&#39;re confused about what an anti-replay system actually is - you&#39;=
re<br>
really talking about a specific implementation of one based on<br>
proof-of-publication, not the concept itself.<br>
<br>
--<br>
&#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
00000000000000001b728df6414af5ef95388557f1c3e5d29c569d7636b93681<br>
</blockquote></div>

--001a11c370165231b3050abbc52b--