Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Paul Snow & Peter Kirby: Factom – Proof of Existance, Proof of Process, Proof of Audit

Episode Date: November 10, 2014

Today’s episode is all about Factom, an open source project which aims to solve three core problems which apply to all Bitcoin 2.0 applications: Speed, Cost, and Bloat. Rather than writing every transaction to the blockchain, Factom allows decentralized applications to write blocks of transactions to Factom blocks, which themselves get hashed and stored to the bitcoin blockchain. At its core, Factom provides Proof of Existance, which allows for any digital artifact to be reduced to a hash that proves that artifact’s existance at a specific point in time. We are joined by Factom CEO, Paul Snow, and President, Peter Kirby, to explore the different applications of Factom as well as the technical workings of this very interesting and promissing project. Episode links: Factom Factom White Paper This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/052

This episode of Epicenter Bitcoin is brought to you by Fairlay. Fairlay is a Bitcoin prediction market where you can place predictions on the likelihood of sporting events, the Bitcoin price, or current affairs. You earn money if your predictions are correct. Head over to Fairlay.com slash epicenter, that's F-A-R-L-A-Y.com slash epicenter to place your first bet today. Hello, welcome to Epicenter Bitcoin, the show which talks about the technologies, projects, and startups driving decentralization and the global cryptocurrency revolution.

My name is Sebastian Couture. And my name is Brian Parmen Crane. We're here today with Peter Kirby and Paul Snow. Peter is the president of Factum. He also started a PVSA Consumer Goods Company and was also working for Coin Terra, the mining company. Paul Snow, I saw the first time a really cool video of him wearing his Texan cowboy hat and inviting everyone to come to Texas when we were organizing a hackathon here in Berlin that was leading before the Texas Bitcoin Conference.

Now, we're here today to talk about Factum. So perhaps let's have you guys introduce yourself briefly and talk a bit about sort of the big picture of Factum because it's a complex project. Paul, do you want to go first? Certainly. My name is Paul Snow. I'm a long-time programmer. I worked on PostScript back when PostScript was the big thing,

and I implemented some Post-Fix programming languages with some other people at the dawn of time. Also worked on the Texas Tears project, building a rules engine that processes eligibility for health and human services programs. And now got into the Bitcoin space, organized the Texas Bitcoin Conference, which will have another conference in March, the 28th and the 29th. And I got involved with Factam and designed this system for creating arbitrary immutable ledgers. Fantastic. My name's Peter Kirby. This is my sixth startup. I began my career in the real estate world and ran a real estate and mortgage and a development company.

Later, I started a consumer product company, and I was also one of the early people at Quintara. Did, Jesus, everything that was business there for a while. I've been in the Bitcoin space for just about two years. and I joined FACTM in September, just basically at the inception, when it went from being an idea to a company. Fantastic. So I guess we can start off by going over the sort of big picture. And in broad strokes, Paul, if you could explain to us, what is Factam? And then what are the goals that FACCUM is trying to accomplish? Well, FACTM is a layer that will...

layover Bitcoin and use and leverage the blockchain to allow clients using Factum to create arbitrary ledgers. And by arbitrary ledgers, I mean a ledger that has the information in it that is useful to the client's application. That could be exchanges of value the way Bitcoin exchanges value or cost. or Mastercoin, but it could just as easily be logs of information, hashes of data that verifies and validates the state of that data at a point in time and gives you a sequence of data points so that you can essentially create cryptographic audits of business processes.

So Factum is basically this general purpose thing that allows you to record and document pretty much anything. Yeah, just to build on what Paul said and simplify pretty quickly, the blockchain provides an incredible, permanent accounting ledger that you can build cool stuff on top of. And Facton provides a layer on top of that that allows you to build applications that are fast and cheap and actually, you know, don't blow up the blockchain. Yeah. So can you tell us a bit? Is that the primary motivation is it to avoid Bitcoin blockchain bloat? You also feel this is more, it's a better way to do it, a more efficient way?

Yeah. I mean, what I was looking at with Factum is there are many, many Bitcoin 2.0 applications. And those Bitcoin 2.0 applications get stifled because the first thing they have to do is create their own blockchain. Or they have to try to encode their information into Bitcoin transactions. And either mechanism provides a layer of complexity that is above and beyond the actual goal of that application. So if somebody, for instance, wants to trade gold and thus they go out and they try to create a gold currency, and then they perhaps if they are creating their own coin, they're recruiting miners. If they're not creating their own coin and they're using some of the protocols that run on top of Bitcoin like Mastercoin or Counterparty or Color coins,

