Re: [Bitcoin-development] My thoughts on the viability of the Factom token
On Fri, Mar 20, 2015 at 12:46:18AM -0500, Brian Deery wrote: > Greetings mailing list. > > Not sure that this content is 100% appropriate here, but Peter Todd > invited me to post this for archival purposes. The original thread > has been removed from the search results, but is still up here: > http://www.reddit.com/r/Bitcoin/comments/2z9k5p/factom_announces_launch_date_for_software_token/ > > > I have added more thoughts too. Thanks. You know, looking though your writeup, I think we're talking past each other. I've found with a lot of other projects a good way to start is to explicitly list what you think Factom *prevents* from happening. It is after all security software - the most important thing it does is what it prevents the attacker from doing. Be specific - you really need to nail down exactly what kind of guarantees you're trying to get out of the Factom system. -- 'peter'[:-1]@petertodd.org 064a6b620c22d89697757f4d81c3b839e50b03e2d3f8e168 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] My thoughts on the viability of the Factom token
Greetings mailing list. Not sure that this content is 100% appropriate here, but Peter Todd invited me to post this for archival purposes. The original thread has been removed from the search results, but is still up here: http://www.reddit.com/r/Bitcoin/comments/2z9k5p/factom_announces_launch_date_for_software_token/ I have added more thoughts too. -BEGIN REDDIT MESSAGE- > The idea behind Factom is to create a proof-of-publication medium where facts > for some purpose can be published That is only part of the story. Factom is attempting to make a publishing platform which is simultaneously censorship and spam resistant. This is what makes Bitcoin magical, and what Factom is trying to accomplish. Last Summer, I went down the road that you are going down and kept coming up with a system that was susceptible to either one or the other. I gave the entities you described the glorious name **Compaction Service Providers** (CSP) and even wrote about it [here](https://github.com/FactomProject/FactomDocs/commit/2791c51917e3ecc65dc52bfc434ca6dec0b3a1fd) back when we were Notarychains. With free entry of CSPs, censorship would be limited, but the entire system would get spammed quickly, and there would not be a good way to accurately locate the data you needed. Without free entry, once a specific CSP (or proofchain packager) was selected by a network, the CSP could selectively censor within that network. Lock in effects would be strong, so switching the entire network over to a new CSP would be expensive. The CSPs (and Proofchain packagers) could "exclude, delay, or reorder the customer's timestamped entries". This is fine as long as the CSP doesn't have an incentive to do these things. You claim that proofchains packagers will be the very business that issues a stock. Since stockholders are trusting the company to return dividends in the first place, the trust can be expanded to managing all the stock trades too. In my mind, the company who issues the stock still may game the system they control for their personal benefit. What is needed is a scalable disimpassioned 3rd party. Something of the scale where if the company president calls up and says "Delay these disfavored parties" that the packagers tell him his company isn't big enough to push them around. I think **Factom sits in a sweet spot between** your proposed **centralized** solution **and** Bitcoin's anonymous membership authority set (**Proof of Work**). The Federated servers must cooperate to move Factom forward, but like Bitcoin, require a majority to effectively censor a transaction. It is a whole lot easier to censor with Proofchains. >The issue is if the Factom servers ever publish a Factom ledger anchor in the >Bitcoin blockchain but don't make the data available you have no way of >proving... Yes, to this point, Factom being forked is way worse than seizing up. The Federated servers are constantly watching their peers and keeping them honest. Since we have a defined majority instead of an anonymous membership set, if one Federated server goes rouge, the honest majority will all place the correct anchor. You will see 1 anchor where someone is maybe trying to defraud you, and 31 anchors that have the correct data. > Those servers are voted in by a (quite complex) consensus algorithm I had considered merge mining, but your [arguments against it](https://letstalkbitcoin.com/ltb104-tree-chains-with-peter-todd/) in reference to sidechains is compelling. Without a majority of miners, then the system is vulnerable to consensus attack. We gain the non-reversability by placing anchors in bitcoin without needing to recruit mining pools. We could have gone to proof of stake, but then someone who funded it early on would have a disproportionate say in how the system was run. Since we have the two step payment process, we can leverage that to determine who is actively participating in the system, and let them determine who sets policy. >but ultimately they are trusted third parties that can break your ability to >prove your Factom-secured records are honest We are making the system so that it is visible if someone is trying to do this, and the other members fight against it. >skipping step #3 and the dependency on trusted third parties But what you are proposing is a single trusted third party. >is you have to pay transaction fees to do it >we need Bitcoin transaction fees to rise greatly I disagree. Bitcoin is optimized for proving a negative over the domain of Bitcoin value transactions. Lets take a closed system like Counterparty's current implementation. To prove the negative (that an asset has not been sent to someone else first) you need to parse the entire Bitcoin blockchain looking for Counterparty transactions. One of two things will happen soon. The 1MB limit will be raised, or not. * Raised blocksize. In order to see if your Counterparty asset was doublespent, you will need to parse thro
[Bitcoin-development] My thoughts on the viability of the Factom token
Repost of https://www.reddit.com/r/Bitcoin/comments/2z9k5p/factom_announces_launch_date_for_software_token/cph0pvo for archival/disclosure purposes: I'm very skeptical about the long-term viability of Factom and the value of the Factom token. The idea behind Factom is to create a proof-of-publication medium where facts for some purpose can be published; the token incentivises people to maintain the infrastructure required for that medium. You can think of Factom as a two layer system, with Factom servers provide a layer that in turn is used by secondary proof-of-publication ledgers. By publishing records in the Factom layer you prove that the secondary layer of actual facts is being maintained honestly. For instance one such secondary layer might be the property records of a city using a digital Torrens title system¹ to maintain land titles. Let's look at how this works step by step: * You would know your digitally represented land title was valid because it was in the city's ledger and the digital signatures verify. * You in turn know the *copy* of that ledger that you posess is the official version because you can inspect the ledger maintained by the Factom servers. * You know that ledger is the official Factom layer - not a fork of that ledger - because you can run the Factom consensus protocol against the Bitcoin blockchain. * You know you have the only Bitcoin blockchain and not a fork because of the Bitcoin Proof-of-Work consensus algorithm. That's four steps in total. The problem is step #3 - the Factom consensus layer - requires you to trust the Factom servers. The issue is if the Factom servers ever publish a Factom ledger anchor in the Bitcoin blockchain but don't make the data available you have no way of proving that your Factom-secured ledger - e.g. the city's property title records - is the only copy out there and you're not trying to defraud someone. Those servers are voted in by a (quite complex) consensus algorithm, but ultimately they are trusted third parties that can break your ability to prove your Factom-secured records are honest. Of course in practice if this happens people will just accept it and patch their software to ignore the failure... but then why use Factom at all? You can do the exact same thing with *far* less complexity by just securing your ledger directly in the Bitcoin blockchain, skipping step #3 and the dependency on trusted third parties. (I don't mean putting the ledger itself in the chain, just hashes of it) The only disadvantage to securing your records directly in the Bitcoin blockchain is you have to pay transaction fees to do it. However currently those fees are very small - they'll always be about the cost to make a transaction - and if they do increase it's easy to create "meta-ledgers" based on explicit trust relationships. For instance a bunch of cities can get together to establish a meta-ledger for all their per-city property title systems, perhaps using efficient threshold-signature² multisig to ensure that a majority of those cities have to sign off on any updates to the meta-ledger. Of course all these Factom alternatives can be argued to "bloat the blockchain" - but how are we going to force people to use less secure alternatives to just using the blockchain? It's impossible to stop people from securing ledgers in the blockchain technically; our only way to do it is via social pressure like writing angry posts on reddit and lawsuits. tl;dr: For the Facom token to rise in value we need Bitcoin transaction fees to rise greatly, and/or people to choose to use much more complex and less secure systems in preference to much more simple systems. Disclaimer: I've been hired by Factom to review the Factom protocol. I also am working on a competing library called Proofchains that among other things can be used to secure ledgers using Bitcoin directly. That funding model for that effort is to convince individual clients that they need the technology and should pay me to develop it. 1) http://en.wikipedia.org/wiki/Torrens_title 2) https://bitcoinmagazine.com/19528/threshold-signatures-new-standard-wallet-security/ -- 'peter'[:-1]@petertodd.org 0de14334f9da364dc660a7cb1d7b695c08a3472e94d3512a signature.asc Description: Digital signature -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
