From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 ; Mon, 16 Mar 2015 22:13:03 GMT Date: Mon, 16 Mar 2015 15:12:59 -0700 From: Peter Todd 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--