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

What I would like to know:

If Factom speaks with potential customers, what are the biggest concerns of them, or maybe the "highest barriers" that they use it?

And, more the opposite: Which business-sector is most interested in using Factom and why?

Not particular to him, more to Factom in general: Do you have any hopes or whishes or desires about what could be done by the community at the current state and with M2 (when? WHEN? )?

Do you guys have any questions you would like Paul to answer on the crypto show tonight?

Well, while I don't agree on the solved problem part, I don't see a problem in the future IF the safenetwork will work as intended
I think that was what I was aiming at (in hindsight), because imho both technologies will complement each other quite well.

Thanks for your insights!

I like to say that factom is for securing and indexing data.

There are other things that you can do with data.  You can store it and you can serve it up.

Data storage in today's world is mostly a solved problem.  It is sitting on some hard drive or on some backup tape, or in someone's email inbox.  Finding the data that you need is the hard part, which is also part of the serving the data.  Someone needs to pay for a computer to be online and ready to hand you any data that you ask for within a few milliseconds.  This is much harder than having it available if and when needed with a few days of lead time. 

Knowing where to look is hard, and knowing if you found the right thing is even harder in today's world.  This is what we are trying to fix.


Think of a newspaper.  When something is published, the news gets widely distributed.  A year later, the newspaper will be harder to get ahold of.  You can't just go down to the corner store and pay a quarter and get a copy anymore.  This is analogous to the serving of the data getting harder.  If you need to get a copy, there are still organizations that retain that newspaper.  You can go down to the library and get old newspaper copies.  For even older newspapers, they have microfiche, which is a more awkward way to get the data.

Some people collect newspaper clippings.  Those clippings are subsets of the entire news system, but are individual proofs that something happened.  By it being on special paper, that makes it hard to forge, and if someone did forge a newspaper clipping, others could prove the negative by going to the library and showing that the clipping does not show up in the authoritative copy on the specified day.

newspaper clippings are like saving the merkle paths.  They prove the positive, but cannot prove the negative.  Public notices are a way to prove that the public was warned about something.  a clipping can prove the notice happened.  Conversely the entire history of publications is needed to show that a notice did not happen.  https://en.wikipedia.org/wiki/Public_notice



>the data is not guaranteed to be stored - so what is the reason to try to store hashes or anything with FCT, if it just may disappear ?

If you wanted a 10 year old newspaper, and went to the newspaper company, would you be terribly surprised if they did not have one available for you?

Lets go further and say that the newspaper company was bought out by a ne'er-do-well.  The newspaper companies new management is incapable of recalling the old newspapers in all the libraries around the world.  They can print new copies that rewrite history if you buy an updated reprinted historical edition at their new headquarters, but it can be proved that they changed history, because the copies in the libraries still exist.



Apologies if this example seems rushed, because it is.


>would the company be able to "restore" their data (the proofs) regardless?

This is why you would run a full factomd node.  It has all the data captured by factom and can generate all proofs.  If you absolutely need to have the data in the future, just store it yourself.  It self validates against bitcoin, so your counterparties do not need to trust your data integrity procedures.


>The actual data is stored by the companies as it is currently in their datacenters.

If the data is small enough (<10Kib) and needs to be public, it can go directly into an Entry.  Most entries, though will be securing private data I suspect though, so yes, just signed hashes with metadata.


ps. bitcoin does not promise to store things forever either.

http://bitcoin.stackexchange.com/questions/2983/is-pruning-transaction-history-implemented-in-satoshis-bitcoin-client


also, https://medium.com/@BrianDeery/i-love-negative-feedback-632f8ee780ff  for those just joining us.

hi
Factom is perfectly doing what it suppose to do,more EC less factoids in circulation means in a long run we are going to make a decent ROI
we all know beggining of Bitcoin.
 "There is a saying that when a genius points at the moon, a fool looks at the finger.
have a great life guys.

Yep, and looks like usage is continuing to grow:

docs.google.com/spreadsheets/d/1RUZLxxoAfT3C5jIJ144DLYdztYe_sqrKqbTlZuD05-s/edit?pref=2&pli=1#gid=445871101

On the plus side the lower the price the more factoids are burned the more the supply is reduced.

Thanks for explaining! I get it now, I think. Makes sense. Pretty interesting stuff.

Paul is working hard, even today on sunday: https://github.com/PaulSnow?tab=activity

Looks like the last commits were just minor tweaks and no more fundamentals or critical bug fixing.

+1
This reminds me of a book I read called "The Legacy of Chernobyl" by Zhores Medvedev.
With Factom, one of the greatest Peacetime Nuclear Disasters could, conceivably, be prevented.

(From memory, so details will be off) In Chernobyl, they left in hot radioactive material in the reactors at the end of the year cycle. This was against regulations, and dangerous.