then they are restricted to what they can record in a Bitcoin transaction. We are looking at the transaction volume going up and beginning to bump that one megabyte block limit. Certainly, Bitcoin is going to address those problems and perhaps increase the block size or raise transaction fees to limit the number of transactions. that occur. But that's a lot of complexity for someone just trying to build something to trade gold to have to deal with. If they had an immutable ledger, they can define their ownership via digital signatures, and then they just need to have the record of the transfers. And from that record of the transfers, then they can determine the ownership.

And they're done. So FACTum seeks to essentially enable all those applications by taking on the complexity of how you create immutable ledgers and how you use Bitcoin to secure them. Yeah, I thought it was very elegant and then we will go into more detail later about how exactly it works. But I thought it was very elegant in how it sort of does away with all that and kind of uses the security of the blockchain. without sort of having to try to either squeeze in by using transactions in a weird way or building some sort of complicated layer on top, it seems to be a very sort of clean and simple solution. Well, moderately simple.

It's still a very complex project. Perhaps we can move to some examples of where do you think this will be most used for? So let me go ahead and take that. Yeah, there's a whole lot of things that you can do with factum that are really exciting. Basically, all business processes have a system of record problem. And those system of record problems cost them awful lot of money. So, for example, Bank of America recently paid $17 billion for the mortgage scandal that involved robocining.

And what happened was they basically lost track of the system of record. That mortgage was issued by some small mortgage broker that transferred it to countrywide. They transferred it to some Wall Street bank that packaged it up into some big credit debt obligation package. And then the mortgage got transferred, et cetera, et cetera. And along the line, the people who own this mortgage, you know, sort of lost track of that record. And what that led to is them foreclosing on people's houses and not recording payments correctly and all sorts of, you know, really horrible stuff. So in a factum world, a company like Bank of America could record that mortgage and basically date stamp at that moment in time, every single record that went into it. You know, there's probably a thousand pages in a mortgage and prove that that existed exactly as it was at that state of time.

And then moving forward, every payment could be recorded. If there was a foreclosure situation, they could record every piece of court documentation and prove that they had that entire record from start to finish. And then, you know, when somebody went to contest a foreclosure, they could prove that it happened or they could also prove the people who got foreclosed on could prove that Bank of America didn't have that document and they couldn't go back and sign it later after the fact. So in that situation, Bank of America would have had the entire record and not, you know, been liable for that very, very, very large fine. So in a fact world, business processes can be 100% honest, which is really a good. exciting. Can I add something to that? I mean, it should be clear that when you record a hash of a document into a factum chain into a ledger that a bank or someone like that is creating, that hash means nothing to anyone looking at that list, you know, because factum is very much like Bitcoin.

It's a publicly auditable chain. It's just that in this public ledger, there would just simply be some hashes. But when I took those documents and I hashed them and compared them to the hash that's in the Bitcoin blockchain, then those fingerprints, which are very, that are, for all practical purposes, unique to every document.

When they match, I know I had that document at that point in time. And so you have both privacy as well as, security and an immutable ledger. So I guess that solves the problem of proof of ownership of a document at some point in time, but how does it address the actual ownership of the document and record keeping of that document? Does it or would you have to rely on some other technology to do that? Well, your biggest problem that you have in these situations is that the system of record, As long as the system of record exists, then you can always go to the system of record and validate and verify the information.

And that's essentially the system we use today. Different banks and different institutions have their own system of record. But after 2008, we had this failure of one institution after another. And so there were all kinds of holes in terms of missing systems of record that had to exist in order to document. these mortgages. Now, in the factum world, if those organizations had been digitally signing the data, then that data could be moved along from one system to the next. But when you went to validate it, you wouldn't have to validate that, you know, it wouldn't be your system of record saying that the data is valid. You would be able to go back to that hash that's been recorded

that basically those other systems that may not exist now, that they went on record. saying this was the data at that time. So you're able to ensure that you have all the data and you're able to ensure that all the data is still valid as it was recorded by the institutions at that time, even if those institutions go away. And that's the real key. That's what cleans this up.

So if I could just sort of play out what this would look like, I presume this means that a bank would have its software, right? where you save documents in, maybe a loan application, and then maybe a feature of that software would be that it at the same time takes that data and takes those documents and it sort of enters it into factum to prove that ownership, right? And then I guess later when someone could go and it rely on that to have a sort of objective outside verification. Yeah, exactly, exactly. the bank can prove that anything existed without, without, you know, with a true third-party verification the system.

