Why do you think that?  https://github.com/FactomProject/factomd/commits/m2-sunday



Maybe more than what you were looking for:
https://medium.com/@BrianDeery/i-love-negative-feedback-632f8ee780ff


While storing things on the factom blockchain is expensive, and not really even guaranteed, it works much better as a publishing platform pointing you where to find the bulk data, and if you find it, is it correct (by whatever definition of "correct" your application might use).  Bitcoin with pruning used widely in the future has similar properties.

As the Turkey censorship detailed above, storage is not the real problem.  The real problem is the indexing, collation, publishing and advertising of the data, coupled with making sure you have the right data.  Storing of the data is not the hard part.  Once you know what data you are looking for (and in some cases how to find it), it does not matter who produces the data, if you can check its hash and verify the signature.
Here is Julian Assange talking about this technology.

https://www.youtube.com/watch?t=290&v=MaB3Zw5_p9c

This resonated pretty strongly with me.  George Orwell predicted a pretty bleak future.  The antagonist in the book 1984 has a saying:


Securing records in a public witness (a blockchain) with >$1,000,000 of electricity per day being burned to advance the ledger, means that bureaucrats with admin rights cannot change history undetectably.  Even when the local databases are wiped, individual citizens can produce copies of the digital documents that match the hashes signed earlier by the bureaucrat's predecessors.

There is also a pet theory of mine which flips the rationale for Bitcoin's existence.

https://medium.com/@BrianDeery/hashpower-is-the-ends-bitcoin-is-the-means-4de61c559bc0

This is pretty much right, but a few details need correcting.  Think of the Federated servers like you think of bitcoin mining pools.  They are the authorities of how transactions get ordered in the system.  They all work together to build the blockchain.  There can be thousands of bitcoin nodes in the system, that also see all the data.  The bitcoin nodes see all the pending unconfirmed transactions, then after the miners order the transactions, all the nodes save the block which sets the ordering.  It is similar with factom.  All the nodes will see all the data, just like bitcoin.  Unlike bitcoin, the authorities are known in advance, so the order can be determined in real time, instead of probabilistically after the fact.  This gives faster response time.  Like the bitcoin miners, the servers will run the same code as all the other nodes.

Unlike ethereum or even bitcoin, factom nodes & servers do very little validation.  All that is checked is if data was paid for before putting it in the blockchain.  This is in contrast to something Turing complete, or even with a simple script like bitcoin.  All the validation for an application will be done on the client side, rather than on the servers.  Here is a comparison of the approaches: https://www.youtube.com/watch?v=naKvYfYsBQo&feature=youtu.be&t=3476

Even with a very high transaction usage, the bandwidth required will be about that of a High Definition movie or two.  

https://bitcointalk.org/index.php?topic=850070.msg13588841#msg13588841

When the system starts to process more transactions than the average node bandwidth can handle, that is where the p2p network sharding comes into effect.  Since all entries in the system need to declare a ChainID, then there is room for lots of parallelism.  We are anticipating this.  For example, Identities are a big part of how the servers will be chosen and managed.  They are forced to start with 0x888888 to be valid by using brute force hashing.  https://github.com/FactomProject/FactomDocs/blob/master/Identity.md#factom-identity-chain-creation  This will put all identities into an easily identifiable network shard.  Since most people won't care about other people's applications, they only join the network shard that handles their application.  The shard is there for real time communication.  After the blocks are made, everyone needs the directory blocks, but you would only download the entry blocks and entries related to your application.  For now everyone downloads everything.

Myfarm's conclusion about the federated servers being more powerful than nodes will come about if they span different network shards.

We will have 32 federated servers for M3.  More than that and we probably would have coordination issues.  

The whitepaper does not have any code in it.  In my opinion, there might be a little too much fluff and exposition.  It is approachable by those who cannot read code.  Most, if not all your questions posted are answered in the whitepaper.

You are asking for a 5 minute read to "fully understand" the project.  It take would probably take a years worth of study to fully understand it.  If you won't even read the whitepaper, then it seems you do not want to understand Factom.

We do have some informative explainer videos.  These may help, and will only take a few minutes to watch.

https://www.youtube.com/watch?v=6NF7ZqaQHqs
https://www.youtube.com/watch?v=2Dj3qZeSLdY&list=PLz_L4-CmLmkf2hAcCEnM_5RM1Gs7XPuuN&index=2

I think the name Factom is a lot better than Notary Chains, which is what the project started out as:
https://github.com/NotaryChains/NotaryChainDocs
https://www.youtube.com/watch?v=HN7ewkc9uiM

The biggest competitor I see is Status Quo.  They have a huge market lead.  While their security isn't as good, and their documents are subject to tampering, the business types often prefer that style of technology.

