Post #3798

899731754e27fc7ba1c4b7e5a037d45c74b4a2b14ad56ae8eb4daa29a34faa4b
3246d51eed7eceb7bd02422d3b49088df1dc1f9d4343999912f1dcc48af57c87
Signature not verified

This entry might be using an old signature, or it was signed by a key that does not exist on the server.

{"entry_date":1534727312,"post_data":{"edit_count":0,"last_edit_date":0,"last_edit_user_id":0,"message_sha512":"ca3de2609d86688cf20150e400f39e491073fb33bbe89ff1fda60762ccbb4006bd9eb1bc4cf23f11177e2f844a286ea0433cbbaf6474473fa88214cde4146830","node_id":32,"post_date":1534727193,"thread_id":568,"user_id":48},"post_link":"http:\/\/factomize.com\/forums\/index.php?threads\/568#post-3798"}
The entry content as it exists in the database. This should be verified against the blockchain entry.
Veteran Blockchain Investment Firm
[USER=8]@Niels[/USER],

[I]NK follow-up 01) Could you go into more details. I don't get the critical enough data to justify it in the context of hashes (pure data on Factom certainly)? I could see other reasons for instance, but that is not about the hashes themselves or lifetime planning. A blockchain also means you have a time associated at commit time. Hashes are one-way functions that over time might mean a collision could be forced if flaws in the hash mechanism is found. When entropy is too low on the data you are hashing you have a potential problem, but then you should be asking yourself whether it should be hashed on the blockchain anyway. I fail to see how Factom on Factom would help in the above situation where hashes are being used. Please ELI5 me.[/I]

We are first to admit that Factom on Factom is a concept that we are still trying to better understand. When we had proposed the GovCloud concept, one of the primary concerns we had was ensuring our efforts would not impact usage on the mainnet significantly if the data is sensitive but unclassified. Our goal is not to pull uses onto a private chain, but if the customer is committed to using a disparate network, we wanted to evaluate options to still generate some usage for the public mainnet. This was one solution offered up. We still have a long way to go to bring it to fruition and may not be possible.


If the mere fact that the public Factom network provides a vector to exploitation, we may not be able to make it work. There are cross-domain solutions but they may be prohibitively expensive to provide the Factom data layer service. What we are discussing is a small piece of what we plan to allocate some of our remaining man-hours and expertise outside of maintaining the node to pursue. We intend to be the USG business development arm of the protocol, providing the medium for other ANOs to market and capitalize on the largest on-demand customer.


We believe in the value the Factom Protocol provides to the many vertical markets that exist. We see the Veteran team as a value-added entity that will enable the Factom protocol to penetrate further into these verticals. Our proposal for a GovCloud is merely a vector to demonstrate the technology, generate awareness, and increase adoption. It may not be obvious, but USG entities are increasingly adopting cloud computing technology on various classification networks. Providing the Factom protocol on these networks to establish trust amongst the entities is the goal here.
This is the raw content, without BBCode parsing.
Top