Quote from: regexlove on April 06, 2015, 11:27:15 PM

Quote from: CanaryInTheMine on April 01, 2015, 01:01:04 AM

Quote from: Mashuri on April 01, 2015, 12:42:17 AM

Quote from: mortified on March 26, 2015, 01:12:02 AM

Using Proof of Stake will end up with Masternode stakeholders owning a lot of beach front property.
Edit: Proof of Stake will allow large Factoid holders to vote on the conversion rate. They will make it prohibitively expensive to buy entry credits. Wealthy attackers can create counterfeit entries and cause genuine entries to be ignored by consensus. In other words, Proof of Stake is not a good consensus, especially for property. Wealthy factoid holders will collude to attack record systems of valuable real estate. This has already been done in countries that have gone to computerized real estate bookkeeping. It would be better to not avoid Bitcoin's consensus approach. Proof of Work offers stronger protection from such attacks.

This. A thousand times this. Attacking POS is economically more feasible than POW.

I'm not sure I completely understand your points... But want to point out that Factom is secured by Bitcoin which is PoW

@FACTOM @mortified @Mashuri
Can you explain this concern deeper
or illustrate by an example/numbers?

Factom uses something I am calling proof of usage. Since we have this two step process to convert from Factoids to Entry Credits, we leverage that for the voting process. When a person commits value to the system, by turning tradable factoids to non-tradable ECs, they have a proportional say in who is a Federated server. Unless a large Factoid holder effectively burns their stored value, they do not have a say in how the system is run. Even if they were a Federated server and purchased Entry Credits, they would not be paying fees to themselves. The fees are something along the lines of a Pigouvian tax https://blog.ethereum.org/2014/02/01/on-transaction-fees-and-the-fallacy-of-market-based-solutions/.

We also use a Commitment Scheme http://en.wikipedia.org/wiki/Commitment_scheme, where a user pays for a hashed Entry before the Federated servers know what it is. If they decide to censor it later, then there is proof that they are censoring. Bitcoin users cannot prove censorship.

As far as counterfit entries, that is a problem if you let it be. We would expect an application which data that needs to be validated would be accompanied by a crypto signature. The Federated servers cannot forge that.

The proof of usage is for moving the system forward. Bitcoin hashpower keeps Factom servers from rewriting history.

The federated servers collectively set the Factoid->EC exchange rate. They want to set it high enough to resist spam, but not so high as to stop legitimate usage. That rate will go up and down relative to USD, BTC, CPI, etc.

"Wealthy attackers can create counterfeit..." This is true in any system, including Bitcoin. A wealthy attacker can make a 51% attack. A wealthy central bank can make counterfeit dollar bills.

"cause genuine entries to be ignored by consensus. In other words, Proof of Stake is not a good consensus," All consensus mechanisms are susceptible to collusion. You are also describing results of the 51% attack in the Bitcoin whitepaper.

"will collude to attack record systems of valuable real estate" There are a few attacks in a property record system. 1: stop changes from happening. This would be pretty obvious to the person buying the property that they were being extorted. If it gets onerous enough, then the property system would drop Factom and restart porting over history from Factom. http://szabo.best.vwh.net/securetitle.html
2: Changing history. Bitcoin hashpower stops this.
3: Creating false histories. Bitcoin will show a fork in Factom, assuming Bitcoin itself is not forked. Our system is designed to seize up before it forks.

"It would be better to not avoid Bitcoin's consensus approach. Proof of Work offers stronger protection from such attacks." I am jealous of the ability of POW to burn through sibyl attacks, and other valuable things. However, as our limited history has shown, if you are not the main Bitcoin chain, then POW makes you vulnerable, be it merge mining or straight SHA256d. Also, having a pre-defined authority set allows instant acknowledgement from one of the Federated servers.

POW provides two things: non-reversability and probabilistically chooses who sets policy. Factom relies on Bitcoin to give non-reversability. Policy is set by servers elected by proof of usage.