[Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles

paul snow snow.paul at gmail.com
Sun Dec 21 13:49:17 UTC 2014

On Dec 20, 2014 8:49 AM, "Peter Todd" <pete at 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³.

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

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141221/793952f0/attachment.html>

More information about the bitcoin-dev mailing list