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
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <snow.paul@gmail.com>) id 1Y1My9-0006Nl-WB
for bitcoin-development@lists.sourceforge.net;
Wed, 17 Dec 2014 22:21:22 +0000
Received-SPF: pass (sog-mx-1.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-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y1My8-0000tf-Hr
for bitcoin-development@lists.sourceforge.net;
Wed, 17 Dec 2014 22:21:21 +0000
Received: by mail-la0-f43.google.com with SMTP id s18so212lam.16
for <bitcoin-development@lists.sourceforge.net>;
Wed, 17 Dec 2014 14:21:14 -0800 (PST)
X-Received: by 10.153.5.1 with SMTP id ci1mr27435784lad.67.1418854874078; Wed,
17 Dec 2014 14:21:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.50.107 with HTTP; Wed, 17 Dec 2014 14:20:33 -0800 (PST)
From: paul snow <snow.paul@gmail.com>
Date: Wed, 17 Dec 2014 16:20:33 -0600
Message-ID: <CAMU7uis0A=BEOgPw=7Z_9F744hrXaVMB_p_D3Z7MYxk40oL+9A@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=001a1133a74ec1e331050a70e4f8
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: 1Y1My8-0000tf-Hr
Subject: [Bitcoin-development] Setting the record straight on
Proof-of-Publication
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: Wed, 17 Dec 2014 22:21:22 -0000
--001a1133a74ec1e331050a70e4f8
Content-Type: text/plain; charset=UTF-8
[[Since I sent this while the List Server was down, it didn't actually go
to everyone. Forgive me if you ended up with two copies.]]
Peter provides an excellent summary of Proof of Publication, which starts
with defining it as being composed of a solution to the double spend
problem. He requires Proof-of-receipt (proof every member of p in audience
P has received a message m), Proof-of-non-publication (proof a message m
has not been published to an audience P), and Proof-of-membership (proof
some q is a member of P).
He goes on to state (curiously) that Factom cannot provide Proof of
Publication.
Proof of Membership
================
Let's first satisfy the easier proofs. A Factom user can know they are a
member of the Factom audience if they have access to the Bitcoin
Blockchain, knowledge of Factom's first anchor (Merkle root stored in the
blockchain) and the Factom network for distributing Factom's structures.
They can pretty much know that they are in the Audience.
Proof of Receipt
============
Proof of receipt is also pretty easy for the Factom user. User submit
entries, and Factom publishes a Merkle Root to the Bitcoin Blockchain. The
Merkle proof to the entry proves receipt. To get the Merkle proof requires
access to Factom structures, which all in the audience have access to by
definition. But the proof itself only requires the blockchain.
At this point the user can have a Merkle proof of their entry rooted in the
blockchain.
Proof of non-publication
==================
Last, can the Factom user have a Proof-of-non-publication? Well,
absolutely. The Factom state limits the public keys that can be used to
write the anchors in the blockchain. Transactions in Bitcoin that are not
signed with those public keys are discounted out of hand. Just like
publishing in Mad Magazine does not qualify if publishing a notice in the
New York Times is the standard.
The complaint Peter has that the user cannot see all the "child chains"
(what we call Factom Chains) is invalid. The user can absolutely see all
the Directory Blocks (which documents all Factom Chains) if they have
access to Factom. But the user doesn't need to prove publication in all
chains. Some of those chains are like Car Magazines, Math Textbooks,
Toaster manuals, etc. Without restricting the domain of publication there
is no proof of the negative. The negative must be proved in the standard of
publication, i.e. the user's chain. And the user can in fact know their
chain, and can enumerate their chain, without regard to most of the other
data in Factom.
Peter seems to be operating under the assumption that the audience for a
Factom user must necessarily be limited to information found in the
blockchain. Yet the user certainly should have access to Factom if they
are a Factom user. Factom then is no different from the New York Times,
and the trust in Factom is less. As Peter says himself, he has to trust the
New York Times doesn't publish multiple versions of the same issue. The
user of the New York Times would have no way to know if there were other
versions of an issue outside of looking at all New York Times issues ever
published.
Factom on the other hand documents their "issues" on the blockchain. Any
fork in publication is obvious as it would require different Bitcoin
addresses to be used, and the blocks would have to have validating
signatures of majorities of all the Factom servers. As long as a fork in
Factom can be clearly identified, and no fork exists, proof of the negative
is assured. And upon a fork, one must assume the users will specify which
fork should be used.
Proof of publication does not require a system that cannot fork, since no
such non-trivial system exists. What is required is that forks can be
detected, and that a path can be chosen to move forward.
--001a1133a74ec1e331050a70e4f8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><span style=3D"font-size:13.3333339691162px">[[Since =
I sent this while the List Server was down, it didn't actually go to ev=
eryone.=C2=A0 Forgive me if you ended up with two copies.]]</span></div><sp=
an style=3D"font-size:13.3333339691162px"><div><span style=3D"font-size:13.=
3333339691162px"><br></span></div>Peter provides an excellent summary of Pr=
oof of Publication, which starts with defining it as being composed of a so=
lution to the double spend problem.=C2=A0 He requires Proof-of-receipt (pro=
of every member of p in audience P has received a message m), Proof-of-non-=
publication (proof a message m has not been published to an audience P), an=
d Proof-of-membership (proof some q is a member of P).</span><div style=3D"=
font-size:13.3333339691162px"><br></div><div style=3D"font-size:13.33333396=
91162px">He goes on to state (curiously) that Factom cannot provide Proof o=
f Publication.</div><div style=3D"font-size:13.3333339691162px"><br></div>P=
roof of Membership<div style=3D"font-size:13.3333339691162px">=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div style=3D"font-size:13.333333=
9691162px"><br></div><div style=3D"font-size:13.3333339691162px">Let's =
first satisfy the easier proofs. A Factom user can know they are a member o=
f the Factom audience if they have access to the Bitcoin Blockchain, knowle=
dge of Factom's first anchor (Merkle root stored in the blockchain) and=
the Factom network for distributing Factom's structures.=C2=A0 They ca=
n pretty much know that they are in the Audience.</div><div style=3D"font-s=
ize:13.3333339691162px"><br></div><div style=3D"font-size:13.3333339691162p=
x">Proof of Receipt</div><div style=3D"font-size:13.3333339691162px">=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div style=3D"font-size:13.333333969116=
2px"><br></div><div style=3D"font-size:13.3333339691162px">Proof of receipt=
is also pretty easy for the Factom user.=C2=A0 User submit entries, and Fa=
ctom publishes a Merkle Root to the Bitcoin Blockchain.=C2=A0 The Merkle pr=
oof to the entry proves receipt.=C2=A0 To get the Merkle proof requires acc=
ess to Factom structures, which all in the audience have access to by defin=
ition.=C2=A0 But the proof itself only requires the blockchain.</div><div s=
tyle=3D"font-size:13.3333339691162px"><br></div><div style=3D"font-size:13.=
3333339691162px">At this point the user can have a Merkle proof of their en=
try rooted in the blockchain.</div><div style=3D"font-size:13.3333339691162=
px"><br></div><div style=3D"font-size:13.3333339691162px">Proof of non-publ=
ication</div><div style=3D"font-size:13.3333339691162px">=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div style=3D"font-size:13.333333=
9691162px"><br></div><div style=3D"font-size:13.3333339691162px">Last, can =
the Factom user have a =C2=A0Proof-of-non-publication?=C2=A0 Well, absolute=
ly.=C2=A0 The Factom state limits the public keys that can be used to write=
the anchors in the blockchain.=C2=A0 Transactions in Bitcoin that are not =
signed with those public keys are discounted out of hand.=C2=A0 Just like p=
ublishing in Mad Magazine does not qualify if publishing a notice in the Ne=
w York Times is the standard.</div><div style=3D"font-size:13.3333339691162=
px"><br></div><div style=3D"font-size:13.3333339691162px">The complaint Pet=
er has that the user cannot see all the "child chains" (what we c=
all Factom Chains) is invalid.=C2=A0 The user can absolutely see all the Di=
rectory Blocks (which documents all Factom Chains) if they have access to F=
actom. But the user doesn't need to prove publication in all chains.=C2=
=A0 Some of those chains are like Car Magazines, Math Textbooks, Toaster ma=
nuals, etc. Without restricting the domain of publication there is no proof=
of the negative. The negative must be proved in the standard of publicatio=
n, i.e. the user's chain.=C2=A0 And the user can in fact know their cha=
in, and can enumerate their chain, without regard to most of the other data=
in Factom.</div><div style=3D"font-size:13.3333339691162px"><br></div><div=
style=3D"font-size:13.3333339691162px">Peter seems to be operating under t=
he assumption that the audience for a Factom user must necessarily be limit=
ed to information found in the blockchain.=C2=A0 Yet the user certainly sho=
uld have access to Factom if they are a Factom user.=C2=A0 Factom then is n=
o different from the New York Times, and the trust in Factom is less. As Pe=
ter says himself, he has to trust the New York Times doesn't publish mu=
ltiple versions of the same issue. The user of the New York Times would hav=
e no way to know if there were other versions of an issue outside of lookin=
g at all New York Times issues ever published. =C2=A0</div><div style=3D"fo=
nt-size:13.3333339691162px"><br></div><div style=3D"font-size:13.3333339691=
162px">Factom on the other hand documents their "issues" on the b=
lockchain.=C2=A0 Any fork in publication is obvious as it would require dif=
ferent Bitcoin addresses to be used, and the blocks would have to have vali=
dating signatures of majorities of all the Factom servers. As long as a for=
k in Factom can be clearly identified, and no fork exists, proof of the neg=
ative is assured.=C2=A0 And upon a fork, one must assume the users will spe=
cify which fork should be used. =C2=A0</div><div style=3D"font-size:13.3333=
339691162px"><br></div><div style=3D"font-size:13.3333339691162px">Proof of=
publication does not require a system that cannot fork, since no such non-=
trivial system exists.=C2=A0 What is required is that forks can be detected=
, and that a path can be chosen to move forward.</div>
</div>
--001a1133a74ec1e331050a70e4f8--
|