So like it's, as Paul says, it's immutable. Like, nobody can change it. It's cemented in the past. Which, like I said, turns out to be. Is anybody working on? Yeah, I'm curious, because a lot of people, right, when we talk about Bitcoin 2.0 protocols, you talk about these possibilities in the abstract, right? We're building this sort of infrastructure thing and then people will build, the expectation

is people will build things on top of it. Yeah. This being one of them. And it's certainly an interesting use case that I hadn't heard of so much before. So are there already people, you know, who are working on using factum like that? because I think you guys won't be the ones doing that, or are you planning on doing those kind of things as well? No, that's absolutely correct.

The goal of fact that is to build a protocol layer and let people build interesting applications on top. So, for example, the details of this are still a little bit private, but country reach out to us. They've got a major problem with titles, you know, their title records, proving who owns what piece of property. And they basically are looking for a blocker, solution to their title problem because if you put a title in the blockchain, there's no way that somebody can go later on and fake that that title was transferred in a way that wasn't true.

So they reached out to us and what we'll probably do is work with a third-party application developer or whoever runs their current title applications and then build a fact and back end to it. So every time that title gets recorded, it also gets recorded in the blockchain. So this is probably going to be the model moving forward with FACTom. People will approach us with a problem, a system of record problem, and we will have a series of technological partners that we can help, you know, sort of we run the back end for it, and they run the sort of application layer. So essentially Factam provides an API where any developer can plug into

and use the protocol. Yeah, absolutely. And build apps on top of that. So this is one example of how Factum can be used in a corporate setting. What are some of the ways that this can benefit just regular people? I mean, so just for context, the prior version of Factum was called a notary coin or the notary chains. Notary chain, sorry rather.

So is the idea to sort of replace notary services? Well, you can certainly use FACTOM as a notary service. For instance, an artist who is working on a song or music or anything like that can certainly take hashes of recordings that they're making and recorded in a FACTOM chain. Again, it would reveal nothing to anyone looking at FACTM from the outside. But at any point in time when there was a challenge, did you write this song, they would certainly be able to bring, you know, provide the earliest proof of recording of that artwork or that song. So there's some of that kind of copyright and

rights protection that you could use FACTM for. You could also use FACTOM as a mechanism for messaging in a way that is undeniable as well. And you can use a system of revealed secrets that allow essentially relatively anonymous messaging yet fixed at a point in time. Anywhere where somebody wants proof that they had this concept or idea first and they want, that record. There are a lot of very interesting use cases that come into play when you're talking about immutable ledgers and revealed secrets that users can use to protect both their privacy as well as just simply being more useful than other tools that we have.

I guess one other, maybe one other example, and We're talking about this before the show with Brian and I is if you'd want to sort of store and a document, you could use, you know, cloud storage, decentralized cloud storage services like storage or made safe and integrate, factum into that somehow. So you would have like a document that would live in the cloud forever and also be, cryptographically proven that it was created a certain date in Factum? That's right. Factum could actually act as a directory service and a timestamp service for technologies like

just general torrents, storage, Storj, and Madesafe. Made Safe and StorJ don't intend to maintain timestamps and hashes. So Factum can do that. You would also be able to use Factum to certify releases of software because you can have a Factum chain that's keeping the hashes of that software at that point in time going forward. And then somebody taking that software could check it against these known chains for their validity to ensure that no one's inserting malware into the source.

And a lot of those kinds of applications. So what are the use cases that maybe for each of you, what is the one use case that you find the most fascinating? Well, the one that really excites me is recently there was a giant oil spill that British petroleum was participated in in the Gulf of Mexico, which is really close to a hometown because we're in Austin, Texas. And what happened there was there was a whole series of contractors and subcontractors and sub-subcontractors. And each one of them was sort of keeping track of what they said they did and not necessarily keeping track of what they didn't do. So there was a major system of record problem. And when a subcontractor said they did something and didn't, and then the person above them said that they did it and, you know, that that that, that, that, that, that, the, that, the, that, the, that, you know, subcontractor finished that work, you know, eventually somewhere along the line, all those records

were not really 100% true. And what ended up happening was, you know, a giant explosion, a tremendous, you know, billions of gallons of oil released into the Gulf of Mexico, huge environmental disaster, because basically, like, people weren't doing what they said they did. And then when the court cases all came out, BP is stuck paying, I think it was like $43 billion in reparation, and various fines, because at the end of the day, they're the people holding the liability for this problem. So in a factum world where every subcontractor was documenting exactly what they did and recording it, and there was an audit system on top of that proving that they did what they said they did, you could go back and figure out not just who's at fault, but like what processes

