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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YYqDy-0005Ln-8Z for bitcoin-development@lists.sourceforge.net; Fri, 20 Mar 2015 06:16:02 +0000 Received: from mail-ie0-f182.google.com ([209.85.223.182]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YYqDv-0000LX-Rb for bitcoin-development@lists.sourceforge.net; Fri, 20 Mar 2015 06:16:02 +0000 Received: by iecsl2 with SMTP id sl2so84793167iec.1 for ; Thu, 19 Mar 2015 23:15:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=YXZM9c19/pwQghd84roxofK4Xnjry6Ml/P+YZL3jrPs=; b=VJ/PYNGXxeb69kLCqu+N9rSHkYFgN1ldspmDGcjg/zcOH5UYUBptPh/1fmA4OMKK8g EQdrVzAGbhTYxwbXi5aOmQsz5/4inXg/7BF92VI905lPbob8xEIcqaof6mwNum8ZsZ8d mR9V22kI+CyCogwNg0OVzUSghXhz+mjnIJHFwzIIci+sbGCF0nbjDsQsmLxholbIF7wm zH2aMb85JFjWyPFUYQ6Lb22OhTRnbV8z5Ala0Xyc2rIRCx976L7zyfWrT113BcmctwWd 5+T+DIEfEipcgGpmIAefbjq/AZ0jbF0QIucWGnhSKV1b+LFjHharxEhhn1BB1lLSzL10 QNHQ== X-Gm-Message-State: ALoCoQkqAvtnULs0KX4EJd6mHDX1jQFBN7Z+q3Zx5c/UPtdx/de9cJMXWB/NdgsZja9V39GoJybj MIME-Version: 1.0 X-Received: by 10.107.133.154 with SMTP id p26mr112795322ioi.63.1426830378473; Thu, 19 Mar 2015 22:46:18 -0700 (PDT) Received: by 10.64.14.98 with HTTP; Thu, 19 Mar 2015 22:46:18 -0700 (PDT) Date: Fri, 20 Mar 2015 00:46:18 -0500 Message-ID: From: Brian Deery To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=001a113fb186dd353f0511b1d561 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YYqDv-0000LX-Rb Subject: Re: [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: Fri, 20 Mar 2015 06:16:02 -0000 --001a113fb186dd353f0511b1d561 Content-Type: text/plain; charset=UTF-8 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 --001a113fb186dd353f0511b1d561 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
Gree=
tings 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 remov=
ed 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 wher=
e 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 wh=
at makes Bitcoin magical, and what Factom is trying to accomplish.  Last Su=
mmer, 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 entit=
ies you described the glorious name **Compaction Service Providers** (CSP) =
and even wrote about it [here](https://github.=
com/FactomProject/FactomDocs/commit/2791c51917e3ecc65dc52bfc434ca6dec0b3a1f=
d) back when we were Notarychains.  With free entry of CSPs, censorship=
 would be limited, but the entire system would get spammed quickly, and the=
re would not be a good way to accurately locate the data you needed.  Witho=
ut 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. =20

You claim that proofchains packagers will be the very business that issues =
a stock.  Since stockholders are trusting the company to return dividends i=
n the first place, the trust can be expanded to managing all the stock trad=
es too.  In my mind, the company who issues the stock still may game the sy=
stem they control for their personal benefit.  What is needed is a scalable=
 disimpassioned 3rd party.  Something of the scale where if the company pre=
sident calls up and says "Delay these disfavored parties" that th=
e 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 (**Pro=
of 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 hone=
st.  Since we have a defined majority instead of an anonymous membership se=
t, if one Federated server goes rouge, the honest majority will all place t=
he correct anchor.  You will see 1 anchor where someone is maybe trying to =
defraud you, and 31 anchors that have the correct data. =20


> Those servers are voted in by a (quite complex) consensus algorithm

I had considered merge mining, but your [arguments against it](https://let=
stalkbitcoin.com/ltb104-tree-chains-with-peter-todd/) in reference to s=
idechains is compelling.  Without a majority of miners, then the system is =
vulnerable to consensus attack.  We gain the non-reversability by placing a=
nchors 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 h=
ave the two step payment process, we can leverage that to determine who is =
actively participating in the system, and let them determine who sets polic=
y.


>but ultimately they are trusted third parties that can break your abili=
ty to prove your Factom-secured records are honest

We are making the system so that it is visible if someone is trying to do t=
his, 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&#=
39;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 block=
chain looking for Counterparty transactions.  One of two things will happen=
 soon.  The 1MB limit will be raised, or not. =20

* Raised blocksize.  In order to see if your Counterparty asset was doubles=
pent, 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.c=
om, and all the others in your search for Counterparty transactions.  Facto=
m is setup so that interpreted protocols like Counterparty do not need to w=
ade through all other protocol's data.

* Block limit stays.  Each Bitcoin transaction becomes expensive.  Each tra=
nsaction might rise to $5, $10, $15, who knows.  Distributions to asset hol=
ders would cost hundreds or thousands per dividend. =20



>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 imp=
ly.


TLDR:
Factom is trying to be a censorship and spam resistant disimpassioned 3rd p=
arty, like Bitcoin.

-----END REDDIT MESSAGE-----






I like to think in audited vs interpreted protocols.  Think Bitcoin vs Coun=
terparty.  Bitcoin won't let an invalid transaction into the system.  C=
ounterparty filters out invalid transactions after the fact.

Proofchains are good for audited protocols where there is a predetermined a=
uditor.  There is a gatekeeper who only adds in valid transactions.

Factom is good for interpreted protocols.  A user's software will filte=
r 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 i=
n Factom is more complicated, but the publishing powers are shared.

On the bitcoin wizards [IRC](https://download.wpsoftware.net/bitcoin/wizar=
ds/2015-03-16.html), phantomcircuit seems to have gotten close, the con=
versation resolved with Alice burning her house down. =20

There are applications where proofchains will work just fine.  If you are s=
ecuring 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-au=
thoritative 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 majo=
rity of keyholders can directly censor the minority.  The minority might ha=
ve recourse like in Szabo's property club blog post to fork the chain a=
nd start an alternate system, but if the minority is too small, then the ne=
twork 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 imm=
utable with proofchains will certainly work.  Property records are highly g=
ated as of now at the county seat.  Transitioning the county property datab=
ase to a proofchains based POP will work.  They are audited records, and th=
e auditor is predetermined.  They already have censorship powers, and would=
 in Factom too.  The only difference would be that in proofchains an invali=
d 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 powerfu=
l, it becomes harder to have a disimpassioned industry group.  This is simi=
lar to politics where we see dispersed costs and concentrated benefits. =20

Lets jump to the end and try to imagine how Counterparty would run on proof=
chains.  Who would be the one to package the transactions?  The counterpart=
 devs can censor now, by updating the software to blacklist certain address=
es.  They are already the predetermined auditor.  The Counterparty Foundati=
on could package the transactions in a proofchain.  The difference to me li=
es in how easy it is to censor.  It feels harder to censor by baking specif=
ic 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 Coun=
terparty would work, since it seems silly to have every transaction be a BT=
C 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 au=
dited.  Proofchains prefilters data and couples the auditor with the packag=
er.  Factom allows the users to choose how they audit data independent of t=
he packager.  How much power do you want to invest in one entity?  Factom a=
llows splitting of those powers.


-Brian Deery
--001a113fb186dd353f0511b1d561--