What is Factom? Paul Snow Interview
Are you wondering just what is this new Factom project, and how does it work? Here on a couch in the Media room of the North American Bitcoin Conference, ...
So here at the conference, I ran into Paul Snow of Factom. They have a really nice booth on display there at the front of the conference. And I pulled him aside here in the media room where we're going to ask him some questions. We're going to tackle some, I think, even controversial minor controversial points on the Factom Project. I hope I get some answers and just explore what it is that you guys are doing. So welcome to my channel.
Glad to be here. Do you want to introduce yourself and who you are? Well, my name is Paul Snow. I've been in the cryptocurrency space since early 2011. I read an article about Bitcoin. At the time, you could use PayPal to put money into some place called Mt. Gox.
Oh, yeah. And so I put a little money in Mt. Gox, bought a little money, bought a little Bitcoin at 77 cents. Yeah. And then pretty much didn't really watch Bitcoin so much. You know, I watched the rise up to 30 and watched the fall and everything.
But I really wasn't concerned about much of any of this. And that was kind of my introduction to Bitcoin. Well, when it began to rise-, coming up into 2013, I began to get a little more interested. I actually took the effort to find something that was a little more technical, that could actually tell me how Bitcoin worked. And that was when I went, oh my goodness, why didn't I dump everything I had into this thing? Yup. Yeah.
But even still, perhaps most of the Bitcoin that I have came from that initial impulse purchase at 77 cents. Right. I didn't know that Mt. Gox was taking PayPal. I used Mt. Gox a number of times.
And what I did, I had to wire-transfer the money. It was really dated at that time. Did they actually do PayPal at the start? They did. They did PayPal for a little while and then PayPal cut it off. Yeah. That doesn't surprise me.
So I think the window was maybe a month or two or something. But don't quote me on that. Right. That would make sense then. I can't imagine they'd stand for that for very long. No.
So okay. Let's move the conversation over a little bit to Factom. Tell me, how did you get involved with the project? And what was your introduction to Factom yourself? Well, I was actually the guy that put Factom together. Right. I did the initial design and architecture. What happened was, about this time last year at the other, at the Miami bitcoin conference, I met David Jonston.
We were sitting at a table. I had known him from Austin, Texas. We both live in Austin, Texas. But I met him at the conference. We're sitting there and we're talking. And he said, "You know what we really need in this space is an incentive model for open source development, where you could do open source development, release software as open source, and yet somehow get value, tokens, or payment for the development work that you're doing, maybe even figure out a way to create a software license for open source.
" I told him, "Well, I've always thought about this, but in the terms or in the context of a distributed operating system where the focus wasn't functionality, but the focus was how do you configure a system to do exactly what you want it to do." And that was stymied by the fact that you need to know what the software is that you're installing, you need to know the parameters around the hardware that you are configuring, how much memory it has, what processor it has. You may want to specify something about the operating system. So many different factors. And there's no way to create a distributed registry to track all that. And then it was at that point I was like, but wait a second, now with the Bitcoin block chain, you actually have a distributed registry.
I actually have the way to solve this fundamental problem for open source. David laughs because he remembers how I just paused for 30 seconds as, you know, as the light came on. So we went back for a few months and I designed, designed, designed. And realized that that's too complex because everything I'm doing is actually building identity systems where I can talk about this processor, the next version of the processor, and the next version of the processor. This version of some software, the next version, the next version, the next version. This project, this installation.
So many factors go into configuring something. And all of these attributes assigned to a thing, there's another word for that, and that's identity. An identity is a thing that has certain attributes. Right. And then when you consider these attributes, you realize these attributes change over time. This will shock you, but I'm actually a day older than I was yesterday.
Yes. So my age is progressing. It's a vector, not a scalar. Your state has changed. Yeah, my state has changed. I go from hungry to full, sleep to awake.
I'm aiming for awake. Yes, you are. It was a late night last night, like every conference. And then we had morning meetings at 8 o'clock this morning so it was ridiculous. Oh, yeah. You had that, at least.
So all these states change. And really, why all that sounds trivial? Those are attributes of a thing, where, I'm the example, that dictate my functionality in a context and that is important, not just with people, it's also important with systems because a system can be busy doing backup. Absolutely. So there's all this other stuff. And so then I started working on identity, realized that's too complex because in order to create this chain of states I needed, really, some tool that would give me a chain of arbitrary data, didn't restrict me in any way, and let me write, this is this state at this point in time. And then, later this is this state at this point in time, and this is this state at this point in time.
And then I could take a collection of these lists of things, and I could correlate and understand what a system should look like at this point, and how it should be modified to be properly configured at this other point, and so forth. And this platform that I needed to create, distributed autonomous identity, this platform that I needed is what actually I'm doing now, which is Factom. Once I have this tool, then suddenly it's not just distributed identity that I can do. I can also track the creative process of a movie or a book or an orchestration. I can track the issuing of a will, you know, the writing of a will and the modifications of that will so at the point that a person dies, there's absolutely no doubt what the proper state of that will is, cryptographically proven. Settlement between systems of record.
Things like the mortgage crisis that happened and Bank of America is fining for foreclosing on people that actually paid their bills. The reason they ended up doing that is because records were lost. And records were lost because there were multiple systems of record involved, but many of those systems of record disappeared. Now what Bank of America did wrong is they actually filled in the gaps but just pretend that you really can't do that. We can't do that. Right, well apparently they can't either.
They had a $17 billion fine. It was fairly significant. But solving these problems are about creating a way to verify and validate data so that that data can be replicated, and yet still be validated and proven to be usable, and from the source that it came from. And so Factom provides that solution. We're looking to talk to Nigeria to work with the government there to solve a little problem called, you know, identity theft. Right, right.
Who knew? And what that, where that will go and what will happen with that is undetermined. But there's so many of these problems where business processes are not secure that Factom can work to solve. Do you have a background in software development then? Yeah, pretty much. Okay, just making sure. Yeah, I tend to..
. You talk like you do. I just wanted to make sure before I continue. Well, I wrote the rules engine behind the eligibility determination system for Medicare and Medicaid. Wow, that's definitely quite a background. Yeah.
So anyone who gets any of these assistance programs in the state of Texas or Michigan... I do not envy that job. Well, I don't know anything about the subject matter. What I built was a rules engine, a compiler, an interpreter sort of thing, that allows policy experts to actually write the rules, and this compiles them into workable code.
Gotcha. Okay. That actually sounds a lot more fun, actually. Fun than what? Yeah. Than sitting around and figuring out who gets Medicare and Medicaid and all those, yes. Right.
There you go. Yeah, 3,000 decision tables in Texas, to make these determinations. Yeah. I mean, I'm surprised it's even deterministic. I would think there was just some degree of randomness that goes on with it. Actually many of the solutions for rules engines are in fact a forward chaining systems and whatnot that use a random ordering, or not necessarily random, it's deterministic.
But it's not deterministic by the people writing the rules. And those systems are not used in eligibility determination because they must be deterministic and they actually must follow the handbook. So decision tables are nondeterministic... Or decision tables are very deterministic for determining eligibility.
Sorry. You hit a button, and I'm a techie. No, that's great. That's great. That's why I like doing these interviews. I try to add a little more of a programmer's angle to some of that de facto and stock stuff people are doing.
Sure. So let's talk about the development of Factom then. What language is it developed in? And who's been behind the development efforts? We're developing in Go. I wrote some initial code. A young friend of mine, Ethan Reisner, wrote a good bit of libraries. And then we slowly brought in some other developers.
Ethan had to go put satellites in space. Yeah. NASA calls, you answer. Yeah. It was a little small startup in California. But we built up a developer of about six or eight core people, and we have about 30 community leaders and cheerleaders worldwide that are talking to different groups about use cases and bringing interesting ideas to the table.
And how are you persisting on block change? Do you actually call the Bitcoind out of the command line or via the JSON H.T.P., A.P.I.
s with actually formatted transactions? We actually call the JSON interface to, and like you say, B.T.C.D. and B.C.
C. is the Bitcoin protocol rewritten in Go. Yeah, in the Counterparty platform, we're strongly looking at B.T.C.D.
and Bitcoind is obviously is great. We're looking for more throughput than we're getting with Bitcoind right now. It's a little bit flaky at times. I don't know if you're having that problem, too. No. Okay.
B.T.C.D. is so solid and so fast. So you're using B.
T.C.D. already? Yes. Okay. Yeah.
We're very strongly examining that. I think we want to move in that direction. Now, while I say that, most of the development is still running against the Testnet on Bitcoin, so that's not nearly the size and complexity of the actual Bitcoin block chain. B.T.C.
D. works wonderfully against the Testnet, but like I said, not necessarily the same thing as running against the full block chain. And are you encoding data in the multisig outputs or the OP_RETURN? OP_RETURN. In OP_RETURN. Okay. Because we're only dropping one anchor into Bitcoin every ten minutes, and that anchor secures all the transactions that come in within 10 minutes.
So you get like a Merkle root that you're putting in the OP_RETURN and that goes in on a harpy every block or something? Yeah. See, that's really interesting because you put in your entries. Let's say it's a will. It's a will, then you decide to disinherit your son. Then you decide, oh, he actually did clean up his room, so I'll bring him back in. Right.
And all of these updates to your will are going into your own Factom chain. So you create a Factom chain. You stick your will as an entry, your will and your updates to your will and so forth. And these entries are hashed, and created, and stuck into an entry block. And that entry block has the hashes of all the entries in your chain that came in within that ten minute window. And then after that ten minute window, everything gets written out and you start another entry block and you put more entries.
Each of these entry blocks create one Merkle root that goes into the directory block. And the directory block then has an entry for your chain, entry for, say, Mastercoin or Omniwallet chain, or a Counterparty chain, or a mortgage chain, or an identity chain and so forth. So at the directory block level, this is a micro-chain. It's always very, very small relative to the data that you're collecting. And you can chase the directory chain to find the entries that you're interested in and go up and down. This means that Factom provides these vertical proof corridors where you can go from Bitcoin through a Merkle tree to the directory block, through a Merkle tree to your entry block to the various entries, and prove the negative on your chain without looking at anything else or anybody else is submitting into Factom.
That means that, yes, while your application may need access to Factom, you can ignore 99% of the data in Factom and still be cryptographically sound on the execution of your own application. That's very different than what we're doing in Counterparty. In Counterparty, we encode it into every single transaction. So all of the knowledge is persisted directly on the chain, whereas you guys are...
I guess it's kind of a merged mining approach in many ways or even a de facto approach. Yes. Is it your vision then that if you have 1,000 Factom users, they would themselves be running 1,000 different separate nodes that will be checking in at those regular 10-minute intervals? Or do you have a super set of the frequent block chain and all the users are on your chain and the access nodes for each other's data? Right. So Factom is a protocol like Bitcoin. Right. Or like Etherium.
Okay. So all the data in Factom is completely independent of the Bitcoin block chain. So full nodes in the Factom node network are the nodes that you submit entries to. They get messaged around, just like a transaction in the Bitcoin world. They come to what we call federated servers, which one of them gets selected..
. There's a white paper. You can read all about it. Go to Factom.org and get into the details. But at a very high level, a federated server has responsibility for your chain in that moment, and it's the one that orders every entry in your chain.
So anyone, everyone submitting entries to your chain, if it's some sort of chain that you're using to coordinate multiple people. Like for instance, let's say you move Counterparty to run on top of Factom. Then you would have a Counterparty chain. And those transactions have to be ordered in order for those transfers of value to be proper. That server in that moment would be ordering those, and sending out notifications that those entries are now in that chain. And users, as soon as they get the notification that the entry's in, can assume that it's in because those nodes can be listening to all the messaging, and simultaneous with the server that's ordering, build the same representation locally.
And all the nodes in the network can be doing that for your chain. So there is no way, once you get the notification that it's there and everybody's got it, that you can reverse it. That takes transfer time, as opposed to waiting for a block to... I like that.
I mean, frankly there's a lot of these sort of... Would you consider yourself a Bitcoin maximalist? Is this a bitcoin maximalist system? I actually do consider myself somewhere in between a Bitcoin maximalist and a more flexible individual, digital coin individual. Okay. Let's address that.
So have we finished the architecture question? I think for now. It's good enough. I think the white paper would really serve as a great reference thereafter. Yeah, the white paper is. Absolutely. You answered a lot of my questions, certainly.
Because if I try to get into the architectural details... They're going to fall asleep probably. Yeah, you guys..
. Thanks for bearing with us so far. Absolutely. So let me talk about how...
We have a token that drives our system. But the critical thing in the architecture of Factom is ensuring that anyone who wants to use the protocol never has to touch any cryptocurrency token. Because cryptocurrency tokens are kryptonite to the banking and financial system. If you go up to a bank and say, "You can use the block chain technology to secure your communications or settlement between one branch and another branch." And they'll say, "Great! We would like to have that block chain technology. We've been hearing about it, reading about it in the Wall Street Journal.
" And you say, "Okay. Well, the first thing you need to do is set up a Bitcoin wallet." "No. We don't want a Bitcoin wallet." "But you have to get some Bitcoin to drive it." "No.
" Because what they hear is running service business issues, money transfer business issues, added scrutiny by FinCEN, added scrutiny by the F.C.C. A bank cannot tolerate that. So they may set up a group to play with it, but they'll never use it as part of their business if it requires them to install wallets and do cryptocurrency transactions. So we get rid of that.
We get rid of it by having a two-stage process. We have factoids that essentially represent the right to obligate the protocol to record data. Okay? So those are freely traded. Because if I want to create a store that sells access to Factom, I'll need some of these tokens. I need to buy them from the market. Where do I get them? Well the servers are being rewarded in those tokens so I'll buy them from the servers.
I'll set up my storefront. Now, I want the bank's command and I say, "I'm going to let you have access to protocol." Well, how do I communicate? This is a store,maybe it's in Arkansas, Little Rock, Arkansas, and they're going to sell access to Factom, which is run all around the world. How do they do that? Well, they convert Factom into an entry credit. And an entry credit is assigned to a public key that the customer provides them. So the bank says, "This is the public key I would like to use.
Here's $20. I would like $20 worth of entry credits." And this little store in Little Rock, Arkansas says, "Okay." They get the appropriate amount of factoids and convert them to entry credits and tie into that public key. Now, entry credits are non-transferable. They are non-refundable.
They are quite literally a license to place X-number of entries with these ten entry credits, ten entries into Factom. Okay? That's it. Now, the bank can go and put ten entries and they say, "That's great. I need more." They go to the store. They buy 100 this time.
They use those up. They go to the store and they say, "You know, really, I'm tired of having to come here and buy these all the time. I'm going to give you a credit card. Anytime you see my balance go down to 10, I want you to refill it to 100." And the little store in Arkansas says, "Great! We just got telephone service. We can do that now.
" And so now, conventional payment for a subscription service to an open source protocol. It's never been done before. There's never been an open source global protocol that can sell what is quite literally a software license that allows access. Who gets the right to sell the license? Well, it has to be someone who's provided services to the protocol. That's the servers. Well, they can sell that right to obligate the protocol to someone else.
They can set up a store and all is well. And this isolates the bank from any kind of cryptocurrency at all. It gives them free access to the data because the data is all distributed through distributed hash table type technologies like Bitcoin. So reading is free. The only thing you have to be concerned with is how do you write it into the system. And everyone's happy.
It also secures their servers. There is a huge security advantage to having a software license to something versus a wallet. If I compromise a server with a wallet and I get the private key, I can transfer funds to some other location and laugh as I go running away. Yeah. That's about right. But if you break into a system and you get a public key holding an entry credit, you get the enormous right to put entries in the Factom.
You can't transfer. Also, you have it, but the original guy also has it. And if you want to sell it to someone else, you have to give them a private key. And the guy that's buying it knows, you have the private key, you thief, and the guy that you stole it from still has the private key. What good is this to me? I mean, I don't care if the balance says 100. How can I know that it's going to be 100 in five minutes? So it's a worthless commodity to sell.
So it means that an application using entry credits is enormously more secure and easy to manage, not to mention the fact that entry credits are very, very small value. So we're intending for an entry to cost a tenth to a hundredth the price of a Bitcoin entry in Factom. So writing something in Factom is just an order of magnitude or cheaper than putting a transaction in the Bitcoin block chain. Yes. Is the D.H.
T. a part of the Factom code? What are you guys using for that? Is it a library? Are you building the whole thing yourselves? No. We're using some libraries. Do you know which ones they are? But that's still in development. They're still in development? Yeah. Okay.
So let's talk a little bit, too, about Factom from a business perspective. You guys, are you guys receiving financing? Have you got a business model? We have some financing. We will be doing a Crowdsale. A Crowdsale basically sells the initial block of factoids to people that want to invest in the protocol. And then the economics of the architecture are designed to allow the value of factoids to track the utility of the protocol. So tell me a little about the factoids.
What is the value of a factoid? And how do you envision people receiving their investment money back? How does it work? Well, the design of the factoids... The federated servers set the exchange rate of factoids to entry credits. And they're motivated. They get a fixed number of factoids every day for being the federated servers.
And there's some interesting distributed things we're working on, but that's immaterial at the bigger picture's level. So they get a fixed amount of factoids. So their interest is to ensure that the factoids they get are of the highest value they can manage. The only thing they can do to increase the value of their payment is to ensure that the protocol is used as widely as possible. They're basically maximizing the price of the factoid times the volume. If they set the price too high, the volume goes way down, the number of factoids that are being converted into entry credits and into Factom goes down, and you get inflation and so .
.. So hold on one second. A factoid, does that represent a token for persistence? Yes. Is it consumed then? And therein is the value? Yes. We say it, well, it gets converted.
The factoid becomes entry credits, the entry credits become entries. And then it's out of the economy. So yes. And do they expand at a rate? You have a fixed flow going into the servers. That's the only source. Is that fixed flow is set up by you guys then? We're going to set it up with a Crowdsale as a percentage of how many factoids are in the system.
They're going to start with 20% of the initial volume of factoids, and you'll have the first year 20% inflation minus any that leave. So you set up a document where this is available for the public to look at and see how the economy is expected to grow, where the distribution is, is there any progress right now? It's very, very difficult to make any kind of projections. Yes, it is. And so the value of the factoid could go up or could go down. Well, the money supplies itself, it should be. I would like to think it'll work.
It will find the equilibrium. And the equilibrium that it will find should amount to the value of the factoids going into the servers will balance with the amount of value that people using the protocol are getting. What they're paying in will eventually balance with the value that's going to the servers. Right. So what you'd want essentially to increase the value is to have more partners, I guess? Yeah? Okay. So let's talk about that.
Do you have some partners lined up already? Can you talk about them? Is that under wraps? We have the Nigerian group. We have a bank in Asia. We can only be rather vague on the record for a lot of this stuff. But we have a bank in Asia that we have meetings set up within the next week or two. Would this be available prior to the Crowdsale then? Or this will be up in the air for a while? We push for this stuff to resolve itself as quickly as possible. I can't tell you when it will resolve.
That's a perfectly fine answer. But a bank in Asia, a very, very interesting financial player in the United States, we have meetings with them this week. We have had last week an in-person meeting at the presidential palace of a South American country to solve some issues that they have in their country. And there's like three or four or five other players in terms of trading assets and all sorts of other interesting things. Well, we have people encroaching our space. We'll wrap this up soon.
One or two more questions. Granted there's a little bit of a controversy there because I think somebody, it was either misquoted, or expressed that a good number of books will be stored on block chain. And then people were kind of taking it apart. Maybe they were being a little pedantic. You want to clarify the record on that, just so that we can broadcast that to the community? Oh, certainly. It's a tempest in a teapot.
We did a demo where we took somewhere near 29,000 books out of the Gutenberg library, all public domain, open source books. And we entered a hash for each book along with metadata, the author, the title, that sort of thing. And created an entry and entered it into a chain in Factom. So there's a Gutenberg chain in Factom. It has an entry for each book. It has also this metadata in it.
And then through Factom and the level D.B., you can do a search and find that book and data. And you could rehash the book, and verify, and validate this book is exactly the one they had when they created with this chain. So over time, a hundred years from now, if they found a set of books, and some of them were corrupted, and some of them weren't, they could figure out what was corrupted, what wasn't, and validate them against the Factom chain. So that's the official answer.
That's the demo. That's the expounded answer. Yes. But what was the reason? To secure books? No. The reason was this is something you could download, read yourself, see how we used the A.P.
I. because all the code is open source. And you can say, "Oh, I would like to secure medical records," or "I would like to secure legal documents." Well, of course, you would do it exactly the same way. But I don't actually have legal documents or medical records that I'd want to use in the demo so we used some other source of data. Okay.
That seemed like a very easy enough clarification. So there you go. Not a big deal. We appreciate the transparency, of course. You only get so much time in front of a microphone on the stage, and people pick and choose little bits and pieces and you know..
. I think most of the criticism was coming from people that weren't in the talk. Because, I think, it was fairly clear in the talk this was a demo so that people could see how the A.P.I. was.
I wasn't there in the talk. I'm at these conferences always, but in this room. Right now, you are missing a talk as well. No! You only have so much time. And we only do what we can. So hopefully.
.. Well, the video is available. Mo is putting the video out within 24 hours. Yes. That's what I typically do.
I'm the last one to see all the conference videos. I have to hear bits and pieces from everybody at the show. But it's nice to get reviews on who did what before it comes out. Sure. I know where to focus my attention. Well, Paul, it was wonderful to meet you and to interview you.
Is there anything else you want to say to the audience? Where can they learn more about Factom? You can go to the Factom.org. From there, you can find our white paper. From there you can find the consensus paper that we've released for review. You can find the links to the Gutenberg demo. And you can find the explorer that lets you look at the records that were entered and see how it works.
The A.P.I. is documented. If you're a developer, you can play with that. And of course, you can find contact information to us.
It's been a long morning for him. Yes, yes, yes. He woke up early and went to bed late. Yeah, yeah. Typical conference. Up late.
Up early. So you can find basically everything you want. And contact us if you have a great idea. We will do what we can. We are not looking to build solutions. We're building a platform to enable solutions.
Paul, it was great. Thank you. Thank you for your time.