broke down so next time we don't have problems like this. So in addition to, you know, a leaving BP of a tremendous amount of liability and, you know, sort of putting the finger on who's really to blame, you could also build better systems that evolve, right? You know, based on this system of record, we can see exactly what happened wrong and then, like, fix it in the future so we don't have the deeper horizon problems. That's what gets me really excited about FACTM. What about you, Paul? Well, I think that my goal with Factam is to simply create a system where we can inject honesty into systems that just aren't terribly honest. If I look at settlement for stocks and stock trading, or if you look at the banking and financial

system, if you look at insurance, any one of these or all of these areas, putting an end to the ability to backdate a record and putting an end to the ability to construct a history that an institution can prefer over what really happened will inject honesty into these systems. And I believe the more business processes that you make cryptographically auditable, the more honesty, you inject into the whole ecosystem. And I think more honesty makes a better world. Cool. That's fascinating. It's very interesting.

So we'll get to talk about the protocol, also the Factum token, and just the overall organization of the team in just a few minutes. But first, we'd like to talk about our sponsor, Fairleigh. Fairlay is a Bitcoin prediction market where you can place predictions on the likelihood of sporting events, the Bitcoin price or current affairs. and you earn money if your predictions are correct. So to place a bet on Fairleigh, you can go to Fairleigh.com slash epicenter. That's F-A-I-R-L-A-Y.com and place your first bet today.

So as we mentioned earlier, Factum is a protocol. It's a Bitcoin 2 protocol. And so can you explain at what level it sits? So perhaps we could start by saying that it's a Bitcoin 2.0 that sits right on top of Bitcoin. It's not built on top of some other platform like counterparty or MasterCoin, something like that. It does have its own chain. Can you go into detail about how that works? Yeah. The way Factum works is it uses a set of a consensus model and a set of federated servers in order to order and secure.

the information submitted to it by the users. And every 10 minutes, it creates a Merkel proof of the data that's in factum and places a entry pegging that data to the Bitcoin blockchain. So basically, you can go through the Bitcoin blockchain through history and look at the pegs and validate the Bitcoin. factum data that was collected all the way up to the last peg. And then in that time period following, Factum is securing those entries using a consensus model. So consensus for 10 minutes, and then you trust consensus for 10 minutes and then you trust Bitcoin forever. That's the basic

design goal of the protocol. A little more detail on the protocol. Every user can create their own chains, what we call a chain in factum. And it's a custom chain that they name and they create. And then they're able to put their entries in their chain. When you create a chain, you have the absolute right to put the first entry into that chain. And that gives you an opportunity to define the rules for that chain and define the process of auditing that chain. And that's important because Factum does not do any kind of vetting of entries. So once that chain is created and once that entry has been added, now anyone can put an entry in that chain.

However, when you run your audit against your chain, any invalid entries will be discarded and you can essentially create a client-side validated series of events. So if I take Bitcoin as kind of an example or any kind of coin transaction as an example, without the proper inputs and without the proper outputs and the proper signatures, the entry would be invalid. So you can place into a chain a series of valid entries and a series of invalid entries, but as you audit the chain and process it,

any invalid entries you'll just discard and leaving only the valid ones and be able to create a perfectly trustable chain of ownership. And the factum servers themselves wouldn't be in the position to create invalid transfers of value because your chain requires certain signatures and nobody outside of the people holding those private keys would be able to create transactions that were valid. So who then takes maybe the rules that were put in this first transaction in a chain

and writes, for example, the software that later goes and validates that? Does that the person that creates the chain and you then provide that to others or does everyone? Well, if you have the right to create the first entry, you have the right, you have the ability to put a hash of an audit program, a link to a website, a URL to some text that describes the rules for that chain. or it could even be a reference to another chain that's managing the versioning of the audit program for your value chain. So you could have a chain that's your audit chain and a chain that's your valid chain,

a value chain. And your value chain in the first entry would say, go to this audit chain to determine how to audit this value chain. And basically you can create these structures that basically reflect, you know, the real world. You know, because the real world's messy and requires updates and all that sort of thing. So you could also have a chain that allows the rules to be, the rules of validation to be changed at a later time, for example. Well, yes, you could. But all of that should be clear from that first entry.

If the rules for the chain should be fixed and non-changeable, then that's what the first entry should tell you. If the rules are changeable, then that's what the first entry should tell you. Or if the chain has to recognize certain authorities, like for instance, if the chain is supposed to manage the ownership of a car, it has to recognize the fact that cars can be repossessed by a court. no matter how much we would like the real world to require digital signatures for all exchanges of ownership, there in the real world some things exchange ownership simply because of losing a court battle or, you know, some other mechanism. So factum is supposed to be built so that you can draw the picture that you want to draw. there is no limits.

