summaryrefslogtreecommitdiff
path: root/5e/a3d5e23c33ae39b245fedfabcf34b1609ed473
blob: 50376651459aa04eb2f02ad90f6574c36f1cd616 (plain)
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
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1Y2iLd-0004ai-F3
	for bitcoin-development@lists.sourceforge.net;
	Sun, 21 Dec 2014 15:23:09 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.106 as permitted sender)
	client-ip=62.13.148.106; envelope-from=pete@petertodd.org;
	helo=outmail148106.authsmtp.co.uk; 
Received: from outmail148106.authsmtp.co.uk ([62.13.148.106])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1Y2iLb-00085J-KK for bitcoin-development@lists.sourceforge.net;
	Sun, 21 Dec 2014 15:23:09 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBLFN09A064368;
	Sun, 21 Dec 2014 15:23:00 GMT
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
	[75.119.251.161]) (authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBLFMu3C073534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Sun, 21 Dec 2014 15:22:59 GMT
Date: Sun, 21 Dec 2014 10:22:56 -0500
From: Peter Todd <pete@petertodd.org>
To: paul snow <snow.paul@gmail.com>
Message-ID: <20141221152256.GA3927@savin.petertodd.org>
References: <20141212090551.GA8259@muck>
	<20141220144800.GA26284@savin.petertodd.org>
	<CAMU7uivcB8969-R=eBtPNXyWt+ULpXWN5sDBOkRN1XRUtXU9Yg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C"
Content-Disposition: inline
In-Reply-To: <CAMU7uivcB8969-R=eBtPNXyWt+ULpXWN5sDBOkRN1XRUtXU9Yg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 3f511d20-8925-11e4-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdAMUHFAXAgsB AmIbWlFeUl97XGo7 bA9PbARUfEhLXhtr
	VklWR1pVCwQmQm59 cGNbUWpycAZDe3o+ ZEJhWnMVXxJ/dEcp
	QE5JHWQEYHphaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
	NQ4vNDcwO3BTJTpY RgYVKF8UXXNDIj4x DwoPGTwzHEoDXCUy
	N1QsJ0IDEUsXUA0K K1wmVxcfPVoqFwda HkpEHC5eIREIQSZj
	JAVGXAskHSVZSDYU JQchKRtFGVQI
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1Y2iLb-00085J-KK
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:23:09 -0000


--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=B3.
>=20
> 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 t=
he
> 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 sharing
> some feature like a particular input on a transaction) as being publishab=
le
> 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 h=
as
> 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.

--=20
'peter'[:-1]@petertodd.org
00000000000000001b728df6414af5ef95388557f1c3e5d29c569d7636b93681

--a8Wt8u1KmwUX3Y2C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJUluXLXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMmY1NTExODMzYTEzMDRhNzJhNzU0ZGY4YWZlZjI2ZjU3
MTI0MzhiY2M0MDgyNmIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftETAf/XGXBcadr7mSw5Ne5tWDaG67d
PdOtjNXFCtmQZYmdrDuGheC9yqTjCJatqS/uGk+7GPRED2juku+RSoObNMSG9LZ+
id103F+V03dospca9F8KKoEsgzWe3Wt1/S7ZQV8XJNblRZwT3JTg+i8PHtexY320
Eg4+a6SWeb8mwCc94l3KAhICsDlGMdSyx0JkmCqMhNhlSB5GDACfGNTNtKiDxD4q
6CxcUz/WlWZOZpdFu1JNH1ndum/98Zj97ersN+70YyPU8TXVuntDY5pLXSZvGePK
xT/wPNEAhhVnqa/Pj31ytiCaFwjW//noIufHjD3m9hOd22S0GfOGhC/8gfZNxg==
=4LDc
-----END PGP SIGNATURE-----

--a8Wt8u1KmwUX3Y2C--