Factom Core Developer Update – June 9th, 2015

Technical Updates | June 9, 2015
Home » Company » Blog » Factom Core Developer Update – June 9th, 2015

Progress Summary

Factom is getting closer to delivering our first milestone. Since releasing explorer.factom.org a few weeks ago, our team has been working on backend updates. You can view our progress on the Factom Project GitHub profile.

We are targeting a pre-release testing version of the Factom client, which will allow third-parties to start building applications using Factom.

Our team is focusing on thoroughly testing and getting Factoids working, a critical requirement to complete our first milestone.

Things We’ve Learned

We have learned a lot from Bitcoin, and are going straight to something more like P2SH. Before the 3xxxx addresses were implemented in Bitcoin, when someone sent BTC to someone else, the sender paid a higher fee for the receiver’s security. If a company wanted to have three of five signatures, then the higher fees for the five pubkeys would be borne by the consumer. Bitcoin fixed this with P2SH, and Factoids use something akin to this from the beginning.

Part of making the coin is generating a genesis block. We leveraged some code from the Ethereum project to build the Factoid genesis block. The Ethereum code looks at data from blockchain.info to build a genesis block. We wanted to be certain that the correct data was put into our genesis block. We compared this with data provided by Koinify. We also ran similar genesis transaction building code against a local BTCD node to test if the blockchain.info database had been corrupted and was feeding invalid data. We are happy to report all three sources validated each other.

Open source software promotes a culture of sharing. Ethereum was kind enough to lend some of their tools to the public, including our project. In turn, we are contributing back issues we have found to continue improving the code.

One of the disappointments we encountered in the past few weeks is the US Government, rather how slow they are. The USG held a crypto competition several years ago for SHA3. SHA3 was to be the next generation hash algorithm after SHA2, which is what Bitcoin uses. In 2012, USG announced a winner in the SHA3 competition. Since then they have been dragging their feet for the past three years on finalizing it.

We wanted to supplement our security of using SHA2 with cross checks of SHA3. This way if either SHA2 or 3 became easy to break, the other would remain to validate nothing had changed.

We were seeing some funny problems with the hashes being made with different libraries in different programming languages. After some digging, we found that USG had changed the SHA3 standard in 2014. Developers writing code for Factom would be using varied computer languages. Those different languages come with different libraries. The library developers have implemented different versions. Here are two examples even within one language (python) which disagree on what SHA3 is: pysha3 and spongeshaker. Most library developers are waiting until finalization of FIPS-202. Some warn against using their library until finalization.

Next Steps

We are concentrating on getting the blockchain data structures right since like Bitcoin those live on forever. If the definition of SHA3 changes, then the block definitions would change too. It seems unwise to build this into our product if the USG might change it again. We have decided to rethink the strategy for the extra security. (note, Bitcoin, as it stands, is also vulnerable to this issue, if what we are defending against with this extra security becomes a true concern.)

We are pushing forward with getting the first Factom milestone completed. Thanks to all of you that have supported our development and the technical community for continuing to review and test Factom along the way.

POSTED: June 9, 2015 BY Brian Deery IN Technical Updates