diff options
| author | paul snow <snow.paul@gmail.com> | 2014-12-17 16:20:33 -0600 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-12-17 22:21:22 +0000 |
| commit | d39daf5ed7d1130188f0a6562e2021cad8594548 (patch) | |
| tree | f55fbcb742be49884e196df5c275047ef2cdd84d | |
| parent | 4c22498a060e1e315e42d36984990d3571dbc751 (diff) | |
| download | pi-bitcoindev-d39daf5ed7d1130188f0a6562e2021cad8594548.tar.gz pi-bitcoindev-d39daf5ed7d1130188f0a6562e2021cad8594548.zip | |
[Bitcoin-development] Setting the record straight on Proof-of-Publication
| -rw-r--r-- | 6c/e3c7e859aaa7d24c10b7071ee5776acb180f62 | 221 |
1 files changed, 221 insertions, 0 deletions
diff --git a/6c/e3c7e859aaa7d24c10b7071ee5776acb180f62 b/6c/e3c7e859aaa7d24c10b7071ee5776acb180f62 new file mode 100644 index 000000000..acd9841dd --- /dev/null +++ b/6c/e3c7e859aaa7d24c10b7071ee5776acb180f62 @@ -0,0 +1,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-- + + |