From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y0yk9-00012r-FI for bitcoin-development@lists.sourceforge.net; Tue, 16 Dec 2014 20:29:17 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.182 as permitted sender) client-ip=209.85.217.182; envelope-from=snow.paul@gmail.com; helo=mail-lb0-f182.google.com; Received: from mail-lb0-f182.google.com ([209.85.217.182]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Y0yk8-0003wN-0i for bitcoin-development@lists.sourceforge.net; Tue, 16 Dec 2014 20:29:17 +0000 Received: by mail-lb0-f182.google.com with SMTP id f15so12380160lbj.41 for ; Tue, 16 Dec 2014 12:29:09 -0800 (PST) X-Received: by 10.152.5.100 with SMTP id r4mr37510741lar.26.1418761749598; Tue, 16 Dec 2014 12:29:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.50.107 with HTTP; Tue, 16 Dec 2014 12:28:29 -0800 (PST) From: paul snow Date: Tue, 16 Dec 2014 14:28:29 -0600 Message-ID: To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=089e0141a3581b1888050a5b36d7 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: 1Y0yk8-0003wN-0i 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 20:29:17 -0000 --089e0141a3581b1888050a5b36d7 Content-Type: text/plain; charset=UTF-8 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 Audience ============= Let's first satisfy the easier proofs. A Factom user can know they are in 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. Entries that are not written 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. --089e0141a3581b1888050a5b36d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Peter provides an excellent summary of Proof of Publicatio= n, which starts with defining it as being composed of a solution to the dou= ble spend problem.=C2=A0 He requires Proof-of-receipt (proof every member o= f p in audience P has received a message m), Proof-of-non-publication (proo= f a message m has not been published to an audience P), and Proof-of-member= ship (proof some q is a member of P).

He goes on to stat= e (curiously) that Factom cannot provide Proof of Publication.
Proof of Audience
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Let's first satisfy the easier proofs. = A Factom user can know they are in the Factom audience if they have access = to the Bitcoin Blockchain, knowledge of Factom's first anchor (Merkle r= oot stored in the blockchain) and the Factom network for distributing Facto= m's structures.=C2=A0 They can pretty much know that they are in the Au= dience.

Proof of Receipt
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

Proof of receipt is also pre= tty easy for the Factom user.=C2=A0 User submit entries, and Factom publish= es a Merkle Root to the Bitcoin Blockchain.=C2=A0 The Merkle proof to the e= ntry proves receipt.=C2=A0 To get the Merkle proof requires access to Facto= m structures, which all in the audience have access to by definition.=C2=A0= But the proof itself only requires the blockchain.

At this point the user can have a Merkle proof of their entry rooted in t= he blockchain.

Proof of non-publication
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=
Last, can the Factom user have a =C2=A0Proof-of-non-publication.=C2=A0= Well, absolutely.=C2=A0 The Factom state limits the public keys that can b= e used to write the anchors in the blockchain.=C2=A0 Entries that are not w= ritten 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.

The complaint Peter = has that the user cannot see all the "child chains" (what we call= Factom Chains) is invalid.=C2=A0 The user can absolutely see all the Direc= tory Blocks (which documents all Factom Chains) if they have access to Fact= om. 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 manua= ls, 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.=C2=A0 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 ass= umption that the audience for a Factom user must necessarily be limited to = information found in the blockchain.=C2=A0 Yet the user certainly should ha= ve access to Factom if they are a Factom user.=C2=A0 Factom then is no diff= erent from the New York Times, and the trust in Factom is less. As Peter sa= ys 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 w= ay to know if there were other versions of an issue outside of looking at a= ll New York Times issues ever published. =C2=A0

Fa= ctom on the other hand documents their "issues" on the blockchain= .=C2=A0 Any fork in publication is obvious as it would require different Bi= tcoin addresses to be used, and the blocks would have to have validating si= gnatures of majorities of all the Factom servers. As long as a fork in Fact= om can be clearly identified, and no fork exists, proof of the negative is = assured.=C2=A0 And upon a fork, one must assume the users will specify whic= h fork should be used. =C2=A0

Proof of publication= does not require a system that cannot fork, since no such non-trivial syst= em exists.=C2=A0 What is required is that forks can be detected, and that a= path can be chosen to move forward.
--089e0141a3581b1888050a5b36d7--