If you can imagine a set of rules, you can define them. That's fascinating. So in this case, could this be, I guess, in the future at some point, that the courts would be given some sort of private key that gives them a special ability to sign signature or that some authority would be defined initially that then would verify court documents or how would that work? Well, I think that this is what's going to happen. There's been a lot of news about how Bitcoin needs to conform to the regulatory environment that exist for the banking and financial world. And what Factum comes back and says, you know, cryptography provides a lot of tools to audit business processes in the real world.

So instead of saying Bitcoin needs to be regulated the way banks are, Factum says, hey, guess what? We can give government the tools to actually enforce the regulations they already have on the books by requiring businesses like banks and financial services to maintain cryptographic audits so that they can be responsible for what they do at the time they do it and not be able to hide behind their messy accounting practices. I see what you. I believe we call that a switcheroo. Oh, absolutely.

Absolutely. I think honest is a very subversive thing. Honesty is a very subversive thing. That's a good statement. I like that. That's interesting. It's fascinating. Now, there is one thing that I'd like to sort of understand a bit better is,

can you describe the server infrastructure? because factum doesn't have minors, correct? Right. So can you describe how that works? Okay, the users will all have public keys that they're using to put entries into factum. And when a user has essentially these entry rights tied to a public key, they can't be transferred in any way. And so other than to use them to put an entry in de facto. Well, those public keys can be used to vote towards servers that the user believes behave well and are good players.

All right. And the top servers in the network will be considered the federated servers. And those federated servers are responsible for running the key. consensus algorithm and the consensus algorithm simply records every entry that's submitted into factum into the proper chain and that is all they do. We seek to maintain a pretty high level of ignorance when it comes to the factum servers. In other words, they should simply scribe the entries they get without knowing what those entries mean or, or, or, you know, what the value of those entries are.

And that, of course, makes the servers a little more honest, even though I can't stop servers from knowing information that's publicly available. In order to keep them honest about what entries they place in the system, we separate the payment for the transaction from the actual submission of the data. So you submit or you commit the system with a hash of the entry with your public address, which says I'm paying for this entry. But since it's a hash, no one in the factum universe can tell what that entry means. They record it, and that now obligates them to record the entry. Then you do a reveal presenting the entry, and because the hash, you do a reveal, presenting the entry,

and because the hash matches what they've already promised place into factum, and because they now learn what chain that entry should be placed into, they are not in a position to censor the entry. They've already promised to put it in. If they don't put it in, all of the nodes looking can see the proper submission and see that it wasn't recorded. So, well, yeah, what keeps them from breaking their promise? Well, they can break it, but it'll be obvious. The other thing is that the responsibility for the chains, every minute shifts from one factum server to another. So even if one factum server tried to censor and not refuse to record the entry, the next factum server likely will. Unless you have collusion of all the factum servers, or then eventually the entry will be recorded.

because the responsibility for recording the entries shifts each minute from one factum server to the next. And all it would take is one honest factum server for your entry to get into the system. So what's still unclear to me is who chooses these servers and the economics, like who, how do they get paid for? Are we talking about like VPS servers? Like what type of servers are we talking about here? Well, these are the people that set up factum servers with the software that we provide. And the factum servers are chosen by election from the users who vote with the public keys that both hold entries to be spent into factum as well as a history of having spent entries into factum.

Both of these numbers are available in the system for tallying the weight. of that vote. So it's kind of like a proof of stake, but it is weighted towards the people actually using factum. And since, yeah, the users are the good guys. They're the ones recording entries. They're the ones that have most, most, a greatest interest in making sure that the servers are religiously recording every entry that they get. And then if I statistically look at the behavior of the servers, I can detect censorship. And one of the things we've learned from Bitcoin is when we realize that an entity, a pool, a mining pool is acting badly, those contributing to that pool will move because the value of Bitcoin requires the

mining pools to behave well. And so we're leveraging that same social aspect to allow the users to remove a server that isn't behaving well, remove support for that server. And the fact is that the system agrees to buy it before they, agrees to record the entry, before the system knows what the entry is. And that's actually a rather critical aspect to our design. So in the future, I suppose that there is some, human intervention in choosing the servers that will get, that users will vote on. Right. Okay.

In the future, could we imagine sort of a, I mean, if we can tie this in with Ethereum, for instance, imagine a scenario where the factum protocol is choosing servers based on data feeds and making decisions like price, speeds, and things like that, and that gets done automatically, and there's no human intervention required. I think that the users always need to have a say in the factum servers, because there are aspects of censorship that don't show up within the factum universe. Basically, I can automate in the protocol any decision where all the data is available in factum.

