From: Peter Todd <pete@petertodd•org>
To: paul snow <snow.paul@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles
Date: Sun, 21 Dec 2014 10:22:56 -0500 [thread overview]
Message-ID: <20141221152256.GA3927@savin.petertodd.org> (raw)
In-Reply-To: <CAMU7uivcB8969-R=eBtPNXyWt+ULpXWN5sDBOkRN1XRUtXU9Yg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3135 bytes --]
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³.
>
> How does proof of publication prove who is in possession of that message?
> 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 != ownership.
> 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.
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2014-12-21 15:23 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-12 9:05 [Bitcoin-development] Setting the record straight on Proof-of-Publication Peter Todd
2014-12-12 12:25 ` Gareth Williams
2014-12-12 17:04 ` Alex Mizrahi
[not found] ` <CAOG=w-v3qjG3zd_WhfFU-OGnsHZEuYvY82eL4GqcdgY6np5bvA@mail.gmail.com>
2014-12-12 17:50 ` Alex Mizrahi
2014-12-13 13:32 ` Gareth Williams
2014-12-15 4:52 ` Peter Todd
2014-12-17 11:55 ` Gareth Williams
2014-12-21 6:12 ` Peter Todd
2014-12-15 4:17 ` Peter Todd
2014-12-12 13:41 ` odinn
2014-12-12 14:17 ` Justus Ranvier
2014-12-15 4:59 ` Peter Todd
2014-12-17 1:16 ` odinn
2014-12-20 14:48 ` [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles Peter Todd
[not found] ` <CAOG=w-vrHPY1aCNndmoW9QyCh9XnWyv8uZn2PyjZ6rNg2MoSSw@mail.gmail.com>
2014-12-21 5:52 ` Peter Todd
[not found] ` <CAOG=w-tZke--6OsqNjJhE9SOdCwdZYZM8iz1VBTFziegt9UZWw@mail.gmail.com>
2014-12-21 7:01 ` Peter Todd
[not found] ` <CAOG=w-s1_VXJAKxBpMOK=B50qnHjxSe4J=vwwSfFPRz0_Cb9rA@mail.gmail.com>
2014-12-21 15:32 ` Peter Todd
2014-12-21 11:25 ` Jorge Timón
2014-12-21 16:07 ` Peter Todd
2014-12-21 19:39 ` Jorge Timón
2014-12-21 10:01 ` Adam Back
2014-12-21 15:29 ` Peter Todd
2014-12-21 13:49 ` paul snow
2014-12-21 15:22 ` Peter Todd [this message]
2014-12-21 15:41 ` paul snow
2014-12-22 0:11 ` Peter Todd
2015-01-06 11:03 ` joliver
2014-12-22 20:05 ` Adam Back
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141221152256.GA3927@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=snow.paul@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox