Enterprise Level Client with Question

[Greg Forst]

a member of our team recently had a discussion with one of their enterprise level clients in the logistics and manufacturing space (can't be named at this time but have been in the news for blockchain) and this was their concern with Factom-

"if Factom takes off and other higher value transactions like mortgage documents are on that network it would increase the odds of it being hacked."

There’s obviously a lot wrong with this statement, but I wanted to get your input on a response (and also in general have us all aware of these types of questions, how to answer them, and how we can address this concern in marketing materials).

 

[Niels Klomp]

Copy and past of my Discord answer. Where Quintilian suggested you can store documents in Factom in between, hence the side step in answering your question:

[16:13] Niels: Please note that you never should put documents themselves on the Factom. You store signed fingerprints on Factom
[16:14] quintilian: (well you could @Niels)
[16:14] Niels: These are oneway hashes. A document has enough entropy
[16:14] Niels: Of course you can but it is bad
[16:14] Niels: You do not want documents on an immutable ledger
[16:14] Niels: (Yes I know luap is working on it)
[16:15] Niels: You can store basicaly anything on Factom if you'd like, since it is simple datastructures arround byte arrays. There is only a size limitation per entry. It doesn't mean you should store everything in it
[16:17] Niels: With everything you store on Factom, first and foremost you have to ask yourself what are the privacy and security implications of storing this information
[16:17] Niels: With Factom you are more or less forced to think about it. Better then having a random programmer starting on smart contracts and never thinking about it (gewijzigd)

 

[Xavier Chen]

The fear of "hack" can have two interpretations. The obvious one is the access issue which most people think about. But if we only store the hashes and not the actual actual data, the risk is minimal.

The second interpretation is privacy. In term of logistics and manufacturing, they might be just as concern about their proprietary information regarding their business operation being out in the open. Similarly, the financial industries my group is targeting will be very concern about the privacy aspect.

@Niels, I remember you wrote something about the privacy aspect of using Factom incorrectly. I can't find it on Discord, do you mind go over it again for the group? I don't believe we settle on a "solution".

On a side note, marketing committee or another group should consolidate these most common questions/concerns from industry partners as we all go out to get businesses. This way our answers are not only consistent, we can also relay these concerns back to the tech team.

 

[Greg Forst]

Copy and paste from discord

BobbyEK - Today at 9:28 AM
They’re concerned that bitcoin will get hacked before their own database? Or worried about the cumulative value of transactions becoming a target worthy of the computational power required?
Niels - Today at 9:31 AM
@BobbyEK One of the concerns we see initialy with enterprise clients is roughly the same as described: Our documents are really valuable. It may not fall into the wrong hands. How can a public blockchain (database) be any good for the security of our content? It is counter intuitive, untill you start explaining that using mathematical algorithms you can make unique fingerprints of any content, without the possibility to go back from the fingerprint to the content :winkedited)
@gforst Please let us know whether their issue is in this alley or it is something completely different(edited)
StevenM now starts explaining social attacks and entropy..... :stuck_out_tongue:
StevenM - Today at 9:33 AM
No lol. I'm on your side :laughing:
Niels - Today at 9:33 AM
Hehe
BobbyEK - Today at 9:36 AM
The general understanding of Blockchain tech still has a way to come in the boardroom. It’s not the IT departments we need to convince, but executives and stakeholders of public companies. They believe existing systems are fine.... until they’re not.
Until the $17billion fine lands on their desk
StevenM - Today at 9:38 AM
It's a strange question in the context of Factom as what are they referring to as "hacked"?
The data on Factom is public. So as Niels had stated, you should only be keeping hashes of records on chain.
Another way to "hack" factom is to control the data going into the blockchain. However, every record has to be properly paid for and signed, so your data will exist or not exist (which you can easily check for). Any modifications change the hash, and break the payment. So if they verify their hashes make it into the blockchain, it's too late for any party to change/censor it.
BobbyEK - Today at 9:41 AM
I think the issue like above is that many people on first glance think Factom is simply storing your data on a blockchain. “Factom stores the World’s data on a decentralised system” - this wording, from Factom themselves, leads to a lot of confusion unless familiar.(edited)
2
Niels - Today at 9:43 AM
Yeah, that is also why I am really interested in some of the applications people will be building on top of Factom. You have to think first (well that is alway a good starting point :wink: ), before creating datastructures on Factom
gforst - Today at 9:52 AM
Love the feedback. Lets say said client is looking at Ethereum. What would be the argument for Factom? (i am copying info to thread as well)

 

[Greg Forst]

copy paste from Discord