but I can't automate what is occurring outside of factum. And censorship is one of those things that occurs outside of factum. The only entities that can see an entry not being recorded will be the users of the system. So I think there will always be the users involved. Did I answer the question? Did I understand it correctly? At least having the option. Yes.

And I think we will want to implement as much automated controls as possible. That's absolutely true. And actually, there are certain missteps that servers can be guilty of, and they will be immediately dropped out of the server pool if those missteps occur. For instance, if they submit entries that aren't, that are not paid for. Entries that are not paid for cannot be submitted in de facto. And so all the other servers that are double-checking the work of a server

responsible for a particular chain, if they see an entry that isn't paid for that a server is trying to place into a chain, then that server immediately gets bounced out. Because that's some sign of an attack. Can we go a bit into talking about the factum token? What is the role of the factum token? How is it issued? Yes.

You know, what are the economics of that? Well, we're calling our factum token a factoid. And so the factoids will be issued with the crowd sale. And so the large body of them will be issued at that time. and then there will be rewards paid out, rewards not the right term. Yeah, it is, block rewards, to the servers for processing the data.

And there are fees involved in placing entries into Factum. But this is how that works, and it's rather an interesting design as well. Factum is targeted towards many organizations that may never want to have a wallet or a cryptocurrency. And so the solution there is to allow entities to sell entries into Factum by simply tying entry rights to a public key. Now all a industry or company that wants to put entries into Factum, but does it. doesn't want a currency or cryptocurrency, all they need are entry rights tied to a public key. So if they can go to a website and buy those entry rights using Bitcoin or using a credit

card or whatever, then they don't have to have a factum wallet or know anything about a factum coin. Well, the factum token allows that to be trivially executed because the factum token ends up in the hands of factum servers. The factum servers probably need to pay bills. So they're incentivized to have interfaces that allow people to buy entry rights. And they, when an individual, when a company goes to that website to buy an entry right, they pay the server, and then the server converts those factum tokens into entries. That's the only way you can get entries into factum is to convert your factum token into entries. So essentially the protocol pays factum tokens, the factoid's out to the servers for having run the servers. Then the servers

can buy the can sell entry rights by returning the factoid back to the protocol. Note that the factoid never went out into the wild. It was never sold for another cryptocurrency for, a dollar, so you avoid the whole issue of regulatory money service business or money transfer business because the server is never selling a transferable right to somebody else. They're only selling non-transferable rights, which essentially give access to the protocol to somebody else. So they can have a nice, clean business that doesn't fall foul to any regulatory problems. I mean, we want to make the blockchain technology.

accessible to business with no barriers. And the way to do that is to make sure that they can access it on their terms, however they want to access it, whether they want to pay with dollars or whether they want to pay with Bitcoin or they want to actually secure factoids out in the wild and buy their entries directly. Whatever path they want should be supported. So what is the business model for you guys then? Well, go ahead, Peter. This is your...

Yeah, yeah, absolutely. So the value of the total pool of factum tokens is based on how... It's based on the utility of it, right? The more people are using factum, the more valuable those tokens become. So this is a really interesting way to monetize open source software, where basically the factum entity is just a nonprofit. the initial crowd sale that we do, which is about 10% of those tokens, builds like an endowment for that nonprofit.

The nonprofit also reserves 10% of future factum tokens to pay out future developers. So we have a way to pay with some combination of cash and factum tokens, people who continue to work on this open source project. And then for all the people who were initially involved in all the people who participated in the crowd sale, the more useful factum becomes the more valuable their holdings in factum. So it turns out to be a wonderful ecosystem where you can align all of the incentives for all of the people who make factum successful, the users, the developers, the future developers, and the initial crowd sale participants.

So what happens, first of all, what happens with these other 80% or 90% and, and And when is the crowd sale, when is that going to happen? Let me answer that in reverse. So the crowd sale is planned for mid-February of 2015. So in a few months, we want to have the beta version of the factum system working prior to that crowd sale. So that's the most important thing for us. We want people to be able to both buy factum at a crowd sale and start developing right

away. The remaining two-thirds of those tokens are the ones that Paul was talking about that will continue to pay for the hardware backbone. The factum servers and the audit process will continue to get paid, sort of like an analog to mining, but they will run the hardware that runs the factum system and earn factum as a result of that. I have another question. So if there is a certain number of factoids, whatever it is. And are they divisible? Or what happens if the demand for that just explodes gigantically? Could you run out of factors? So a factum token will buy a certain number of entries into the system. And then when those entries get bought, that factum token, you know, essentially pays that factum server. So it gets recycled back in the system in a way that

