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 <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, "You don't under= stand," 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'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, "Peter Todd" = <<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>> 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> > On Dec 20, 2014 8:49 AM, "Peter Todd" <<a href=3D"mailto:= pete@petertodd.org">pete@petertodd.org</a>> wrote:<br> > ><br> > > However the converse is not possible: anti-replay cannot be used = to<br> > implement proof-of-publication. Knowing that no conflicting message ex= ists<br> > says nothing about who be in posession of that message, or indeed, any= <br> > message at all. Thus anti-replay is not sufficient to implement other = uses<br> > of proof-of-publication such as decentralized exchange=C2=B3.<br> ><br> > How does proof of publication prove who is in possession of that messa= ge?<br> > 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> > The data written in an anti-replay system and<br> > the data written in a proof of publication system differs in that you = can't<br> > repeat data in an anti-replay system according to some understanding o= f the<br> > rules of the meaning of the data (if I am following your description<b= r> > correctly).<br> <br> I'm not sure you understand what an anti-replay system is; data isn'= ;t<br> written to them; they'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> > If the data itself defines possession, the "ownership of the mess= age" (it<br> > isn't even clear to me what you mean by that phrase) isn't def= ined by<br> > either proof, but by the message itself.=C2=A0 And the message itself = isn't<br> > constrained by either to prohibit proving ownership (what ever you mea= n by<br> > that).<br> <br> Wait, where did I say "ownership of the message"? What you quoted= above<br> says *posession*, which !=3D ownership.<br> <br> > Of course, I do assume I can test a message (or a set of messages shar= ing<br> > some feature like a particular input on a transaction) as being publis= hable<br> > in an anti-replay system without actually publishing it.=C2=A0 That do= es allow<br> > one to prove non-publishing.=C2=A0 You can determine if a message exis= ts that<br> > would preclude the publishing of a message; the very purpose of an<br> > anti-replay proof.<br> ><br> > And I would assert that such a search (i.e. the idea that such a searc= h has<br> > meaning in a anti-replay system) is already incorporating the assumpti= on<br> > that such a search is possible and must be possible for an anti-replay= <br> > system.<br> <br> You're confused about what an anti-replay system actually is - you'= re<br> really talking about a specific implementation of one based on<br> proof-of-publication, not the concept itself.<br> <br> --<br> 'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet= ertodd.org</a><br> 00000000000000001b728df6414af5ef95388557f1c3e5d29c569d7636b93681<br> </blockquote></div> --001a11c370165231b3050abbc52b--