Is the whole point of Factom the ability to store hashes on a blockchain?

[cryptworld]

I thought that you can do that with maidsafe,
isn't maidsafe able to do almost everything that factom do?

[dwma]

Some speculate solely on Bitcoin and despises speculation on any alternative blockchains. They even morally look down at others over this!

Bitcoin has many issues to become so generalized.  The very fact that Justus wants BTC to be a store of value while also believing BTC to be a the blockchain data store speaks to the extremism in his view.

People who have approached this technology with an open mind come to it with vastly different opinions.

[justusranvier]

Bitcoin has many issues to become so generalized.  The very fact that Justus wants BTC to be a store of value while also believing BTC to be a the blockchain data store speaks to the extremism in his view.

Congratulations on learning how to use scary words like "extremism".

Perhaps someday you can graduate to adjectives and maybe eventually even syllogisms.

[justusranvier]

Let's stay on topic.  The need is to prove the negative.  You cannot prove the negative outside a bounded context, but you can do so within a bounded context.  

Neither Factom nor Colored Coins nor Bitcoin nor any other ledger can change this.

The bounded context can be defined by a colored coin.  Only with physical assets, actions can be taken outside colored coins.

The bounded context can be defined by Factom.  Only with physical assets, actions can be taken outside of Factom.

That is a complicated way of saying that you were conflating two independent issues under the term "negative proof":

1. Can a user trust real-world entities to honour the promises represented by a digital token.
2. Can a user trust that a particular digital token is valid with respect to other digital tokens.

The first issue is not a problem that can be solved by software and in that case both Factom and colored coins are on the same solution. Since it's completely outside the scope of the conversation that's not what I was talking about when I said redesign problems to remove the need for negative proofs.

The second issue is one that can be solved by creating a system the proves that no conflicting digital tokens exist compared to a particular token of interest, but they can also be solved in much easier ways such as having the holder of the token produce a positive proof of ownership.

The second way is easier to implement and more robust, and the former is overly complicated unless the actual goal is to produce straw justifications for an appcoin.

[AlanX]

That is a complicated way of saying that you were conflating two independent issues under the term "negative proof":

1. Can a user trust real-world entities to honour the promises represented by a digital token.
2. Can a user trust that a particular digital token is valid with respect to other digital tokens.

The second issue is one that can be solved by creating a system the proves that no conflicting digital tokens exist compared to a particular token of interest, but they can also be solved in much easier ways such as having the holder of the token produce a positive proof of ownership.

You claimed the existence of designs that avoid negative proofs. "A better solution is to approach problems differently such that negative proofs are not needed in the first place,..."

Your words, not mine.

In no way was I "conflating two independent issues".    Issues are the things for which you find a solution.  Your two points are two ways to deal with the need for negative proofs and enforcing them.  There are others:  

1.  A user can trust real-world entities to honour the promises represented by digital statements provided by those entitites

2.  A user can trust real-world entities to enforce the promises represented by documents between the user and other parties

3.  A user can trust real-world entities to record and secure agreements for presentation to enforcement entities if necessary at the time these agreements should be executed.

And there are more. Maybe an infinite number of them.

All of these (and your suggestions) revolve around the idea that you can establish one way or another both positive proofs (that agreements have been made, services performed, goods delivered, etc.) and negative proofs (parties held rights to goods (no double spend), services were not performed, goods were not delivered, agreements were not made, etc.).

We can talk about the philosophical nature of the issues, or we can talk about solutions to the issues that beset us.  I was not talking about our particular solution, but rather trying to address your assertion that there was no issue at all.  

The second way is easier to implement and more robust, and the former is overly complicated unless the actual goal is to produce straw justifications for an appcoin.

There is no holy one way to address all the situations that people may find themselves in.  Colored Coins are great solutions for some problems.  They do not solve every problem.  Factom is a really great solution for some problems.  Factom does not solve all problems.

I am not sure why you think the existence of an AppCoin is so evil.  But I'd be totally willing to discuss the design of Factom, and why we have a token if you like.  I do not care to try and stigmatize anyone for disagreeing with our design.  Perhaps some dialog would actually be helpful.

[AlanX]

I thought that you can do that with maidsafe,
isn't maidsafe able to do almost everything that factom do?

Maidsafe doesn't timestamp, order, or create chains of data.  You might be able to do with Maidsafe what you can do with Factom in some fashion, but it would be easier to put your data in Maidsafe and timestamp it in Factom.

[AlanX]

Since this conversation appears to be at an end, let me give a more thoughtful response to this post.

Let's stay on topic.  The need is to prove the negative.  You cannot prove the negative outside a bounded context, but you can do so within a bounded context.  

Neither Factom nor Colored Coins nor Bitcoin nor any other ledger can change this.

The bounded context can be defined by a colored coin.  Only with physical assets, actions can be taken outside colored coins.

The bounded context can be defined by Factom.  Only with physical assets, actions can be taken outside of Factom.

That is a complicated way of saying that you were conflating two independent issues under the term "negative proof":

1. Can a user trust real-world entities to honour the promises represented by a digital token.
2. Can a user trust that a particular digital token is valid with respect to other digital tokens.

The first issue is not a problem that can be solved by software and in that case both Factom and colored coins are on the same solution. Since it's completely outside the scope of the conversation that's not what I was talking about when I said redesign problems to remove the need for negative proofs.

The scope of discussion is about "proof of the negative".  You can do so within a restricted context.  Like digital coins.  It is harder (as in case 1. above) when you want to actually be useful in the real world.

The second issue is one that can be solved by creating a system the proves that no conflicting digital tokens exist compared to a particular token of interest, but they can also be solved in much easier ways such as having the holder of the token produce a positive proof of ownership.

"Positive proof of ownership" can only exist within some context where other ownership can be excluded.  If the party can transfer ownership, then there was a state where some set of data proves their ownership.  But that data can never be taken away from the owner.  So clearly there must be some way to add data, to allow transfer of ownership to someone else.  

You can't get rid of the previous data, you can only amend it in some way.  Every technology based on ledgers does this.  Bitcoin, databases, double entry accounting, the DMV, ... everyone.   And ownership then is proven by eliminating the possibility that someone else owns the token.

Unless you have invented something like Harry Potter's Map, that no matter who holds the data, it is updated as the state of Hogwarts changes...

The second way is easier to implement and more robust, and the former is overly complicated unless the actual goal is to produce straw justifications for an appcoin.

The injection of appcoins in this discussion is the staw argument.  Not even in Factom does the appcoin have anything to do with proving the negative.  It provides an incentive to maintain a ledger.  Just as Bitcoin's token provides an incentive to maintain a ledger.

It is the ledger that allows a proof of the negative.