Author: paul snow 2014-12-17 22:20:33
Published on: 2014-12-17T22:20:33+00:00
In this context, Peter provides a clear explanation of Proof of Publication and its components, including Proof-of-receipt, Proof-of-non-publication, and Proof-of-membership. However, he curiously claims that Factom cannot provide Proof of Publication. The author then goes on to explain how Factom can actually provide all three proofs. Proof-of-Membership is easily satisfied as any Factom user with access to the Bitcoin Blockchain and knowledge of Factom's first anchor can know they are a member of the audience. Proof-of-Receipt is also straightforward as users submit entries, and Factom publishes a Merkle Root to the Bitcoin Blockchain. Lastly, Proof-of-non-publication can be achieved as Factom state limits the public keys that can be used to write anchors in the blockchain. The author argues that Peter's complaint about not being able to see all "child chains" is invalid as users don't need to prove publication in all chains, but only need to restrict the domain of publication to their own chain. The author also makes the point that Factom documents their "issues" on the blockchain, making it easy to identify any fork in publication. Overall, the author concludes that Proof of Publication does not require a system that cannot fork, but rather requires that forks can be detected and a path can be chosen to move forward.
Updated on: 2023-06-09T14:43:50.369770+00:00