--
Niels - Today at 9:53 AM
Completely different tech. Factom is about auditing information. Ethereum is smart contracts. Factom has stable prices for enchoring info. Ethereum not so much so currently.(edited)
Ethereum is a distributed state machine
sanchopansa - Today at 9:53 AM
It would be great to have some more context about what they deem as hack. Blockchains are slower and more expensive then centralised databases, but they are also more secure. If they are worried about hacks, they should be even more worried in the case of a centralised setup

 

[Greg Forst]

copy paste from discord
---

sanchopansa - Today at 10:00 AM
I also get the question about Ethereum vs Factom quite a bit. It’s not so easy to convince people, since I think one can make a valid case of IPFS and Ethereum providing a similar functionality to Factom. The answer I usually give is that: The Factom protocol is cheaper, has sharding by design, so in theory it should be easier to scale and last but not least it’s optimised for a specific purpose: creating immutable audit trails. IMO, this makes it safer to use at least compared to Ethereum at the moment, as there you always have the risk of introducing bugs because of the immaturity of Solidity and the EVM

 

[Greg Forst]

copy and paste from discord

--
StevenM - Today at 10:07 AM
I feel developers who use etheruem also try to have a lot of data logic on Etheruem. This is good for some purposes, but not for the use cases Factom is targeting. The second you couple data with logic on etheruem, now you have to handle smart contract upgrades and other means to "fork" your contract if you want to keep the data. However your architect it, it's not as trivial as keeping the logic off blockchain.
Factom is purely data. If you want to add a new datatype to your audit trails, just do it. Update your client side code. It's simple.

 

[Greg Forst]

copy and paste discord

--
gforst - Today at 10:21 AM
lets say you needed to ensure the integrity of software files being shared. (I know I am not giving you full information) but in theory smart contracts are not the proper solution to ensure the integrity of software files being shared?
Niels - Today at 10:23 AM
Nope. Don't want bugs in your smart contract when you need to prove something with readily available techniques. Hashes are proven technology for 30+ years. By making sure you store a hash on a immutable ledger and a signature for that hash, you can always independently verify this hash and signature when you receive the software files (or any files).(edited)
You can both prove the positive: These are the files that were hashed and signed and the negative: These are not the file that were hashed before. It is altered
This is the basic Factom use case :wink:
Do not start using smart contracts for that :smiley:

 

[Greg Forst]

copy and paste from discord
--
sanchopansa - Today at 11:49 AM
While I agree that ensuring the integrity of files is easier done on Factom, I would also play a bit devil’s advocate and claim that it is not so outlandish to do the same using Ethereum. One can create for example an asset registry smart contract that is in essence a mapping from a string to an array of (int, string). The key, a string can contain the unique id of the asset (e.g. a file) and then the (int, string) would be a time stamp and the hash (potentially signed) of the contents. When the file/asset is somehow modified, one can append a new (int, string) to the list. This is obviously very simplistic, but I don’t see why it wouldn’t work. Then to check the audit trail it would actually be free since you are only reading from the data in the contract.(edited)
luap - Today at 11:51 AM
One big argument for Factom is the non volatility of the cost of operations
Mig - Today at 11:51 AM
What would be the cost of such a method using ETH during a peak of on chain volume like they had with the cryptokitties ?
StevenM - Today at 11:55 AM
@sanchopansa I agree simple contracts can be created. However I think it would require a bit more:
The contract would probably want to gate against a record being overwritten.
The contract would probably only want certain addresses to write to the state.
So it would need logic to only allow address X, and handle adding a new address with permission to write.
If compromised, you would have to add client side logic to ignore certain records, or add the feature to delete records into the contract itself.

all these features pose risk, and I don't see the benefit of running the logic in a smart contract vs client side logic
1
Cloning all the data structures from factom into etheruem is just too expensive.
Signing entries in factom adds 64 bytes plus some overhead. But 100 bytes, or 1024 bytes is the same cost. On etheruem, each byte has a cost. So there is always a choice to be made, add logic to prevent some action, or add information in the record. Both have additional costs in Etheruem.

I do not mean to bash Etheruem, it's just not intended for this use as well as Factom. IMO (a bit biased probably :laughing: )
sanchopansa - Today at 11:59 AM
Factom would of course be cheaper. SSTORE is the EVM transaction that is required to store data on chain and its cost is 20k gas. You also need 21k for the transaction itself so at minimum 41k gas. With ETH at 700 usd and a gas price of 10 gwei it would be around 0.29 usd, which is a huge difference to Factom unless the operators make ECs more expensive.
sanchopansa - Today at 12:02 PM
And yes I agree that Factom is more secure, easier and cheaper @StevenM. I am also a fan of Ethereum, but I think using a protocol tailor made for creating immutable chains is the better proposition for a number of use cases and there is a big enough market for it to merit its creation. I wouldn’t be here otherwise.
Complexity is the enemy of security and I think that’s one of the main problems with Ethereum that I don’t see going away any time soon.