Topic: [ANN] FACTOM - Introducing Honesty to Record-Keeping - page 468. (Read 2115931 times)

Yes that's right, we are looking to integrate when both projects are able to scale up and nearing their respective public launches.

Storj doesn't believe in competition between different projects but in collaboration and integration. Ethereum, Factom, Maidsafe, etc, try to solve a different problem, each one its own, so for true decentralization (not only for cloud storage) there needs to be cooperation between all these very good ideas. Storj itself tries to be as modular as possible so it can be adapted to work with other parties.

Yesterday shawn(super3) was talking about possibly using factom to verify data on storj network

As CreationLayer mentioned above, if you see how Factom could fit well within your business, project or idea we will be happy to expand on it.
We already have numerous use cases and you will see them explained soon in more of our videos on our YouTube channel.
Businesses, other projects and even governments are approaching us to discuss their plans.

If you would like your idea to be featured in a video with Factom join the discussion below or email us at [email protected].
We are looking forward to hear from you.    

I'll do my best to answer this.

Factom will be launching a Factom token, tentatively called factoids. This will help fund initial development, and allow users access to the Factom servers. The tokens ensure use of the system is fair, and help support the ecosystem of nodes.

In addition, the Factom team will be assisting businesses get setup with Factom. If a business has specific needs, the team can help integrate and get them up to speed with using the service on the blockchain. Since a number of businesses have expressed interest but need additional help, the Factom team will be able to provide services, and contribute back to the project if a request leads to additional development. In some cases for more intense integrations, the team may request compensation, as many businesses or other entities are interested in using blockchain technology, but don't have an onsite staff to quickly implement. Of course anyone could offer integration services, and determine compensation. Factom will take a direct focus on larger impactful projects.

factom. a simple yet necessary system that enables off blockchain distributed algorithms to be secured by bitcoins pow? I like. +++

Thanks for your reply.
What is the business model of Factom?

Thanks for the ideas, @everyone keep them coming. 

Systems that need to:

- prove a process
- prove existence of something (historical fact checks for example)
- prove the record exists (for auditing, but different than above)

I could see this being useful as an intermediate hash table sitting inbetween a front end web application, and a BPO system http://en.wikipedia.org/wiki/Business_process_outsourcing

In terms of consumer oriented use cases, I think the appeal would be privacy as some transactions may not want to be broadcasted on the Bitcoin Blockchain - the ability for Factom to encode transactions offchain would mean that this can act like a dark pool

@delulo


it would be more accurate to say that they are secured by the bitcoin blockchain.  Not all the data that Factom collects is recorded in the blockchain.  You are mostly correct about dealing with Bitcoin rules.  It depends on how much confidence your application needs.  if you want to double check everything that Factom is doing, then verifying it all the way to the blockchain would give you confidence Factom is not misbehaving.  This is similar to Bitcoin, where you can either run a full node, checking all the miner's work, or using a lite client on your phone.  it depends on how secure you need to be. 

I suspect that a majority of people will use lite clients like they do in Bitcoin.  This would mean they only needed to deal with the Factom API.  Initially, we are planning on having a program that runs on your computer which acts as an interface between a web services API and the Factom network.  This means that we can continue to update the p2p network while the api calls your application uses stays the same.


It is more federated than centralized.  I believe it is like NXT, where the server responsible for packaging transactions is known before a block is created, rather than like Bitcoin, where the transaction packager is known after the fact.  Since the network knows who is supposed to do the packaging, an acknowledgement from them is like having a promise from a Bitcoin miner.  There is a continuum of confidence as time goes on.  see#3: https://bitcointalksearch.org/topic/m.9754449

Storj use cases for Factom

Storj - Decentralized Cloud Storage
Storj has some pretty interesting use cases for Factom as part of a Group of Verification Nodes (GVNs) that manage heartbeats and payments for their cloud storage platform. Clients will need a trustless method to audit heartbeats and payments for farmers using DriveShare, who earn Storjcoin X for leasing their storage. End-users or third-party apps and tools using MetaDisk or its API, who pay for storage, need to be guaranteed files are retrievable and maintain their set redundancy over the network.

Another use could be to record files metadata and the network location of their shards (smaller chunks) into a single hash. This drastically reduces the amount of data to be stored on the blockchain as well as enabling faster throughput. In turn this could help Storj scale up their network to thousands of users in a secure, trustless and reliable way.

An example: Surveillance Records
CCTV footage and photos could be proven to have existed in their original and unmodified form at a certain time by using Factom. Storj on the other end could keep these assets safe and secure on their cloud platform in their original and unmodified state. A front-end app could leverage both platforms to provide irrefutable evidence during a justice proceeding for instance.

Working on a project and need a system of records? Factom is here to help. Introduce us to your use case.

Factom is a simple extension of the Bitcoin blockchain that lets you build faster, cost effective applications.
Factom is a system for securing millions of realtime records in the blockchain with a single hash. This gives you the tools to build applications with all of the security of the blockchain without the speed, cost, or size limitations. The blockchain opens tremendous possibilities to bring honesty to all systems. And Factom creates tools to build on top of it.

• What is Factom? Watch our explainer video: http://youtu.be/YBXNLW-YvoA
• Read our whitepaper: https://github.com/FactomProject/FactomDocs/raw/master/Factom_Whitepaper.pdf
• Test our Factom API: https://github.com/FactomProject/FactomDocs/blob/master/FactomAPI.pdf
• Factom Use Case - Saving BoA $17 Billion: http://youtu.be/DbRVPBFiy64

Are you working on a project and need a system of records? Introduce your project to us, we are looking for use cases and integrating our Open Source code and API with as many ideas as possible.