A good place to start is with the whitepaper.  This will catch you up on the basics.

https://github.com/FactomProject/FactomDocs/blob/master/Factom_Whitepaper.pdf

If you still want more after digesting the 38 page whitepaper, we have another follow up paper with more details.

https://github.com/FactomProject/FactomDocs/blob/master/FactomLedgerbyConsensus.pdf

The email in question did come from Paul.  There wasn't much difference between the email content and what we told the community a few weeks ago:

https://letstalkbitcoin.com/blog/post/the-crypto-show-with-the-factom-crew-paul-snow-den-and-brian-deery

It would help if you could post the error messages, perhaps on https://0bin.net/ instead of the entire error log here.

Others have had luck with an experimental windows version.  There are both the 32 and 64 bit versions.  See if those fix your windows issue.  https://github.com/FactomProject/factomd/issues/23

The linux virtualbox not working is concerning.  We might need to look closer into that.

Steve, thank you for trusting our project with you hard earned bitcoins.  
The least risky (and easiest from an effort perspective) is to just leave the factoids on the 12 words.  Check that the koinify process worked by using keymaker just to give yourself peace of mind that everything worked right.
https://factom.com/devs/docs/howto/check-your-factoid-balance

You can leave those factoids on the 12 words indefinitely.

I see the drop in Factoid transactions over the network as well.  There are still transactions happening though, and we are able to move factoids as expected.  It is unclear what is happening on the exchange.

done right, a single transaction would be valid on both chains:

http://www.coindesk.com/rise-replay-attacks-ethereum-divide/

For all those running windows and are having trouble with factomd on Milestone1, a helpful community member has developed a fix.

If you were having problems with windows giving panics, please test one of these:
https://github.com/FactomProject/factomd/issues/23

Let us know if it fixed the windows problem you had been seeing.

You are confusing proof of existence with proof of publication, i.e. proving the positive vs proving the negative.

An example is that a bitcoin full node proves the negative by examining the entire chain history. To see that a doublespend hasn't happened, all transactions ever are examined.  Axiomatically, if it is not in the blockchain, it didn't happen.

Contrast this with an SPV node like the sildbach wallet.  it relies on the proof of the positive.  a fullnode can show an SPV client that a transaction is in the blockchain, but the full node cannot prove the negative, that the BTC has not been spent earlier.  SPV clients rely on the economic incentives of miners to protect them.

Factom is for client side interpreted applications which need to prove the negative.  if all you need to do is proof of existence, then yes, you can do that yourself or with any other ephemeral service.

We made kind of a big deal about this in the white paper.

my pleasure.

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

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.

the papermill will create the public and private keypairs.  It does not require the blockchain in order to use.  it can be imported into a wallet later and used to create transactions.

Before I would send any factoids to the paper wallet, I would import the private key into walletapp.  if the public key on the paper matches the public key in the wallet, it should be safe enough to send.  you do not need the blockchain or factomd running in order to import a private key.

if you are worried about local attackers, you can run a CD based linux distro with the computer hard drive disconnected.  this will stop the private key from being saved locally.  download and install the factomd binaries then run walletapp.

hmm, there should be more than this between "syncing to block height" and the error that you are showing.  I need the text just after "syncing to block height"

if it scrolls off the cmd window, you can change the screen buffer size from 300 to 3000 to see more.
http://www.chami.com/tips/windows/050298W.html

Factomd should't shut down on it's own.  let see if we can find the error.  open a command prompt, then run factomd.  When it closes, it should give an error message.  

What does it say just below: At x: syncing to block height x from...  after it stops?

As usual this journalist tends to point in the right direction, but gets details wrong.

He is confusing storing with freely serving up data.  Often these are the same, but don't have to be.

Also, we have maintained all along that factom is for securing data not storing it.  There is no guarantee that factom data will be around in the future.  A good analogy is that 100 year old newspapers are not found on your doorstep, but if you need one, with enough effort you can find it in microfiche at a library.  Factom is good for telling you what to ask for and to make sure you got the right thing once you find it.  If you absolutely need to have some data in the future, store it yourself.  The data validates itself though, so no one needs to trust your storage system was honest.  

He is also assuming there needs to be an internal reward for both serving and storing.  As bittorrent and IPFS (when available) show that is not the case.  People serve up data that is relevent to their community.  We see this with bitcoin too.  There will always be full nodes even when pruning is common.  Their upload bandwidth just might be really slow.

Even his view from the perspective of Bitcoin is also only half-true.  UTXOs are not stored in ram.  
https://www.reddit.com/r/Bitcoin/comments/35asg6/gavin_andresen_utxo_uhoh/cr2n147
https://www.reddit.com/r/Bitcoin/comments/35asg6/gavin_andresen_utxo_uhoh/cr2vk8x