* Re: [Bitcoin-development] My thoughts on the viability of the Factom token
@ 2015-03-20 5:46 Brian Deery
2015-03-29 14:20 ` Peter Todd
0 siblings, 1 reply; 3+ messages in thread
From: Brian Deery @ 2015-03-20 5:46 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 9747 bytes --]
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 through many terabytes of Bitcoin
transactions to find the few MiB of Counterparty transactions. You
would also need to wade through all the other embedded protocols like
Omni, ProofOfExistence.com, and all the others in your search for
Counterparty transactions. Factom is setup so that interpreted
protocols like Counterparty do not need to wade through all other
protocol's data.
* Block limit stays. Each Bitcoin transaction becomes expensive.
Each transaction might rise to $5, $10, $15, who knows. Distributions
to asset holders would cost hundreds or thousands per dividend.
>I'm very skeptical about the long-term viability of Factom and the value of the Factom token.
>tl;dr: For the Facom token to rise in value we need Bitcoin transaction fees to rise greatly
You are making economic statements with technical arguments to back
them up. I think the economics and technicals are not as tightly
bound as you imply.
TLDR:
Factom is trying to be a censorship and spam resistant disimpassioned
3rd party, like Bitcoin.
-----END REDDIT MESSAGE-----
I like to think in audited vs interpreted protocols. Think Bitcoin vs
Counterparty. Bitcoin won't let an invalid transaction into the
system. Counterparty filters out invalid transactions after the fact.
Proofchains are good for audited protocols where there is a
predetermined auditor. There is a gatekeeper who only adds in valid
transactions.
Factom is good for interpreted protocols. A user's software will
filter out transactions which do not pass a ruleset that they agreed
to.
Both are immutable and serve as proof of publication (POP). Sure the
POP in Factom is more complicated, but the publishing powers are
shared.
On the bitcoin wizards
[IRC](https://download.wpsoftware.net/bitcoin/wizards/2015-03-16.html),
phantomcircuit seems to have gotten close, the conversation resolved
with Alice burning her house down.
There are applications where proofchains will work just fine. If you
are securing your own blockchian for your own data, proofchains will
work. You are not worried about censoring yourself.
If two rivalrous institutions are sharing a blockchain, then giving
one of them exclusive power of making the blockchain is undesirable
for the non-authoritative institution. No need to discuss that
arrangement anymore.
With threshold multisig, now multiple institutions would need to
cooperate amongst each other to create a communal blockchain. In this
example, a majority of keyholders can directly censor the minority.
The minority might have recourse like in Szabo's property club blog
post to fork the chain and start an alternate system, but if the
minority is too small, then the network will not jump to the fairer
fork.
OK, lets move authority to an industry group. For something like
property records, it is shown to work in a centralized model. Making
that model immutable with proofchains will certainly work. Property
records are highly gated as of now at the county seat. Transitioning
the county property database to a proofchains based POP will work.
They are audited records, and the auditor is predetermined. They
already have censorship powers, and would in Factom too. The only
difference would be that in proofchains an invalid record would not
exist, and in Factom, an invalid record would exist, but not be signed
by the county.
As the individual players in a system become more numerous and less
powerful, it becomes harder to have a disimpassioned industry group.
This is similar to politics where we see dispersed costs and
concentrated benefits.
Lets jump to the end and try to imagine how Counterparty would run on
proofchains. Who would be the one to package the transactions? The
counterpart devs can censor now, by updating the software to blacklist
certain addresses. They are already the predetermined auditor. The
Counterparty Foundation could package the transactions in a
proofchain. The difference to me lies in how easy it is to censor.
It feels harder to censor by baking specific blacklists into the
software than keeping a blacklisted party from ever publishing at all.
One is very visible and the latter maybe not as much. (Something like
proofchains is how I initially imagined Mastercoin and Counterparty
would work, since it seems silly to have every transaction be a BTC
transaction too. I underestimated their desire for censorship
resistance.)
In the end it comes down to the data being published, and how/when it
is audited. Proofchains prefilters data and couples the auditor with
the packager. Factom allows the users to choose how they audit data
independent of the packager. How much power do you want to invest in
one entity? Factom allows splitting of those powers.
-Brian Deery
[-- Attachment #2: Type: text/html, Size: 10426 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] My thoughts on the viability of the Factom token
2015-03-20 5:46 [Bitcoin-development] My thoughts on the viability of the Factom token Brian Deery
@ 2015-03-29 14:20 ` Peter Todd
0 siblings, 0 replies; 3+ messages in thread
From: Peter Todd @ 2015-03-29 14:20 UTC (permalink / raw)
To: Brian Deery; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]
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
0000000000000000064a6b620c22d89697757f4d81c3b839e50b03e2d3f8e168
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bitcoin-development] My thoughts on the viability of the Factom token
@ 2015-03-16 22:12 Peter Todd
0 siblings, 0 replies; 3+ messages in thread
From: Peter Todd @ 2015-03-16 22:12 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4344 bytes --]
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
00000000000000000de14334f9da364dc660a7cb1d7b695c08a3472e94d3512a
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-03-29 14:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-20 5:46 [Bitcoin-development] My thoughts on the viability of the Factom token Brian Deery
2015-03-29 14:20 ` Peter Todd
-- strict thread matches above, loose matches on Subject: below --
2015-03-16 22:12 Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox