Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles
On Dec 20, 2014 8:49 AM, Peter Todd p...@petertodd.org wrote: However the converse is not possible: anti-replay cannot be used to implement proof-of-publication. Knowing that no conflicting message exists says nothing about who be in posession of that message, or indeed, any message at all. Thus anti-replay is not sufficient to implement other uses of proof-of-publication such as decentralized exchange³. How does proof of publication prove who is in possession of that message? Or of any message at all? The data written in an anti-replay system and the data written in a proof of publication system differs in that you can't repeat data in an anti-replay system according to some understanding of the rules of the meaning of the data (if I am following your description correctly). Obviously you can publish the same data as many times as you like in a proof-of-publication system; the interpretation of what that data means would be the responsibility of the observers, not the publishing vehicle. Repeated entries thus can be written, and the user of PoP can validate and prove they did so. If the data itself defines possession, the ownership of the message (it isn't even clear to me what you mean by that phrase) isn't defined by either proof, but by the message itself. And the message itself isn't constrained by either to prohibit proving ownership (what ever you mean by that). Of course, I do assume I can test a message (or a set of messages sharing some feature like a particular input on a transaction) as being publishable in an anti-replay system without actually publishing it. That does allow one to prove non-publishing. You can determine if a message exists that would preclude the publishing of a message; the very purpose of an anti-replay proof. And I would assert that such a search (i.e. the idea that such a search has meaning in a anti-replay system) is already incorporating the assumption that such a search is possible and must be possible for an anti-replay system. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles
I could play the game where I say, You don't understand, and, like you, not address any of your points. First, there is no dependence on implementation in my arguments. If a system can prevent replay by some set of rules, it necessarily must be able to answer the question if a message is publishable. Non publishing proofs are thus possible and even required. The argument that proof of audience isn't part of an anti-replay system is not one I picked up on, but an publicly auditable anti replay system necessarily must define its audience. Again, not an issue for an auditable system. On Dec 21, 2014 9:23 AM, Peter Todd p...@petertodd.org wrote: On Sun, Dec 21, 2014 at 07:49:17AM -0600, paul snow wrote: On Dec 20, 2014 8:49 AM, Peter Todd p...@petertodd.org wrote: However the converse is not possible: anti-replay cannot be used to implement proof-of-publication. Knowing that no conflicting message exists says nothing about who be in posession of that message, or indeed, any message at all. Thus anti-replay is not sufficient to implement other uses of proof-of-publication such as decentralized exchange³. How does proof of publication prove who is in possession of that message? Or of any message at all? With the blockchain you prove the message in in the blockchain; anyone in posession of the blockchain will be in posession of the message. Secondly determining if you are in posession of the blockchain is possible subject to the usual considerations about attacker size, whether or not your local clock is up-to-date, etc. The data written in an anti-replay system and the data written in a proof of publication system differs in that you can't repeat data in an anti-replay system according to some understanding of the rules of the meaning of the data (if I am following your description correctly). I'm not sure you understand what an anti-replay system is; data isn't written to them; they're an abstract mathematical model that may be actually implemented in a variety of ways. Now it is true that any conceivable implementation must involve some type of storage, but that storage can easily 100% local to the anti-replay oracle and need not store the data itself. For instance a trusted computer in a vault that maintains an extremely large bloom filter of previously used keys would be a perfectly reasonable implementation. If the data itself defines possession, the ownership of the message (it isn't even clear to me what you mean by that phrase) isn't defined by either proof, but by the message itself. And the message itself isn't constrained by either to prohibit proving ownership (what ever you mean by that). Wait, where did I say ownership of the message? What you quoted above says *posession*, which != ownership. Of course, I do assume I can test a message (or a set of messages sharing some feature like a particular input on a transaction) as being publishable in an anti-replay system without actually publishing it. That does allow one to prove non-publishing. You can determine if a message exists that would preclude the publishing of a message; the very purpose of an anti-replay proof. And I would assert that such a search (i.e. the idea that such a search has meaning in a anti-replay system) is already incorporating the assumption that such a search is possible and must be possible for an anti-replay system. You're confused about what an anti-replay system actually is - you're really talking about a specific implementation of one based on proof-of-publication, not the concept itself. -- 'peter'[:-1]@petertodd.org 1b728df6414af5ef95388557f1c3e5d29c569d7636b93681 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Setting the record straight on Proof-of-Publication
[[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. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Setting the record straight on Proof-of-Publication
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. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