This was what started the meltdown. The reason it happened is in the Soviet system, the inspectors and Plant operators basically belonged to the same company - the government. And they both got a big fat bonus if all was well at the end of cycle. So, the inspectors overlooked the problem - so they could get paid as well.

How would factom affect this? If they had to hash the data? Im not sure.
Lets see... either
1)
A) at the time of inspection, they could fudge the data from the start so factom wouldn't affect it.
B) Factomizing data would prevent dishonesty here somehow (chime in guys?)

~OR~

2)
They would have to be honest because all the data leading up to the inspection was hashed so an impartial investigator would know they were lying if they said all was A-OK from whatever metrics they collect throughout the year.

Haha that's hilarious, the troll-box never ceases to amaze me.

But then again it could explain the major 500+BTC sell offs....

Ahh, I doubt it's real and only a rumor used to spread FUD.

I'm guessing you longed xmr on the peak. Bad luck.

Smart move would be to sell before this drops further. Get in on XMR while its under 2MILL SAT. Wont be there for much longer.

This guys makes us great favour they will stay out of the game. Let them dump it.

No worries. Lies in the trollbox are part of the daily game and nearly nobody will believe it.

And most of the talking there is positive: http://www.polonibox.com/?messageText=factom

Someone is spreading rumours in the polo trollbox that factom is bankrupt. That doesn't really help our cause. Can we have a factom representative point out they've just raised 6 million in funding and are doing fine?

Imagine a security-camera in a Hotel-lobby. It takes 24 photos per second (or something like that) and all photos are stored on the server of the security-company.

The security-company uses Factom to hash the film-material - each single photo. It also hashes log-ins of the accounts of employees. All is hashed into Factom on an own chain for that company, plus: timestamped and anchored into the Bitcoin-Blockchain.

Important is: The actual data is stored on servers of the security-company - not in Factom. They only store hashes of each photo on the

Let's say the film-recordings play a role in a lawsuit. The security-company is able to proof that they have the whole material - no photo is missing, no file was altered and they also can proof that the time-stamp is correct.

If that wouldn't be the case, let's say the film-material was manipulated --> the files wouldn't match anymore to the hashes.

If photos were deleted --> there would be timestamped hashes in Factom while the real data is missing.

And because the security company also hashes log-ins of employee-accounts into Factom it would be possible to find out who was responsible and what he did and when.

And those Entries are stored on several Factom-servers. While the server of the security-company is a single-point of failure, because a corrupted employee could mess with the data or it could be hacked, it's near to impossible to do that with the decentralized federated servers of Factom. And even if: After 10 minutes it's in the Bitcoin-Blockchain.


But: The Factom server don't necessarily provide Entry Credits. They are paid with Factoids from the protocol for their work. Entry Credits are created through a transaction from Factoids to an Entry-Credit-Adress. The security-company could pay somebody (an EC-store, maybe somebody who runs a Factom-Server) with $x  to purchase Entry Credits. The EC-Store-Owner sends Factoids (matching the $ amount - dependent on the current FCT-price) to the EC-Adress of the security-company.

- The security company gets Entry Credits for Dollar
- The converted Factoids are out of the system - burned/destroyed


Or to make it easier: Let's say one of your friends wants to hash a lot of important documents into Factom but he doesn't have an account on Poloniex to buy Factoids. He could give you cash and you could make a transaction from your Factoid-address to his Entry-Credit-Address. Or he could be the Factom-EC-store and they would send him Factoids on his EC-Address. If I would want to do it I would send from my Factoid address to my EC-address.

What I want to say with that, because some don't understand that: In all possible ways of purchasing EC's, FCT's are converted into EC's and burned through that process.

Nope, it doesn't work this way. The actual data is stored by the companies as it is currently in their datacenters. With factom they create a merkle tree of this data or hashes of each file (as they like and dependent on use case) and store it in the factom blockchain. If they do it in regular intervals, they have a proofable hashed history of their data. This can be used to either check the integrity of the current data, or to audit the status of data back in history.

I suggest to have a look at the documentation for further details: https://github.com/FactomProject/FactomDocs

Hi! I think I just realised how FCT, EC and fiat will correlate, and its very fascinating!
But what I still don't understand is the data storage thing. Please correct me if I'm wrong.
These entries are stored on one of the Servers that provide the EC credits, right? They store the actual data, and only store a hash on the blockchain to be able to proof what you mentioned above. If say, a company was to change some of the data or added new data, it would be stored on the EC server, right? So what if, for some reason, all of the data on the EC servers (including Factom) were to be destroyed, would the company be able to "restore" their data (the proofs) regardless?

#edit
I would assume they could, because they could calculate everything from the hashes on the blockchain. But I'm not 100% percent sure. cheers!

thanks!