From: Peter Todd <pete@petertodd•org>
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] My thoughts on the viability of the Factom token
Date: Mon, 16 Mar 2015 15:12:59 -0700 [thread overview]
Message-ID: <20150316221259.GA29362@muck> (raw)
[-- 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 --]
next reply other threads:[~2015-03-16 22:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-16 22:12 Peter Todd [this message]
2015-03-20 5:46 Brian Deery
2015-03-29 14:20 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150316221259.GA29362@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox