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
