From: paul snow <snow.paul@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] Setting the record straight on Proof-of-Publication
Date: Wed, 17 Dec 2014 16:20:33 -0600 [thread overview]
Message-ID: <CAMU7uis0A=BEOgPw=7Z_9F744hrXaVMB_p_D3Z7MYxk40oL+9A@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3831 bytes --]
[[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.
[-- Attachment #2: Type: text/html, Size: 5373 bytes --]
next reply other threads:[~2014-12-17 22:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-17 22:20 paul snow [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-12-16 20:28 paul snow
2014-12-12 9:05 Peter Todd
2014-12-12 12:25 ` Gareth Williams
2014-12-12 17:04 ` Alex Mizrahi
[not found] ` <CAOG=w-v3qjG3zd_WhfFU-OGnsHZEuYvY82eL4GqcdgY6np5bvA@mail.gmail.com>
2014-12-12 17:50 ` Alex Mizrahi
2014-12-13 13:32 ` Gareth Williams
2014-12-15 4:52 ` Peter Todd
2014-12-17 11:55 ` Gareth Williams
2014-12-21 6:12 ` Peter Todd
2014-12-15 4:17 ` Peter Todd
2014-12-12 13:41 ` odinn
2014-12-12 14:17 ` Justus Ranvier
2014-12-15 4:59 ` Peter Todd
2014-12-17 1:16 ` odinn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMU7uis0A=BEOgPw=7Z_9F744hrXaVMB_p_D3Z7MYxk40oL+9A@mail.gmail.com' \
--to=snow.paul@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox