1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1YXdG5-0001YE-CC
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Mar 2015 22:13:13 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.111 as permitted sender)
client-ip=62.13.148.111; envelope-from=pete@petertodd.org;
helo=outmail148111.authsmtp.net;
Received: from outmail148111.authsmtp.net ([62.13.148.111])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YXdG2-0001nu-UK for bitcoin-development@lists.sourceforge.net;
Mon, 16 Mar 2015 22:13:13 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t2GMD4Qn034837
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Mar 2015 22:13:04 GMT
Received: from muck ([50.58.157.74]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t2GMD0DD019759
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Mar 2015 22:13:03 GMT
Date: Mon, 16 Mar 2015 15:12:59 -0700
From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20150316221259.GA29362@muck>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3"
Content-Disposition: inline
X-Server-Quench: 9da692b0-cc29-11e4-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgN1
LRkLXVBSFQB4Ax4L Bx0UUho8cgVYfXZu ZENlQHdfQ0Fycll8
DApWYhByZRMUaGEW V0VROQJVcQpIMBYR O1Z2ViENfDZUZHN9
RlY+Y3U7ZmQBbXwN GFxcdVtLHEoCQSgZ VlgeHTIyEk0ZXG00
KVQ6KlNUAkcYOEQ2 MEcwEVUWewMSB0Vw FkpRByoRO14CSixD
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 50.58.157.74/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1YXdG2-0001nu-UK
Subject: [Bitcoin-development] My thoughts on the viability of the Factom
token
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2015 22:13:13 -0000
--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 fac=
ts
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 t=
wo
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=B9 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=B2 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-wall=
et-security/
--=20
'peter'[:-1]@petertodd.org
00000000000000000de14334f9da364dc660a7cb1d7b695c08a3472e94d3512a
--r5Pyd7+fXNt84Ff3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVB1VoXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwZGUxNDMzNGY5ZGEzNjRkYzY2MGE3Y2IxZDdiNjk1YzA4
YTM0NzJlOTRkMzUxMmEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udxrvAf/eJB6L7bIiL1o9YInEoTuSXt1
N89gjOho0nZFEz0E1WzPaCPCm0m1TnKG7qonEoaLNoDTCrm6SczCP7w01ovR4eEV
Je2qjwDUdrlGuXu6bG92kTtFEQ7/X0ih+Zo4QtOOARgMad0Nqqo3I89lM9ungK8H
PPYRN/4y60t2Q1kUXsH9iwaNCFuTjTMQRQCZ3poQzRSCTeQZJdeL39WxQF57hmDp
8M/AiYstPfas3BiQufDICyuKLFVjtPLpWRhsqot2eusv3cxu6+3Gbs/91i1duueK
zJfj4OhJXfyjfNiYK2Zn8K3LdlLdhsF3+o7p1cFgqD8LcfKLs+dqiE/G6iC9ZQ==
=3H2P
-----END PGP SIGNATURE-----
--r5Pyd7+fXNt84Ff3--
|
