Any update on milestone 2 testing? Also, are we on target to delivering what we promised for Microsoft's BaaS? Thanks in advanced for your reply. Exciting times ahead  I'm still collecting emails from people interested in testing milestone 2. Let me know if you want to be one of the first outside the team to play with it. We had success with the community testing milestone 1 back in August 2015. |
|
|
|
I see koinify is/has shut down and that it doesn't matter in regards to our presale buy. But, is there a GUI wallet ready? I never imported my 12 word phrase anywhere - or the coins safe in their original place forever? Or must I eventually import? I would rather not touch them for years.
To check your balance, or to see if you were one of the handful of people that had problems with the koinify purchase, run the keymaker app. instructions here: http://factom.org/howto and here: https://github.com/FactomProject/keymakerI would recommend keymaker to see if the 12 words work. If they work in keymaker, you can hold them there like a paper wallet. If you are impatient, you can create an account on poliniex and import the 12 words and all the factoids directly (unless you were one of the lucky handfull, which keymaker will tell you) |
|
|
|
1. Factom is geared more for indexing data rather than storing it. in some cases they are one in the same, but the system makes no long term promise about quickly serving your data back to you whenever you request it. Think of it like pruning in bitcoin. Something the size of an omni or counterparty transaction would easily fit in an entry. Now if you store a local copy of the data you need, then the factom data structures give you the ability to provide a proof later on to peers. 1.1 The current target price is about $0.001 per KiB, which equates to $1000/GiB. When the system goes decentralized in the future, it is not knowable what the Federated Servers will set this price at though. 2. It has more to do with a holistic approach to access control. If an element of immutable time is required for access, then it gives sysadmins time to respond to certain types of attacks. 3. two points. a. We expect that communities will share their data subsets amongst each other freely. If property records are secured for some country, then it makes sense for various citizens in that country to download and share up the public data. People share up bittorrent data for free to members of their communities who want their particular datasets. b. This is all public data, and someone will record it. Take centuries old newspapers for example. They can still be found, just not a the corner shop. You would need to go to a library to get it, or maybe pay a fee. I don't think the data will ever go away as long as there is some chance that it may be valuable, but it may be harder to get. 4. Countrywide would sign the hashes before placing them into factom. spam would be unsigned and could be ignored. 5. Paying for upload bandwidth in a distributed way is a really tricky unsolved problem in general. Both storj and maidsafe are exploring solutions to this. Every solution Paul and I explored could be gamed one way or another. If it is as successful as you are claiming, then the inflation subsidy would more than pay for upload services. There is no mining in factom so inflation does not get dissipated in electricity bills. I made some back of the envolope numbers which Paul will present in Miami about how the data is segregated. I guess it isn't really an announcement, just an analysis, so I'll share it here. There are lots of wild guesses here, but it gives you the idea of how it will scale. This is data per year. Assume: 50 million shipping containers, each with 10 entries per year 117 million mortgages with 12 entries per year 5 million mortgage originations/title transfers with 30 entries per year 300 million health records with 10 entries per year 1 stock exchange with 1500 companies with 10 million entries per day each assume 1k per entry.  total data in all the layers per year is 26.4 petabytes. The shared part in blue is the directory blocks. This comes to 313 gigabytes. the Entry Credit payment overhead (yellow) is only to prevent spam in the present. it can be discarded by most people, and they can just store the balance info. (think UTXO set vs full chain in Bitcoin) Notice factoids do not even show up on the graph. those are just a way to get entry credits in the first place, and there would be a 10,000-100,000 ratio in EC commits compared to factoid transfers. Only very small subsets of the red Entry Block data is only needed by the applications to prove their states. your application would only need a small sliver of the red. If the annual user data is 19.5 petabytes, you would only need to sift through blue 300 gigabytes to find the data for your application. 5.1 data in factom is separated into chains, which are a clean way to segregate applications and what data you are storing. I imagine in the future, you will only be storing and uploading the data which is important to your application. There are also plans to segment the network, so peers form subnets which only relay some of the data. 6. Because Sibyl. We get advantages from having a predefined authority set. As that set gets bigger it gets harder to manage. Also there need to be few enough of them to matter to vote out. see Dunbars number. 7. yes, sorry, we tweaked the protocol between the whitepaper publishing and launch. They are indeed every 10 minutes. we have a few other mistakes in the paper: https://github.com/FactomProject/FactomDocs/blob/master/Factom_Whitepaper_Errata.md8. Thats where we started out with, but that one party could censor an individual while leaving the rest of the network working. would all of bitcoin switch over to a new network just because the miners were censoring one particular person? the next step is to allow free entry, but then to prove the negative, an application would need to download data from all possible sources, making spam trivial. more thoughts here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-March/007721.htmlThanks for the fantastic reply! And thanks for those links as well. I still have a few concerns and inquires. 2. Would you care to give an example? 3. What about private data? 5. I either don't understand or I didn't phrase my question properly. Do full nodes hold the same amount of information as Federated Servers? Federated Servers would be required to store everything in blue and everything in red, right? Would full nodes have to do the same? How much space is that? 6. Frankly, I'm not much of a security expert and while I have a vague idea of how a Sybil attack works I don't understand how one could be performed without a fixed number of Federated and Audit Servers. If you would care to explain, it would be much appreciated. 8. I'm beginning to grasp the whole censorship resistant while simultaneously spam resistant concept. However, Factom seems like an expensive solution to prevent the occasional censor and in a free market I feel like a trusted 3rd party who engaged in such practices would die while other blockchain stamping services took their place. Is this a bad assumption? And if it's not too much trouble, I'd like to add a couple more questions... 9. Given that the factoid's real value, speculation aside, is based completely on the amount of entries entered into the protocol, given that currently less than 2000 entries are made a day, and given that when milestone 3 is achieved, which is expected to happen in the coming months, 73000 factoids will be generated each month, the current price for a factoid seems vastly overvalued. Is this all just speculation, or am I missing something? 10. Is there anything I can do to help out?? Once again, thanks for the helpful response. 3. There is no private data in factom. everything in factom is public. it may be encrypted, the the cyphertext is public. 5. Good question, this comes down to nomenclature. keep in mind that even bitcoin miners do not need to be full nodes. all they need is the UTXO set to validate transactions. The factom federated servers are the same way, they only need the chain heads, Entry Credit and Factoid balances to create new blocks. It is in their interest to serve up the data later, but the protocol does not require it. Axiomatically, a full node will have all the data. factom is setup so that you will eventually be able to usefully contribute upload bandwidth to the network without being a full node. This was the point I was trying to make. 6. Perhaps sibyl isn't the right term, since it means something specific. Mostly we are worried about getting the balance right between too many and too few servers. We want to have different people be the various federated servers. If an unlimited number of people can be a federated server, then it will be hard for whoever is voting to determine if someone is running multiple servers. Also, it is a bit disruptive when servers drop out, so it would be better if they were professionals who could dedicate enough attention to it. If it is spread out too much, then not enough attention will be paid at the lower levels. Also, conversations with others who have implemented similar consensus systems in the past observed that numbers much higher than 32 became problematic technically. 8. You are ignoring the network effect. Imagine if counterparty was built on a system where built on a system where it needed to be packaged by servers owned by digicash, inc. In order for a counterparty transaction to be valid, it would need to be accepted by digicash, inc. If digicash occasionally decided to cut someone out from the ecosystem, then that person effectively loses their tokens. if the system stops you from transferring them in exchange for money, you might as well not have them. Assume there is free entry into the system. In order to verify your counterparty asset, you needed to download all of the Digicash, inc counterparty transaction. ok, that is what you had to do anyway. Another entrant, Beenz, decides to process counterparty transactions too. now in order to validate counterparty you need to download all of Digicash and Beenz. Who gets to decide what new entrants are worthy? If there is free entry, Cheapestparty, inc will start up and provide free counterparty transactions. The market goes wild and puts petabytes of counterparty trades into Cheapestparty. Now in order to validate the counterparty transactions, you suddenly need to download petabytes instead of gigabytes of transactions. It seems you are confusing timestmping with blockchains. timestamps are for proving the positive and blockchains are good for proving the negative. see: http://tpbit.blogspot.ca/2016/01/positive-and-negative-proofs-in.html10. we will be starting to test the p2p network soon with milestone 2 code. we are looking for community testers who will help us test the milestone2 code before we launch it. please reach out to brian@factom.org if you would like to help test. |
|
|
|
A few questions as I work to wrap my head around Factom and determine if I want to invest or not:
1. Why will 73,000 FCT be created each month? Why not 75,000 or 50,000? It seems to me that initially, there will be substantial inflation once the Federated servers go live and at some point, potentially substantial deflation. Why not just create as many FCT each month as are used to purchase Entry Credits to keep the number of FCT static?
2. As I understand it, Entry Credit holders will be able to vote for the Federated Servers. What is to stop me from purchasing a ton of Entry Credits not to use for Entries, but to use to vote my servers and the servers of my friends to Federated status. What's to stop me from, "Selling" my votes? Why not have a Darkcoin masternode system where anyone can run a Federated Server who puts up the necessary collateral and they are paid in turn. More decentralized and less prone to vote stuffing.
3. As I understand it, X Factoid were sold at the public offering, and Y Factoid are held by Factom Inc or its employees. Is this correct, and if so, does Factom Inc. hold those tokens or employees? And what rules are in place for those tokens? For example, is there a lockup period where they can't be sold and if so, what is the expiration date? Or are they actively being sold by employees for profit or the company to raise additional funds?
Thank you for your insight as I conduct my due diligence.
1. As described in the initial token sale documentation, to pay for the server+engineering time, new factoids would be created at a rate of 20%/year of the token sale amount. 4379795.611338 factoids were sold, which corresponds to 875959.1222676 per year or 72996.5935223 per month. The federated servers goal is to make each unit they are granted become more valuable. The best way they have of doing this is to increase the amount of value people are sacrificing to place data into the blockchain. The more people are using the system, the more demand there is for the tokens, and the higher the market price. If we were trying to make factoids be money, only paying transaction fees would keep the supply stable. In contrast to many other projects, Factoids are not trying to be money. We already have internet money, and that is bitcoin. Factoids are a tool to pay the servers in a scalable decentralized way, coupled with a way to provably show that value was destroyed. The closed loop feedback nature of the system means in the long term (absent speculation), the dollar amount of the factoid inflation will match the dollar amount of entry credits being purchased. Speculation thrown into this will drive the dollar price up or down from this equilibrium. Now when we have this mismatch between the source (inflation) and the sink (entry credit purchases) then the increased or decreased supply will tend to correct the price towards equilibrium. Contrast this with your transaction fee model, where speculation would be the whole point of the token. At that point factoids would be competing to be money, which goes against what we are trying to do. 2. most systems can be attacked by throwing money at them. The best we can do is to make it so that an attacker needs to expend more value than the rest of the network combined. Optimally we would use thermodynamic proof of work, but as history has shown, unless you are Bitcoin, using proof of work is more of a liability than a benefit. The darkcoin masternodes seem like proof-of-stake. Daniel Larimer has some interesting recent thoughts on proof of stake. I have long been of the opinion that proof-of-stake is superior to proof-of-work. Today I would like to challenge my own beliefs against the lessons I have learned from over a year of experience with proof-of-stake. http://bytemaster.github.io/article/2016/01/04/The-Benefits-of-Proof-of-Work/We think that the people who have the most interest in the success of the system are the ones who are actively using the system. The ones purchasing entry credits are the ones using the system. On that note, we are setting up a delegation system, so you can direct your Entry Credit support to your favorite blogger, who presumably actually pays attention to what is going on. They would then vote on your behalf. 3. 40% of the token sale amount was granted to early purchasers. 60% of the token sale amount was granted to early contributors.  http://allcoinsnews.com/2015/05/16/factom-raises-2278-btc-in-software-token-crowdsale/ |
|
|
|
no. google decided to finally retire some of their go crypto repositories, and we needed to compensate so that it would continue to compile. although bip39 was developed by the same people behind the slush pool and trezor, there is no connection. |
|
|
|
Will the master passphrase (which I got from Koinify) be valid "forever" to recover your FCT?
Is it something like a private-key?
Looking at where this great project is going, I'm planning to hold for another 1.5 / 2 years and don't want to discover that my FCT are gone when I try to "dig them up".
There were a few lucky people who had problems with the token sale. I would recommend running keymaker on the 12 words to make sure your address contains the on-chain balance that you expected. The koinify wallet did not look at the factom blockchain, so there may have been some disconnect for some people. also, depending on your paranoia level, you were online when the koinify sale happened. if you want offline security, papermill can be run offline, and never touch an online computer. the conterbalance to that is that latent bugs in the software may have bad results, and inaction might be safer. It depends on what your risk tradeoffs are. as far as the importing, we do plan to support it for a while, but the mapping between the 12 words to the private keys is publicly documented, so it will always be possible with enough effort. https://github.com/FactomProject/FactomDocs/tree/master/token_sale |
|
|
|
The website says this about Papermill:"This is early beta software you should use this guide at your own risk, we suggest not to use large amount of factoids in case there may be issues and/or bugs." Thats not too reassuring for me to store any factoids long term. The koinify passphrase is not as secure?? Thanks 1. see https://bitcointalk.org/index.php?topic=850070.msg13544457#msg135444572. also keep in mind the backup strategy. humans have much more experience preserving pieces of paper than they do digital media. |
|
|
|
Dear sir
First l must admit that l m not computer expert at all but followed Factoid Wallet GUI Guide
l have installed Factomd and walletapp from the link provided by Factom.org and have tried to run Factomd to sync to Blockchain but keep getting,
Error reading config file
System cannot find the file specified
The process cannot access the file because it is being used by an other process
Invalid argument
l would appreciate if you could spare some of your precious time to guide me how to solve this issue to sync and create a Factoid address to move my Factoids as you may aware of that Koinify is shutting down by 15 Feb 2016
Kind Regards
Do not worry about losing factoids due to koinify shutting down. The 12 words were the only way to move the factoids, with or without koinify. Koinify closing only will have a small drawback. Their password reset feature was a good way to check if you had the correct 12 words. We will lose that as a debugging feature. We are aware that on windows the log file does complain a bit, but it does not stop you from using factom. as far as the config file, there is an internal one which uses the defaults. only when you need to do development or something like that would you need a config file. is accessed by |
|
|
|
Hello Factom community. Back during the factoid crowd sale, I heard about this tech and bought some factoid on a whim (good choice  ). Now with the recent surge in price I have been researching Factom and I have some questions: 1. First I need to get something straight. As far as I can tell, Factom is not for storing data. Is this correct? It seems to me that one could store data in entries, but it would only be stored on the Factom full nodes and it would supposedly be expensive, and so rather than storing data, users are intended to store hashes of data. Please correct/validate/enlighten me. 1.1 I couldn't find in the whitepaper how much space 1 entry credit purchases. How much space does it purchase? I'm trying to figure out how realistic it is to store data. 2. If Factom does not store data, but more likely data hashes, how does Factom secure information? In one of Factom's YouTube videos a use case for Factom is described as preventing the Sony hack; however, I fail to see how Factom could prevent such a hack. Sony's data is still on their servers and if a hacker breached those servers he would still be able to acquire sensitive information and do with it as he pleases. 3. Another question about data. If I lose the data that I have secured with Factom, I, nor anyone else, can prove whether or not it existed. Correct? 4. Related to the last question. As far as I understand it, anyone can submit entries into a chain, correct? If so, data loss becomes an issue again. I watched another YouTube video where Paul Snow is speaking at a conference in Dubai I think. In this video he explains how Bank of America could have reviewed a Factom chain to insure all the records were present and correct. I don't understand how Factom can prove if all the records were there. If all the records were hashed into "Countrywide Mortgage Records" and after review there were hashes that were unaccounted for, how does Bank of America know if these unaccounted hashes are important records or just spam? 5. It seems that Factom becomes successful and widely used it will be storing impressive amounts of data. In a world where millions or billions of entries are being submitted every year I can't help but think that the amount of data a full node will have to store will simply be too much. This is especially true when one considers that Federated servers are not being rewarded for their storage; they are only being rewarded for further entry submissions. This means that as time passes the ratio of the amount of data being stored compared to the reward will get bigger and bigger. While normal data centers, say Amazon Cloud Services, receives constant compensation for the continued use of storage, Factom Federated Servers don't. Please help me better understand the economics of Factom and how this problem (if it even is a problem) will be overcome. 5.1 It also seems inevitable that data centers will be the only ones capable of being full nodes. Is this correct? intended? 6. How come the amount of Federated Servers and Audit Servers are fixed? It seems to me that the more there are, the better. So why not just have all full nodes be in the pool of possible Federated and Audit Servers and then split the group in two according to the mentioned voting system? 7. After reading the whitepaper, it is still unclear to me whether directory blocks are made after every one minute or after every 10 minutes. The whitepaper states they are made after every minute, but on examination of the protocol through the block explorer, I get the idea they are made every 10 minutes. Please elaborate. If answers to these question are posted somewhere else, forgive me. I couldn't find any. I also hope that this isn't overbearing, I just want to better understand how Factom works as I really hope it succeeds. Thank you for your time. EDIT: One more question 8. How is the decentralized Federated Server model better than a centralized company that does the same thing? Since everything is validated client side, Couldn't a central entity assemble hashes and stamp them into the blockchain? 1. Factom is geared more for indexing data rather than storing it. in some cases they are one in the same, but the system makes no long term promise about quickly serving your data back to you whenever you request it. Think of it like pruning in bitcoin. Something the size of an omni or counterparty transaction would easily fit in an entry. Now if you store a local copy of the data you need, then the factom data structures give you the ability to provide a proof later on to peers. 1.1 The current target price is about $0.001 per KiB, which equates to $1000/GiB. When the system goes decentralized in the future, it is not knowable what the Federated Servers will set this price at though. 2. It has more to do with a holistic approach to access control. If an element of immutable time is required for access, then it gives sysadmins time to respond to certain types of attacks. 3. two points. a. We expect that communities will share their data subsets amongst each other freely. If property records are secured for some country, then it makes sense for various citizens in that country to download and share up the public data. People share up bittorrent data for free to members of their communities who want their particular datasets. b. This is all public data, and someone will record it. Take centuries old newspapers for example. They can still be found, just not a the corner shop. You would need to go to a library to get it, or maybe pay a fee. I don't think the data will ever go away as long as there is some chance that it may be valuable, but it may be harder to get. 4. Countrywide would sign the hashes before placing them into factom. spam would be unsigned and could be ignored. 5. Paying for upload bandwidth in a distributed way is a really tricky unsolved problem in general. Both storj and maidsafe are exploring solutions to this. Every solution Paul and I explored could be gamed one way or another. If it is as successful as you are claiming, then the inflation subsidy would more than pay for upload services. There is no mining in factom so inflation does not get dissipated in electricity bills. I made some back of the envolope numbers which Paul will present in Miami about how the data is segregated. I guess it isn't really an announcement, just an analysis, so I'll share it here. There are lots of wild guesses here, but it gives you the idea of how it will scale. This is data per year. Assume: 50 million shipping containers, each with 10 entries per year 117 million mortgages with 12 entries per year 5 million mortgage originations/title transfers with 30 entries per year 300 million health records with 10 entries per year 1 stock exchange with 1500 companies with 10 million entries per day each assume 1k per entry. total data in all the layers per year is 26.4 terabytes. The shared part in blue is the directory blocks. This comes to 313 gigabytes. the Entry Credit payment overhead (yellow) is only to prevent spam in the present. it can be discarded by most people, and they can just store the balance info. (think UTXO set vs full chain in Bitcoin) Notice factoids do not even show up on the graph. those are just a way to get entry credits in the first place, and there would be a 10,000-100,000 ratio in EC commits compared to factoid transfers. Only very small subsets of the red Entry Block data is only needed by the applications to prove their states. your application would only need a small sliver of the red. If the annual user data is 19.5 terabytes, you would only need to sift through blue 300 gigabytes to find the data for your application. 5.1 data in factom is separated into chains, which are a clean way to segregate applications and what data you are storing. I imagine in the future, you will only be storing and uploading the data which is important to your application. There are also plans to segment the network, so peers form subnets which only relay some of the data. 6. Because Sibyl. We get advantages from having a predefined authority set. As that set gets bigger it gets harder to manage. Also there need to be few enough of them to matter to vote out. see Dunbars number. 7. yes, sorry, we tweaked the protocol between the whitepaper publishing and launch. They are indeed every 10 minutes. we have a few other mistakes in the paper: https://github.com/FactomProject/FactomDocs/blob/master/Factom_Whitepaper_Errata.md8. Thats where we started out with, but that one party could censor an individual while leaving the rest of the network working. would all of bitcoin switch over to a new network just because the miners were censoring one particular person? the next step is to allow free entry, but then to prove the negative, an application would need to download data from all possible sources, making spam trivial. more thoughts here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-March/007721.html |
|
|
|
Careful -
"This is early beta software you should use this guide at your own risk, we suggest not to use large amount of factoids in case there may be issues and/or bugs."
Indeed, Factom is still an early stage project with no guarantees. factoidpapermill is still early, but has way fewer moving parts than other ways of generating keys. It can also be run on an offline computer booted with a live linux CD then printed or written down. This way when the computer is turned off, all the private key data gets erased when the ram dissipates. walletapp also runs offline. you can try importing the newly created private key in walletapp to make sure it gives you the same public address. Also, the internet is a scary place with hackers and security holes all over the place. Certificate authorities can even be spoofed by men in the middle, so sometimes even you can't trust HTTPS. We are hoping Factom can lay some groundwork for much better internet security, way better than the cobbled together system we have now. It is going to take a while to get to a point where these systems are possible. Bitcoin solves so many more problems in the world other than just moving money. Hopefully it will help make software distribution actually secure. $ sha256sum *
cd245ae20668027b644a0e7175b6c6955c9994e7034cfb30e54497c3d6a0eacf factoidpapermill.exe
f56f10a3ce1643e9f721bd0031d5ee7622a36d1f393af4c8b7ba7f6d089e03d4 factoidpapermill-linux
9eab8daf48c416ef2cce0fc35205cabe6a3644e220d0a218d46a0b080d2f9578 factoidpapermill-mac
We also made walletmgr, which can export the seed used to derive all the keys in the wallet. This is intended to give a paper backup which can be used in a disaster. The disaster recovery software hasn't been written yet, but having the paper seed backup will allow recovery. it doesn't have binaries yet, so you need golang installed to run it. #to install
go get -v github.com/FactomProject/walletmgr
#to run
walletmgr exportseed
|
|
|
|
Thanks , knowing that they are safe now and will be safe in the future is enough for me at the moment , will there be an easier way of withdrawing somewhere in the future , i also do not want to loose any coins in that pretty complicated withdrawal process
If you are going to hold them in cold storage, I would recommend double checking that the balance is what you expect. In computer security there is generally a convenience vs security tradeoff. Here is an inconvenient way of checking your balance, but the most secure. The keymaker app can check balances using an offline computer. It can be done on a cd booted version of linux, disconnected from the internet after downloading the keymaker-linux binary. This way the private key gets wiped from memory on shutdown. you can type the public address manually into a separate online computer. |
|
|
|
Did I have to withdraw my factoids from koinify at some point ?
I have a LOT on there and when i tried checking my balance now the page does not realy load and my balance is not shown.
If someone knows that you can still withdraw and that this is just an error on my end please tell me I am starting to panic a bit here.
when clicking on my wallet it says "The page at koinify.com says: (object Object) and it does not show my balance I googled it and it seems to be something with my browser , did not have this before , what is wondering me that i have the same error on several browsers including on my cellphone.
Thank you for trusting our project with your hard earned bitcoins. At this point, the koinify wallet cannot be used to send factoids. If you purchased Factoids during the April/May timeframe, you should have written down 12 words. That is the only way to access factoids now. If you plan to immidiately send them all to poloniex the import feature there is the most striaghtforward. http://imgur.com/zQ8E34vTo check your balance without handing them to someone else in the process, or to see if you were one of the handful of people that had problems, run the keymaker app. instructions here: http://factom.org/howto and here: https://github.com/FactomProject/keymakerYou can install the gui wallet also, which has directions at: http://factom.org/howto This will allow you to send to bittrex or https://yuanbaohui.com/ as well. If you want to develop apps using your factoids, I would suggest using a sandbox first, as it will help you from losing factoids during the development process. https://github.com/FactomProject/FactomDocs/blob/master/developerSandboxSetup.md |
|
|
|
kodeon.CEO, please check your "MY MESSAGES" tab at the top of the page.
Thank's for the help, now when running the walletapp after running the factomd program, the CLI outputs the following "ERROR Reading config file!" I've tried doing a search on my drives, seems the file does not exist. Is there something I need to do that I'm missing? You can safely ignore the config file error if you just want to use the defaults. If you are doing any development, you might want to setup a sandbox, which would need the config file. https://github.com/FactomProject/FactomDocs/blob/master/developerSandboxSetup.md |
|
|
|
1. The "Factom Federated Servers": Are they somehow centralized? Can I run a Factom node? Is there a process involved in joining the Federation? . Like in bitcoin, there will be different classes of nodes all communicating over a flood fill P2P network. Yes, you can install a node and propagate messages around the network. I think the question you are asking is "Can I run an authoritative node?" as in, can I be a miner. That is a more complicated question. You would basically need to win elections to become part of the federation. Users who purchase entry credits are the ones who cast votes. This is what Milestone 3 is for. 2. If Factoms are like ETH and EC's (Entry Credits) are gas, could an Ethereum dapp serve as a potentially more decentralized Factom? hmm, interesting question. My first reaction is: probably not. The Ethereum VM is really slow, described as "the computing power of a 1990's mobile phone". There will be a lot of data flowing through factom, and I don't immediately see how all the data can be put into factom, and not into ethereum's state too. The whole point of factom is to offload data from the main blockchain. Perhaps with something like zk-SNARK, you can put the proof of honest dealing in ethereum, but the proof would need to extend all the way down to the network card firmware to prove you weren't filtering, and would take 10000x longer than just doing the computation once. Even then, you could probably filter (censor) before it got to your machine. The goal is to make it censorship resistant, which is really hard. The best we know how to do is make it expensive to censor. I haven't though about redesigning factom as an Eth program very hard, but I would love to be proven wrong. 3. There is a Factom chain. If this chain is lost or the network should die is the data on the BTC chain still "useful"? Or to put it differently, does the data stored on the BTC chain make sense without reference to the data stored on the Factom chain? Bitcoin is used in Factom to do multiple things. - Prevent Factom from undetectably rewriting history. The hashpower prevents the Federated servers from erasing history. - Show the users of Factom that the blockchain is not forked. It also provides a sibyl resistant communication amongst Federated servers, and to the clients. All the user Chains in Factom are under the Merkle root placed in the bitcoin blockchain. I think you are referring to the Factom blockchain, though. The Federated Servers (like the miners) are only there to build the head of the blockchain, and to arbitrate between conflicting state changes. The only state changes that the Factom servers arbitrate between relate to Factoids and Entry Credits. After the blockchain is built, anyone can pass it around, verify it, and retain it even if the Federated Servers disappear. This is one of the reasons why it makes sense to run your own node, to make sure you have a copy of all the data. 4. Quote from 'Factom Ledger by Consensus':
Quote
Placing Offensive or Illegal Entries into Factom
Censorship is very hard and perhaps nearly impossible in Factom. No data in the Directory Blocks, nor the Entry Blocks will be plain text. The Entries themselves can contain any information at all, but Entries containing offensive material can be identified and removed from any particular system using Factom. Even though Factom secures such information, that does not mean users are forced to hold the offensive material.
So this might mean that the answer to 3 is No, but more importantly how can information be deleted and who decides what is deleted? If Factom is not censorship-resistant then this poses a problem. Good question. Again, it is complicated, and likely is a nomenclature issue. This is the equivalent of saying something can be deleted from bittorrent. Also, pruning in Bitcoin is a good analogy. If you know about some data on your system that you don't want to retain or serve up, you can delete it from your system. Factom's (and blockchains in general) power is in proving the negative. If a community agrees on the head of the blockchain, then they agree on the history taken to get there. Everyone can examine the same history to arrive at the same state. The problem is that forbidden knowledge may be embedded in that history. The assumption is that this forbidden knowledge doesn't change the application state, but needs to be examined by new entrants to prove it does not affect the state. It turns into an oracle problem at this point. One can imagine an oracle, for example the Illegal Prime Number Detection Censorship Authority (IPNDCA) who scans the blockchain for the forbidden prime numbers. When they find the forbidden data, they would identify it by its Entry Hash and place that into their own Chain. If IPNDCA flags innocuous data, others in the community can present the data and the signed hash showing it was flagged and the oracle would lose credibility. If the forbidden data does affect the state, then the oracle probably needs to be aware of this, and communicate this appropriately. What is more likely is that the forbidden data is there but ignored, like how some forbidden data exists in the Bitcoin blockchain, but doesn't seem to be causing legal troubles. |
|
|
|
|
kodeon.CEO, please check your "MY MESSAGES" tab at the top of the page.
|
|
|
|
I think that Paul's comment on the AMA is getting totally blown out of proportion. Granted, we are calling it Release Candidate 1, which is a bad name. It probably conveys more quality than you should expect. We are working to have the first release candidate of the consensus algorithm by the end of the year. We fully expect to release a few release candidates prior to going into production with the consensus algorithm early in 2016.
THIS
This was not an announcement. It was an internal target to aim at, not something that we expect the community to rely on. This was from an "Ask Me Anything" session. A predictive answer was given, not a binding announcement. Lets make sure we temper expectations. At best we will be showing off a developer preview. It is far from being ready to switch the network over and start using. It will be enough for structures to be built with optimal network communications. It will probably perform poorly with sub-optimal network communications, i.e. on the internet. It is primarily for our internal testing team to have something to start poking at. That being said, now is a good time to start asking for Milestone 2 Community Testers. Please email me at brian@factom.org if you would like to help test Milestone 2 Release Candidates. The complexity to get it installed is probably about as difficult as this one for Milestone 1: https://github.com/FactomProject/FactomDocs/blob/master/communityTesterDirections.md |
|
|
|
|
Show Posts