Getting place! Maybe I will invest! looks crazy!

I discovered this project on storj forums and I am very interested on it, I will follow close.

Is Factom designed to have some kind of coin distribution / fundraiser / initial mining? I could have found out I guess by reading the whitepaper but maybe you can give me a short version

Would the following summary about Factom be about correct? Factum lets you create ledgers that are periodically recorded in the Bitcoin blochchain. The developer only has to deal with the rules / API of the factom ledger(s) and not with Bitcoin itself. Also the centralized handling of the Factom ledgers makes "confirmation" fast. This might be pretty wrong since I just read the wsj article. But please enlighten me if it is.

Here are some thoughts that came from a different channel I thought were worth sharing:

Factom is more about record-keeping than storing data.

We are trying to give users the irreversibility of the Bitcoin blockchain without having every transaction in Bitcoin.  We are trying to make a system which is both censorship resistant as well as spam resistant.  The two are diametrically opposed.  Bitcoin itself is trying to achieve both of these as well. 

Bitcoin is a big complex system which boils down to the world agreeing on a UTXO set.  It is a big datastructure to see if money has been sent to someone else first. 

Bitcoin proves the negative (that money hasn't been spent earlier).  A BTC receiver must have the entire UTXO set to prove that negative.  (There may be more optimizations later, with patricia-merkle trees, etc, but the miners need the entire UTXO.  Also, light clients can trust miners, but I digress.)

Factom is trying to generalize the proof of the negative.

Factom is also a big complex system to let the world agree on a data set.  Factom takes disparate sets of data, and classifies them into buckets.  These buckets, which we call Chains, and have user specified IDs.  The idea is that all of the data relevant to an application is tagged and placed into the correct buckets.  For an application to prove a negative, it needs to download and verify only the data in its Chains.  If the data is not included in the Chain, it can be assumed not to exist.  This is very similar to how a bitcoin can be assumed not to have been spent if it is not included in a block.


The intent is to not store large pieces of data.  we are trying to discourage that by setting the pricing for other services to be more attractive. 

The data is shared on a Distributed Hash Table, so a user could reshare out the data which they are interested in, but not store data for other's uninteresting applications.

The storing of the bulk data in storj or maidsafe is what we had in mind too.  One of the problems with storing in storj, though is someone needs to keep paying a maintenance fee.

DanSmith:

The magic of having the DHT, though is that subsets of the data can be shared independently.  The bank itself could spool up many copies of its data if it needed to share it in a distributed fashion.  A potential auditor knowing they might need the data in the future could collect it in real time.  If the network were attacked, the proof would still be rooted in Bitcoin.

One mitigation to your attack would be for the federated servers to share different subsets of the data on different IPs.

I do envision different availabilities for different datasets.  Popular datasets will be massively shared, and niche ones would be harder to get.  In the distant future, it may even come to a point where payment is required to download rare data.  Businesses would sell this historical data which doesn't have altruists sharing it.


What I worry more about is sibyl attacks on the DHT routing table.  If you only get lies as to where you can find your data, then you are out of luck.  I have read about ISPs sibyl attacking their customer's bittorrent connections, but those were more to force their customers to share amongst themselves, instead of over the ISP's peering connections.  There is a lot of research being done finding how to burn through DHT sibyl attacks, but it is indeed a complex problem.


Running Federated servers over tor will not likely work, mostly because of the bandwidth.  The federated servers need to have low latency to turn the data around.  It is a flood fill network, so every full node needs to see all Entries, plus 3 packets with assorted signatures covering that Entry.  The federated servers come to consensus every minute.

well... now that I think about it, only a majority is needed for consensus.  One of the federated servers could listen over clearnet, pretending to be a non-authoritative full node.  Its signed transactions could be broadcast through Tor.  only 2 sigs of hashes would go through Tor for every Entry.  If they take too long to broadcast consensus, then the rest of the network can quickly come to consensus without them.  Timing attacks from their peers are still possible to find them, though.  we do have heartbeats that are needed from every federated server to show the rest of the network they are still alive.  this may be hampered by tor's latency.  maybe the heartbeats can be sent over multiple tor routes to decrease the chance of one getting lost. 

Bitcoin bans spamming peers, but that wouldn't work over tor.  a full node deciding to listen on tor would just have to eat all the DOS traffic, since it couldn't ban an IP. 

Sharing data over Tor after the fact will work much better, since latency and bandwidth are less critical.  a tor node can insert itself into the DHT routing table, and offer up contraband data.

Lots to think about with Factom and Tor.  Bitcoin's flood fill network has some of the properties of tor, since peers don't know if a new transaction originated from that peer.  Factom's network is probably closer to the streamtorrent system.  It would be interesting to see how traceable that network is.

Apologies for the rambling response to your post. 

Factom Presentation at the Seattle Bitcoin Meetup

Checkout the video below and more on our YouTube channel.

Thanks, that's an interesting video about BoA's 10 bill.docs.
I was prompted to this thought:
32-byte hashes of 10 bil. docs add up to 300GB of storage. That's for only one bank.
Eventually, only the Federated servers (FSs) will be able to store the whole DHT.
The attacker can query DHT to learn a unique subset of nodes which store all data, i.e FSs.

Then the attacker can mount a botnet DDOS attack on those FSs.
This attack will not grind Factom to a halt, it will only prevent FSs from serving legitimate customers which require the unique data stored by FSs.
Of course, having FSs running as Tor services would mitigate a DDOS attack.

Factom Use Case - Saving BoA $17 Billion

Click below to view on our YouTube channel.

What is Factom?

The first explainer video now available on our YouTube channel! Click below to view.