you could never run out of factum tokens. Now, over time, as hardware gets faster and, you know, sort of competition builds for entries, the price of how many entries of factum token buys can increase. So it could start at 100 and then go to 1,000 and then go to 10,000 as it becomes more and more, you know, as the hardware becomes more efficient. So eventually the price of an entry goes down, but the number of factum tokens that are introduced into the system can stay, you know, fixed over the entire time,

or at least have a standard release of them to the audit servers. Ah, okay, I got answers. Because otherwise, you might run into the situation. You might run into a situation where you can only buy at least like a thousand at a time or something. But of course, if it's visible like Bitcoin, then you don't have that issue. We want to create a limited, you know, a scarcity of tokens so the value goes up, but we also don't want to hamstring the system at all because you can't buy what you need to.

Yeah, I think this makes a lot of sense, and it's such a fascinating model. Now, we're seeing it like again and again and again with like this way of having decentralized open source systems that can still be like really interesting businesses in this way. So, I mean, it's, of course, extremely similar in this way to Ethereum or storage or a lot of other projects in this area. Well, and our chairman, David Johnson, is one of the pioneers of this. sort of model for monetizing open source software. You'll know David because he was obviously involved in the made safe crowd sale and a couple of the other major ones. And he wrote a white paper all about how this new model allows you to build really wonderful open source software that solves a lot of major problems in the world and not have to rely on the venture capital model or an equity model

or a separate company that, you know, basically builds a consulting on top of it, you know, you can actually build value for the open source project. Yeah, we spent quite a bit of time describing that model with him last week, actually. And in a lot of ways, I think perhaps you fall within the framework of that DAPS white paper on the crowd sales side, but also, you know, being a non-profit foundation. Now, touching on that, can you sort of describe your organization? Yeah, absolutely. So as I mentioned, David Johnson is the chairman and Paul, who's on the other line is the CEO. Paul is also the sort of lead architect developer, you know, heading the code side.

I'm the president of the company. I do mostly the business development and, you know, fundraising and all that store. That's sort of everything that falls under business processes is sort of my jurisdiction. We have a team of five developers, a gentleman named Bo Wang and a gentleman named Jack Liu, who are Chinese coders. They live in Austin, lots and lots and lots of background. I think they have about 20 plus years of experience each. Brian Deary is our lead architect. He's helping Paul both write the white paper and rough out the overall architecture design. There's a new gentleman named Matthew Bing, who's just joined our team on Monday, and he'll be doing a lot of the server-related coding. And then we have a whole team of advisors, people like Stevens Brigg, who have a tremendous

amount of depth in security and blockchain technologies and other tools that we can sort of rely on to help us and help guide us on specific technical matters. So you mentioned that there was a crowd sale taking place in February. What's the time? timeline on development looking like right now? So there's basically four steps in the development cycle in our roadmap. The first one was getting that proof of existence piece right that was in place this summer. The next step was basically building the factum chains and making sure that every factum entry can basically talk to the other factum blocks so you can chain those records together.

We have that in place. They're building the APIs right now for that and that's going to be released in mid-November. along with that version 1.0 of the white paper that we're finalizing right now. So pretty soon, within the next few weeks, developers will actually get to play with factum using the API calls on a test server so they can sort of experiment with it

and start building the kinds of applications that they wanna develop for. In early 2015, it's probably looking like about January, we'll have in place the more beta version of it which is going to include the federated server model that Paul described, and also the tokenization mechanism like who gets what tokens and at what rate. So we'll release that in early 2015 prior to the crowd sale. Cool.

Great. Well, this is super fascinating. I'm really excited we've had you guys on because I think this is one of the most exciting projects, I think I've come across. Now, there's one question I want to ask about also partially for self-refer. reasons because I organized the big one meetup in Berlin and I'm giving a talk I'm giving a talk on Tuesday about side chains so I've been thinking a lot about that oh fantastic and I'm really curious what do you guys think um assuming side chains work out and they sort of live up to their

promise with that in any way effect factum uh no what's really cool about the way sidechance is building their project is that factum can lay right on top of those side chains just as easily. You know, Factum just writes hashes into a blockchain. So if it turns out that side chains evolves to be, you know, blockchains for, or, you know, side chains for specific functions and they want to run factum tools on top of those, piece of cake. Factum is blockchain agnostic. And in a similar sense, like if it turns out that Ethereum builds a really robust blockchain and people want to do interesting projects on top of that blockchain,

