dansmith:
I must admit there is a lot we didn't put in the paper. There isn't a lot on consensus or incentives. 38 pages was stretching it already. Satoshi's was only 9. AlanX is memorializing more of what we are designing in a forthcoming consensus paper. Incentives have yet to be explored formally.
1: Yes, something like that. historical crowd sales map the private key owner in Bitcoin to be the new owner in the funded system. A lot of that heavily relies on having the same elliptic curve as Bitcoin, though. 5 years have passed, so we can build our system using updated crypto, but that would make shortcuts like this harder. It would be nice to get some advantages by using Edwards Curves, etc. We haven't gotten quite to that level of detail yet for that part of the system. Also, we have very limited time to experiment with new things.
2: Yes. The cost of doing business includes paying the BTC transaction fee. For the Federated servers to play in the system, they need to have a small amount of hot wallet BTC to pay transaction fees. Since there is a small (~=16) set of Federated servers who need to hold the BTC for transaction fees, users or non-authoritative full nodes do not need to hold BTC. Every 10 minutes, a deterministic algorithm determines which one of the 16 Federated servers is responsible for anchoring the group's data.
3: There are varying levels of trust that an application can have. Just like Bitcoin, Factom is eventually consistent. Bitcoin gives the irreversibility metric by number of confirmations and by how many of the nodes have the TX in their mempools. Factom will have granularity of certainty too.
certainty level 1: A Federated server has acknowledged receipt of the data.
certainty level 2: The Federated server's peers have not alerted a problem over the Factom P2P network.
certainty level 3: The Anchor (Merkle root of all Factom data over last 10 minutes) with your data in it has a Bitcoin transaction on the Bitcoin network.
certainty level 4: Federated server peers have not created alert transactions in the form of alert BTC transactions.
certainty level 5: The Anchor has 1 Bitcoin confirmation.
certainty level 6: The Anchor is buried under under several Bitcoin blocks, without also seeing some kind of alert or canceling transactions from the Federated server peers. Eventually, Factom will extend beyond a statute of limitations style period to prevent the Federated server majority from canceling an anchor of a misbehaving peer.
Since we use a multistep commit and reveal process, the Federated servers will be accepting payment for Entries which they do not know the contents of. If later, they censor based on the Entry content, it is provable. A user ( or more probably an Audit server) will publicize this censorship. The Audit servers have an incentive to make the community dislike the current Federated servers, so the Audit servers can get enough votes to be promoted up to Federated servers, and get more Factoids. Adam Back advocated for blind commitments similar to what we are doing in Bitcoin earlier.
https://bt.irlbtc.com/view/206303.0A lot of this is still preliminary.
4: When the Entry Credits are used to pay for Entries, new Factoids will be credited and spread amongst the various participating Federated and Audit servers. This is similar to transaction fees paid to Bitcoin miners. Distribution proportionality schemes are also preliminary.
5: I think this is where a misunderstanding is occurring. The 16 Federated servers cooperate to collectively sign the Directory Block, which has Merkle roots of all the Entry Blocks. They need to agree as a majority to a single directory block. If a server were to pay for Entries to the system itself, it would get back less than 1/16th of the value it put in.
Concerning the threshold multisig:
Factom's reason for existence is to move transactions off of the blockchain. looping half of the process back into BTC again goes against that core rationale, but I can see where you are going with it.
Factom is a dynamic system. With a multisig system, someone has to actually control the private keys. That doesn't afford a really dynamic system.
We have a type of delegated proof of stake. This gives the active users in the system the say in who they want to package transactions. This has some merits. I hear the Ethereum folks are planning on now using some type of POS in their consensus. There are even serious proposals for bringing POS elements into Bitcoin (see Proof of Activity
http://www.cs.technion.ac.il/~idddo/PoAslides.pdf).
The POS elements mean that the system authorities (federated servers and audit servers) can change in a short period of time based on the expressed wishes of the users. There are often calls to change what mining pools are patronized by individual miners. this will give a similar ability but enclosed in the Factom system.
If we brought in merge mining to the system, we would rely on miners twofold. we are already using miners for the non-reversibility. with merge mining, they would also be setting policy. This is a secondary business for them, and may not give it the attention someone who made it their sole business.
Bitcoin multisig currently doesn't have a high enough M of N for standard scripts. we are trying to get this project working without the help of miners (other than them not censoring our anchors, etc). current standard transactions give a maximum of 4 of 6, which isn't enough separation of powers for my taste.
http://bitcoin.stackexchange.com/questions/23893/what-are-the-limits-of-m-and-n-in-m-of-n-multisig-addresses Going higher would involve cooperation with miners.
But back to the threshold multisig. For the system to be dynamic and in control of the users, there needs to be some coupling between the stored value in the system and a say in who controls the system. in a threshold multisig system, the coupling is permanent once a payment is made. this encourages keeping smaller amounts in multisig as a balance, defeating the purpose of the whole system (moving transactions off the blockchain).
Threshold multisig also changes the system dynamics. If the service gets big enough, the majority can misbehave and steal all the stored bitcoin in the system. With the current design, if the majority misbehave, they will end up destroying the value they created in the system. This seems like the biggest problem with a threshold multisig to me.
Systems build on top of Factom are expecting it to last indefinitely. Factom also gives proof of the negative, which makes switching from one system to another expensive for a distributed system. There is some commentary on this in our AMA thread in Reddit.
http://www.reddit.com/r/Bitcoin/comments/2mkyrg/we_are_the_founders_of_factom_see_our_white_paper/ Systems are looking for a canonical source to hold the entirety of their transactions. Setting up competing threshold multisig systems would expand the search space needed to prove a negative. Also a distributed system would need to decide which system to expand its search into. Too wide of a search and spam becomes a problem. Seperating Factom from bitcoin value also makes it portable. Factom can switch the POW system which provides its non-reversibility. If Bitcoin falls to another POW system, Factom can switch to being secured by that system, or a multitude of systems.
I haven't considered all the pros and cons of a system you are imagining. I can imagine a system like it working technically. I can also imagine a purely altruistic system of packaging transactions and securing them with Bitcoin. It boils down to what system correctly aligns incentives of all the parties involved, rather than what is technically possible. On the topic of incentives, I must admit I have a strong incentive to believe the things I have described. Please do consider exploring further the system you are starting down.
