1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <snow.paul@gmail.com>) id 1Y2gsv-0004uQ-KJ
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Dec 2014 13:49:25 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.43 as permitted sender)
client-ip=209.85.215.43; envelope-from=snow.paul@gmail.com;
helo=mail-la0-f43.google.com;
Received: from mail-la0-f43.google.com ([209.85.215.43])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y2gsu-0002Rg-I8
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Dec 2014 13:49:25 +0000
Received: by mail-la0-f43.google.com with SMTP id s18so2898802lam.30
for <bitcoin-development@lists.sourceforge.net>;
Sun, 21 Dec 2014 05:49:18 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.95.133 with SMTP id dk5mr17205866lbb.55.1419169758181;
Sun, 21 Dec 2014 05:49:18 -0800 (PST)
Received: by 10.112.50.107 with HTTP; Sun, 21 Dec 2014 05:49:17 -0800 (PST)
Received: by 10.112.50.107 with HTTP; Sun, 21 Dec 2014 05:49:17 -0800 (PST)
In-Reply-To: <20141220144800.GA26284@savin.petertodd.org>
References: <20141212090551.GA8259@muck>
<20141220144800.GA26284@savin.petertodd.org>
Date: Sun, 21 Dec 2014 07:49:17 -0600
Message-ID: <CAMU7uivcB8969-R=eBtPNXyWt+ULpXWN5sDBOkRN1XRUtXU9Yg@mail.gmail.com>
From: paul snow <snow.paul@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11360ef64fff29050aba35e7
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: 1Y2gsu-0002Rg-I8
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 13:49:25 -0000
--001a11360ef64fff29050aba35e7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 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
correctly).
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
that).
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.
--001a11360ef64fff29050aba35e7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><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 im=
plement proof-of-publication. Knowing that no conflicting message exists sa=
ys nothing about who be in posession of that message, or indeed, any messag=
e at all. Thus anti-replay is not sufficient to implement other uses of pro=
of-of-publication such as decentralized exchange=C2=B3.</p>
<p dir=3D"ltr">How does proof of publication prove who is in possession of =
that message?=C2=A0 Or of any message at all?=C2=A0 The data written in an =
anti-replay system and the data written in a proof of publication system di=
ffers 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 foll=
owing your description correctly).=C2=A0</p>
<p dir=3D"ltr"> Obviously you can publish the same data as many times as yo=
u like in a proof-of-publication system; the interpretation of what that da=
ta means would be the responsibility of the observers, not the "publis=
hing vehicle".=C2=A0 Repeated entries thus can be written, and the use=
r of PoP can=C2=A0 validate and prove they did so.</p>
<p dir=3D"ltr">If the data itself defines possession, the "ownership o=
f the message" (it isn't even clear to me what you mean by that ph=
rase) isn't defined by either proof, but by the message itself.=C2=A0 A=
nd the message itself isn't constrained by either to prohibit proving o=
wnership (what ever you mean by that).</p>
<p dir=3D"ltr">Of course, I do assume I can test a message (or a set of mes=
sages sharing some feature like a particular input on a transaction) as bei=
ng publishable in an anti-replay system without actually publishing it.=C2=
=A0 That does allow one to prove non-publishing.=C2=A0 You can determine if=
a message exists that would preclude the publishing of a message; the very=
purpose of an anti-replay proof.=C2=A0 </p>
<p dir=3D"ltr">And I would assert that such a search (i.e. the idea that su=
ch a search has meaning in a anti-replay system) is already incorporating t=
he assumption that such a search is possible and must be possible for an an=
ti-replay system.</p>
--001a11360ef64fff29050aba35e7--
|