you can use FACTM for that too. So the tools that we're building fit really beautifully into the ecosystem as it evolves. But would you have to Ford Factam and have like, you know, a Factam Ethereum, a factum side chains, a factum Bitcoin, or could it be one Factam that sort of simultaneously runs on all those systems? You could write into the Facton Protocol to write to multiple blockchains, right, Paul? Yes. Well, the observation is that factum doesn't actually move value natively.

I mean, mostly it's an immutable ledger. And so it's the client that decides what to place into factum. And so if my proofs are running down into Bitcoin, that's fine. If the proofs are running down into Ethereum, that's fine. but factum itself doesn't interact with either. If the side chain protocol, when that's in place, we can actually create side chains that are running in factum. It may require us to add a little more code into our system to handle those chains differently

because we would have to have that chain conform to the, the specifications of side chains. But that would allow someone to actually move Bitcoin value into a factum chain where it could have expanded protocols built on Bitcoin and then have the Bitcoin value come back into Bitcoin. You know, so if Bitcoin moves into factum, it bounces around in factum, and then it moves back into the Bitcoin protocol. So basically, I think that side chains is an incredible opportunity for Factum. That's the way I look at it.

So in a sense, Factum could be a type of side chain almost. Yes, absolutely. Cool. I think David made a pretty strong point last week about the need for inoperability between all these different protocols. And perhaps when that inoperability begins really to be a sort of default feature in all these protocols, then we'll really start seeing a lot of interaction between them. Yeah, absolutely.

And to build on David's point, the more interactive all these protocols are, the more likely they are to be adopted, right? you know, we want to play with protocols that play nice in the same ecosystem. Yeah, I mean, one thing that he had mentioned that I hadn't really thought about earlier is, you know, the idea that we sort of see these protocols as being in competition with each other, when in fact they're not, they should be learning from each other. And if you think about it, I mean, we could imagine a future where, you know, you build an app or you build some piece of software, you build a service that uses multiple components.

You could be using factum for one thing. You could be using Ethereum for something else. You could be using counterparty or you could be using colored coins and have that all built into one piece of software. And the inoperability allows for value to move from one to another. Yeah, absolutely. And I think that's a really good way for the ecosystem to evolve. Everybody plays nicely together.

Yeah, before we wrap up, is there something else you guys want to briefly mention or talk about. We've really covered a lot and on the other hand we could go for another hour if you wanted to. There's a there are a lot of ramifications to the protocol and a lot of interactions and yeah we would encourage people to go to the factum.org and learn more about factum and there you go. And definitely read the white paper. We're also... Twice. Yeah, absolutely.

As I mentioned, on the 17th, we'll be releasing that version 1.0 of the white paper. Look at it, read it. We're open to feedback. It's not just open source, but it's also open development. So we're getting all the technical thought leaders and all of the really smart people that we know to read it, give us feedback, push back on some things. We want to make this a project that people are excited about developing on. and the first step is that they read that paper and they give us the feedback that we need to move it forward.

And where can people find the paper? That'll be on factum.org as of the 17th, and it's going to be in the GitHub repository also. Okay, so that's GitHub.com slash Factum Project. Now, just to be clear, there is another, I mean, there's a previous white paper called Notary Chains. Not to be confused with that paper. It is Factum Projects, and you find it there in the Facton. Yeah, correct. Yeah, correct.

And we'll be good to release. We'll make sure that all the rechanges. Totally cleaned out. Yeah. We'll also add it to the show notes at episode of Bitcoin.com. Fantastic. Yeah, and it comes out and we'll definitely speak about it. Well, thanks so much, guys, for joining us today.

That was super fascinating, really interesting. And I'm extremely excited to see how this turns out. And also look forward to reading the white paper again when it's kind of in a wrapped up, nice and clean form. So thanks so much. Fantastic. Thank you. We really appreciate the time. Thank you very much. Well, and thanks so much also to our listeners for listening. It was a pleasure as always.

If you want to follow us on Twitter, we're at Epicenter BTC. You can also subscribe to our newsletter, which goes out every Friday. And you can do that at episodeabitcom.com slash newsletter. You can also donate to us, Epcentabikwintercom.com slash tips. And leave us that iTunes through so people can find the show and let's know what we're doing well and we'll be still improved. So thanks so much and we'll be back next week. We'll actually will be doing, we will do the episode with Ariana Simpson of Bicco.

Right. So we've got Ariana Simpson and gems coming up in the next few weeks. So stay tuned on Twitter feed and also on our Google Plus page. We'll be announcing that there. Okay. Well, thanks so much and we'll be back next week. Have a wonderful day. Thanks again.

Thank you. Yeah, cool. Thanks, thanks guys. Thanks guys. You know,