diff options
| author | paul snow <snow.paul@gmail.com> | 2014-12-16 14:28:29 -0600 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-12-16 20:29:17 +0000 |
| commit | c1973c7eec9121c2f33eaae82ab5a2db3b3bd4d4 (patch) | |
| tree | 0310c80bd9a7f298b8359a7d43cf2de581da77f1 | |
| parent | 398ba96eaff5c9112871edd020cb180002196a36 (diff) | |
| download | pi-bitcoindev-c1973c7eec9121c2f33eaae82ab5a2db3b3bd4d4.tar.gz pi-bitcoindev-c1973c7eec9121c2f33eaae82ab5a2db3b3bd4d4.zip | |
[Bitcoin-development] Setting the record straight on Proof-of-Publication
| -rw-r--r-- | 6d/87ce1786f18038c0206eb822cc2d44a77306f7 | 199 |
1 files changed, 199 insertions, 0 deletions
diff --git a/6d/87ce1786f18038c0206eb822cc2d44a77306f7 b/6d/87ce1786f18038c0206eb822cc2d44a77306f7 new file mode 100644 index 000000000..2c31066dc --- /dev/null +++ b/6d/87ce1786f18038c0206eb822cc2d44a77306f7 @@ -0,0 +1,199 @@ +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 <snow.paul@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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 <snow.paul@gmail.com> +Date: Tue, 16 Dec 2014 14:28:29 -0600 +Message-ID: <CAMU7uitZX3DEQri3nqC4vS+cs35MgtPd9CDi7Q_qNn7j6WsaCg@mail.gmail.com> +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: <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: 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 + +<div dir=3D"ltr">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).<div><br></div><div>He goes on to stat= +e (curiously) that Factom cannot provide Proof of Publication.</div><div><b= +r></div><div>Proof of Audience</div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D</div><div><br></div><div>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.</div><div><br></div><div>Proof of Receipt</div><div>=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D</div><div><br></div><div>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.</div><div><br></div><di= +v>At this point the user can have a Merkle proof of their entry rooted in t= +he blockchain.</div><div><br></div><div>Proof of non-publication</div><div>= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div><br></div>= +<div>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.</div><div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>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</div><div><br></div><div>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.</div></div> + +--089e0141a3581b1888050a5b36d7-- + + |