Storj (pronounced: storage) aims to become a cloud storage platform that can’t be censored or monitored, or have downtime. Storj is a platform, cryptocurrency, and suite of decentralized applications that allows users to store data in a secure and decentralized manner. It uses blockchain features like a transaction ledger, public/private key encryption, and cryptographic hash functions for security. Furthermore, it will be way cheaper (10x-to-100x), faster, and more secure than traditional cloud storage services.

Storj is working hard to solve data security issues with the help of its own web app, MetaDisk, and client app, DriveShare. It is the first decentralized, end-to-end encrypted cloud storage that uses blockchain technology and cryptography to secure online files. There is no need to trust a corporation, vulnerable servers, or employees with your files. Storj completely removes trust from the equation.

To best protect your data, files are encrypted client-side on users’ computers before they are uploaded. Each file is split up into chunks which are first encrypted and then distributed for storage across the Storj network. The network is comprised of DriveShare nodes run by users around the world who rent out their unused hard drive space in return for Storjcoin X (SJCX).

The decentralized aspect of Storj means there are no central servers to be compromised, and because of the use of client-side encryption, only the end-users have access to their unencrypted files and encryption keys.

Storj is a cloud storage platform. The key word in that sentence is ‘platform’ because without it, Storj would just really be a decentralized cloud storage alternative. While a decentralized cloud storage alternative in itself would still be a great product, what we are creating goes beyond that.

Storj allows users to create decentralized applications. We have already begun to see basic demos using the MetaDisk API and pulling content from the network, including an image viewer, a .txt and .pdf viewer, a music player, and even a video service. Some of these services have even been thrown into a Storj Media Center of sorts.

Our corporate entity Storj Labs aims to bring decentralized cloud storage to the average business and consumer. With constant data breaches and high costs, users are becoming more aware that the current model of cloud storage is broken. Storj Labs provides DaaS (Data-as-a-Service), as well as help building tools and APIs for customers to be able to interface with this new cloud storage model.

Please send an email to fund@storj.io to learn more about investment opportunities.

The Community Funds are for rewarding community members for their contributions to supporting Storj. These rewards take the form of bounties, payments for specific tasks, and giveaways!

The Developer Funds are used for payment as salary, tips, and bonuses for full time and volunteer contributors to the project.

Yes. We do not require user accounts or personal information to use the platform.

The crowdsale funds are used for:

• Reimbursement of prior expenses

• Salaries for full time contributors and payments to freelancers

• Further development of Metadisk, our web application software

• Development of DriveShare, our storage and bandwidth renting software

• Research and development for the protocol, applications, and blockchain technologies

• Marketing, advertising, media, and articles

• Community Funding

• Legal counsel

The tokens were distributed in the following proportions:

• Bitcoin Sales - 70% of coins

• Developer Pool - 15% of coins

• Community Pool - 15% of coins

MetaDisk is our first application. It allows people to upload files to the network. DriveShare is our second application. It allows people to share their hard drive space with the network.

People running the DriveShare client will never know what files they are hosting, nor will they be able to access them. The person uploading files to the network will be responsible.

MetaDisk is an open-source file sharing app that is based on a decentralized network of nodes and is the first application built on top of the Storj platform. These nodes are all around the world and act as a network to host all of the data that goes through MetaDisk.

Each file is shredded, encrypted, and then distributed across the network to achieve maximum security. Only the original uploader of the files has the private keys to decrypt and open them.

MetaDisk is our end user application that allows users to store files on the network. With MetaDisk you will be able to store, download, and share all of your files securely.

Yes, you will be able to remove files from the network. A very simple way to do this will be to stop paying for the storage of the file.

You will be making small microtransactions to maintain the storage of your file and to access it. These payments will be small and made over time.

You probably wouldn't stream directly from the farmer. More likely a MetaDisk-like node will proxy from the farmer, cache it on the server, then serve from there. This is sort of what the current MetaDisk nodes do. If it's not in cache they will pull it from the network, and charge for the resources used.

We're also examining the feasibility of other payment models. For example, a website distributing a podcast may be able to purchase download credits for other users. Research will be done during the upcoming beta test to determine the most convenient and effective distribution methods.

Users will not need to specify storage duration upfront. You will be making microtransactions to maintain the storage of your file and to access it, so your file will remain in the network until your payments stop.

This is currently not possible, but eventually we will be able to integrate with other projects like Ethereum, which will be able to create, enforce, and allow modification of smart contracts between users and nodes.

Yes, users will be able to set the level of redundancy they feel comfortable with.

Yes, you will be able to adjust your redundancy level. The network will then upload the files to the required number of farmers.

You could use our API to build your own application on top of the network and allow people to host files and build your own business!

Yes. Your files will be encrypted, copied, and distributed around the world, rendering them immune to censorship and natural disasters.

DriveShare is an open-source application that allows users to rent out their excess hard drive space in exchange for SJCX. This software works in conjunction with Metadisk. Those running Driveshare will act as decentralized cloud storage nodes for the network.

Drive Farming is the term used to describe the act of selling or renting out extra hard drive space. This is most comparable to traditional crypto-currency mining. Users allocate a portion of their available hard drive space and specify a folder on their drive to store network data.

This space stores small encrypted shards of MetaDisk users’ files. This means that no farmer holds the entire file that a user uploaded, and, because of the encryption, they couldn’t read it anyway.

If someone attempts to access and alter the files that they are storing, the shard will fail the next challenge issued by the owner of the data. This will result in the malicious node being dropped, and the network will select another location to store the shard. And of course, the network doesn’t pay cheating nodes.

Much like Drive Farming, Bandwidth farming is a key part of DriveShare. Users can allocate a defined amount of bandwidth to Storj and therefore will be able to download and upload files at their desired speed.

All the nodes working together act as a torrent-like network, which will minimize slowdown and keep service quality high.

With Bitcoin you mine; with Storj you farm. It's not exactly the same thing as mining BTC or LTC with ASICs or GPUs. By “farming” we mean sharing your unused hard drive space through our DriveShare app.

The simple DriveShare GUI will allow you to specify how much storage you want to share, add an SJCX address for payments, and specify a MetaDisk node to use.

Then, when people upload files via MetaDisk, if your node is online, you will start getting file chunks hosted on your HD and you will get a reward for them.

There are a few variables that could make the number of hosted chunks on your shared storage (and thus your expected rewards) higher or lower:

• Size of shared storage

• Upload and download bandwidth

• Reliability and availability of your DriveShare node

• Demand for storage

We are not implementing farming pools. However, farming pools could exist if one or more nodes running MetaDisk or an application that uses the MetaDisk API are set to use specific DriveShare nodes for storage. The same is true if a number of DriveShare nodes are set to use a specific MetaDisk node to get file chunks/contracts. Consider that anyone could be running a MetaDisk node as well as a DriveShare node.

Our code is Open Source and we expect people to play with it and customize it to their needs, so yes farming pools could be an option.

Since Storj is a decentralized network, the price of data storage will ultimately be determined by market forces. Farmers will compete to win the business of users, and users will only agree to prices they find competitive. MetaDisk will make it a simple process for users to find farmers at competitive rates.

Although the exact market price cannot be predicted at this time, the decentralized model of Storj will likely offer better rates than are currently set by conventional cloud storage providers for a similar amount of storage.

Your upload speed will severely limit the amount of data that can be stored or served by you in a timely manner. The problem comes when you have contracts for stored data that expire, or when your storage system goes offline and you lose those contracts and the data is deleted. Your system then has to re-fill terabytes of data on a slow line. In addition, if your node can’t upload data in a timely manner on request, you may lose contracts or be dropped from the network.

While DriveShare doesn’t offer a “donate” option, you could share your available space for a nominal amount of SJCX. If you charge just enough to cover the cost of your electricity, you essentially offer it to the network for “free.”

Because Storj provides secure zero-knowledge encrypted storage, it’s not possible to know what type of data is being stored. However third-party service providers, developers, and apps wishing to utilize the Storj network can restrict the types of files and uploads that maybe stored on the network through their front-end.

No. To protect against node failures and downtime the Storj network defaults to three redundant storage nodes. If you manually lowered the number of nodes storing their files to a single node, then your file would be inaccessible until it came back online.

Also, if your files are stored with multiple nodes and one goes offline, the Storj network will automatically find another node to take over the open contract so your files continue to be available.

Not at all. The Storj network breaks every file up into very small chunks that could be distributed to dozens of Storj nodes for hosting.

Just as with other peer-to-peer networks your computer only needs to retrieve that small chunk from each host which can be accomplished very quickly, no matter how low the bandwidth of an individual node.

The network will route around your node, and drop your contracts. Another node on the network would retrieve the data from the redundant nodes that the owner has contracted with, and you will lose the contract to store the affected data.

You will be paid for the period of time that you provided the storage space to the network. When your storage goes offline, you will start to fail network challenges. After a certain number of failures, your contracts will be revoked and distributed to other nodes.

Ideally, this would require an upfront investment of a couple hundred dollars to purchase a dedicated network attached storage device such as the Synology DS213air or DS214se.

These can be plugged in and run 24/7 with up to 2x1TB - 6TB drives. Adding a small, inexpensive 400W+ Cyberpower or APC UPS Battery backup could also improve uptime during power outages.

This is a very simple and efficient setup for the average user, but please make sure to verify DriveShare compatibility with any NAS you wish to purchase on StorjTalk.

Yes you can, any disk drive that your operating system (Windows, Mac OS, Linux) recognizes as an attached drive can be selected from within the DriveShare application.

Crowdsale participants get exclusive access to early farming software and applications.

There will be 3 Test Groups:

• Group A Crowdsale participants holding over 10,000 SJCX - Not Rewarded

• Group B All crowdsale contributors & new participants (more info) - Rewarded

• Group C Anyone holding 10,000 SJCX* or more - Rewarded

*Details are subject to change.

SJCX can be purchased at any time and be added to your address balance to be able to qualify for Test Group C. Also your original crowdsale address can be topped up to and over 10,000 SJCX to be eligible for Test Group A.

“Not Rewarded” means Group A will only be helping with testing and will not earn coins for sharing their storage. “Rewarded” means you will earn SJCX to share your unused storage during beta testing (Groups B and C).

Make sure you use an SJCX or Bitcoin address where you control the private keys, we do not recommend using an address from an exchange. We will need to verify you actually own the address before you are allowed to be a tester.

Learn More

You can find the latest client release and more details on https://github.com/Storj/dataserv-client/releases/.

Please follow the instructions provided on https://driveshare.org/dataserv.html.

CONFIG: The config command is currently only run once when you first run dataserv-client (ie, starting from 0 without previous build). Currently only one argument, --set_payout_address is necessary. Config will create your config.json file which will include your payout address, your private key/wallet address and the version of the client under which is was created.

FARM: The farm command is a compilation of multiple commands and currently serves as the primary command in the dataserv-client application. Farm includes the functions register, build and poll, run in that order.

dataserv-client --store_path --max_size farm

REGISTER: The register command is no longer used in dataserv-client except as a component of the farm command. Register communicates with the server your payout address and authentication address, linking the two together and setting the date that your build started. This is the point where you payout address is linked to your auth address and you wallet address. Your payout address and wallet are the seeds for you auth address (ie a single config.json will always create the same auth address)

BUILD: The build command is a testing command and will likely play no role once peer-to-peer data transfers begin. In the tests, build is the engine that creates shards (SHA 256 hashes). Build includes periodic pinging of the server with your current height. By default, build pings the server every 25 shards with your current height. Once the build is finished (reaches --max_size) build will report your final height to the server.

POLL: The poll command is a simple ping of the server to tell it that your build is live and being shared on the network. Poll does not tell the server your height but reports that you are live. The height that is reported is the last height reported by build. Poll can be run independently when desired to stay live on the status page during farm command with high –set_height_interval

Rewards have been implemented during the testing process of the Storj applications. Rewards will be advertised but the breakdown and rules governing are subject to change as the project evolves. Rewards are present to provide motivation/incentive for participation in the tests. Rewards are NOT payment for testing. Rewards are NOT equivalent to mining rewards.

At the present time each payout address must have a minimum of 10,000 SJCX to qualify for rewards and upon request any address that was not affiliated with the crowdsale, will have to have 10,000 SJCX donated to the rewards pool to qualify for future rewards. There is NO guarantee of rewards equaling or exceeding the 10,000 SJCX donation.

Rewards are calculated using a fair methodology that looks at available data at the time of snapshots such as capacity and SJCX holdings and via server tracking of data such as duration of registered address, uptime and audit success. The criteria and timing of rewards snapshots or tracking will be advertised in advance.

That’s easy, just follow all the instructions regarding running the client and ignore instructions about funding your payout address. You still want to set up a counterwallet address as there may be rewards issued that are not tied to SJCX holdings. You wouldn’t want to miss out. Also, once Storj goes live, you will need to have a payout address that you have control over the private keys.

There is no requirement for holding SJCX just to participate in the testing, only the rewards are tied to SJCX holdings.

At this stage in testing and until peer-to-peer data transfers are tested, dataserv-client locally generates empty containers, inflated to 128MB (friendly size) each. These empty containers are “shards”. The build portion of the farm command will create a predetermined number of shards based on your --max_size setting. Shards are encrypted using SHA 256 hashes. Each shared hash is created determinalistically based on the seed. At the present time that seed is your payout address. In the future, there may be an option to create shards using your auth address as the seed (please stay tuned for that option and how to utilize it).

What deterministic shard/hash creation means is that any build using a specific payout address will create the same shards in the same order. While not tested, multiple builds to the same payout address may pose issues with the audit function. It is therefore advised that multiple builds be created to different payout addresses.

Your height, as reported at https://status.driveshare.org/api/online/json is based on the number of shards that you are reporting live to the server (read build and poll definitions). Only the shards that have been reported to the server by the build function and then reported as live by the poll function will appear in your height.

The storage capacity reported on https://driveshare.org/status.html is a derivative of your height. The current calculation uses the friendly 8000 shards per TB (800 shards per 100GB, 8 shards per GB).

The friendly method of determining drive size or file size is by multiplying by 1000 (ie 1KB = 1000 bytes). In actuality, the real multiplier is 1024 (ie 1KB = 1024 bytes). The same ratio is always present. 1TB =1024 GB, 1GB =1024MB, 1MB = 1024KB. The confusion that often happens is when both friendly and actual sizes are referenced together, or when a friendly size is referenced and the means of checking said size use actual bytes.

For the purposes of Storj and the DriveShare test groups, both have been used. 128MB, the size of a shard, is referenced with a friendly file size (actual size is 134,2117,728 bytes = 128*1024*1024). The current display on the status page also uses the friendly method to display capacity. Formerly, the status page did display actual capacity. As mentioned above the number of shards divided by 8000 will give your friendly size, however, number of shards divided by 8192 will give you your actual size.

Further complicating this file size/drive capacity issue is the fact that many OSs and external drive devices will hold a certain amount of drive space in reserve (buffers, error protection, etc). This space isn’t visible to the user and should not be utilized (it is there for drive health).

PAYOUT ADDRESS: A payout address is an address that you set in the client and should be your counterwallet address (https://counterwallet.io or https://counterwallet.coindaddy.io). You will need to transfer your funds from any exchange to your counterwallet address.

IMPORTANT NOTICE: TO ENSURE ACCESS, SJCX HOLDINGS MUST BE HELD IN AN ADDRESS FOR WHICH YOU HOLD THE PRIVATE KEY. COUNTERWALLET IS THE RECOMMENDED SITE AND EXCHANGE ADDRESSES ARE STRONGLY DISCOURAGED. STORJ LABS IS NOT LIABLE IF YOU LOSE ACCESS TO YOUR FUNDS OR THE DRIVESHARE CLIENT/SERVER.

Your payout address is currently the seed for the SHA 256 hashes/shards.

It is your payout address that will be tracked for rewards purposes and should be an address that you control. Your payout address is what you will see on the status pages and how you can track your progress/standings https://driveshare.org/status.html or https://status.driveshare.org/api/online

Rewards are an incentive provided by the developers of the Storj project to encourage participation in the testing process and should NOT be considered a form of payment or a form of return on investment. Rewards are NOT guaranteed. The structure of, timing of and amount of rewards are subject to change during the testing.

Qualifying for Rewards – Step 1:

To qualify for rewards the first step is to possess 10,000 SJCX in your payout address. Compliance with this requirement will be tracked through http://blockscan.com and in order to ensure that you are compliant it is advised that any transactions be made 24 hours prior to any deadlines, snapshot or donations request to ensure that the transaction will appear on the blockchain.

Qualifying for Rewards – Step 2a: Crowdsale Participants

For those that participated in the Crowdsale, simply holding 10,000 SJCX in your payout address will qualify you for full rewards. Holding >0 but <10,000 SJCX will qualify a Crowdsale participant for partial rewards. The fraction of full rewards will be determined by the developers, but will be a maximum of the percentage of 10,000 SJCX held.

Qualifying for Rewards – Step 2b: Non-Crowdsale Participants

For non-crowdsale participants there will be a request for donations prior to TGB M3-2 (test group b, milestone 3, part 2). Prior to this request, qualification for rewards is the same as for crowdsale participants. Once the request is made, qualification for rewards is dependent on a donation of 10,000 SJCX to the rewards pool. There will be a window to donate prior to the commencement of TGB M3-2 testing & tracking. There is NO partial rewards for non-crowdsale members. A donation entitles a non-crowdsale participant to full rewards based on their stats.

A non-crowdsale participant does not need to both donate and hold 10K SJCX during TGB M3-2 to qualify for rewards. Only the donation is required for rewards qualification.

There is NO guarantee that any participant, crowdsale or otherwise, will receive 10,000 SJCX (or any amount for that matter) in rewards during TGB M3-2

Policies have not been announced at the present time as to requirements for holding or donations for future test groups. Once announced, this information will be updated. Any statements about these policies are unofficial or speculative until announced officially.

We are not paying farmers at the current time. Storj is currently in development, and running Test Group B, which issues rewards in SJCX. When Storj and its component programs are live, each farmer will be able to decide how much to charge for their services, creating a competitive marketplace.

The rewards given to people who participate in testing are NOT a form of payment, and no guarantee of earnings can be given at this time.

One million SJCX will be distributed for Test Group B. As of January 21st, 2016, 600,000 of these had already been granted. You can look at the data of the rewards to Test Group B here. (All rewards data will be made publicly available like this.)

You can inspect the mathematical formula used to compute rewards here.

An audit is a validation process that looks at the shards you have in your --store_path and ensures that A.) the SHA 256 hashes match the payout address (seed) and B.) all the hashes that should be present are present (read build definition). To be a valid build, shards/hashes must pass audits. Audits will be a part of TGB M3-2 and moving forward.

Once live peer-to-peer data transfers start, audits will be used to verify that all data a given address is “contracted” to hold is present. Failed audits may lead to loss of contract and profit in a live launch scenario.

First, during the testing process, data is locally generated and the only network traffic is from your client to the server (pings). That means that you need to be actively running farm (or farm with high --set_interval_value and a separate terminal running poll) to show up on the status pages.

Once live peer-to-peer data transfers start, audits will be used to verify that all data a given address is “contracted” to hold is present. Failed audits may lead to loss of contract and profit in a live launch scenario.

• https://driveshare.org/status.html - shows payout address, when you last pinged the server & capacity in TB (height/8000) - User Friendly Version

• https://status.driveshare.org/api/online - shows payout address, when you last pinged the server & your height (number of shards)

• https://status.driveshare.org/api/online/json - shows payout address, auth address, when you last pinged the server & your height (this json actually drives the information of the other sites)

• http://storjtracker.com - shows your payout address, when you last pinged the server, your verified SJCX holdings & your capacity in GB (this page was created by linuxman21)

Efforts have been made within the dataserv-client to automatically restart build and poll functions, but there are times when an error causes the program to stop completely.

Unsanctioned approaches can be used to restart the dataserv-client in these cases. They include batch files with repeating loops (there is currently a set of windows batch files pinned to #test_group_b on Slack), including either batch file or fully arguemented command string in your operating system startup, StorjTrackr which can help you to monitor your build(s) https://github.com/jaylagorio/StorjTrackr/releases and a GUI currently in early testing https://github.com/Storj/driveshare-gui

In the future some of these features may be added to the client, but at this time, you use such unsanctioned approaches at your own risk/benefit. Storj Labs and the developers will not guarantee the functionality of any approach and base all rewards distributions on available and verifiable data (ie, saying you were online or had SJCX is not verifiable and will not be considered proof).

WARNING dataserv_client.messaging 57: HTTP Error 401: UNAUTHORIZED

INFO dataserv_client.messaging 78: Query retry in 30 seconds.

While not always the case, many of these 401 Unauthorized errors are associated with your local clock being out of sync with the server clock. For security reasons, the current server-side application only allows a 15 second offset from the ping time to the time that ping is received. In typical situations, pings should take only milliseconds, but if clocks are not synced, this time can appear much larger.

To resolve this issue, you should take measures to sync your clock with internet time (methods vary and you should research your specific operating system to ensure that your clock is synced). It is possible, over time, for a synced clock to fall out of sync with internet time, so either this process will need to be repeated or periodic syncing done via software.

There are two different sets of communications you should be looking for to check for proper functionality. If you are seeing this, then you are running properly.

During build portion of farm (hashes vary at each step):

INFO dataserv_client.builder 108: Resuming from height 116977

INFO dataserv_client.builder 131: Saving seed 56793d6abb4598Udjec379d65f1dfb1d352d11d3111358a35b99cbd9f94f35 with SHA-256 hash 636a241bcf263f91e63739523dc6cd6abb45b8735466e0b1885f1dec15abea.

INFO dataserv_client.builder 131: Saving seed e207af815ca541cd6abb45e832806f6c4128f9ed2a5230616a581d300d29e32a0 with SHA-256 hash a66d648dc69afb01bda363c1cd6abb45b2f62110a0c15468cbafc4780b2c827d.

During poll portion of farm:

INFO dataserv_client.api 200: Build finished

INFO dataserv_client.api 135: Pinging server 'httsp://status.driveshare.org' at 2015-09-20 21:16:16.

INFO dataserv_client.messaging 43: Query: https://status.driveshare.org/api/ping/<auth address appears here>>

INFO dataserv_client.api 135: Pinging server 'https://status.driveshare.org' at 2015-09-20 21:17:17.

INFO dataserv_client.messaging 43: Query: https://status.driveshare.org/api/ping/<auth address appears here>>

Many errors will not cause the program to stop but will timeout for 30 seconds and try again. If your terminal returns to the command prompt, you should check the last error and either find a resolution at one of the available resources Github or Slack.

During testing, the simple answer is no. Since we aren’t dealing with any real data and network traffic is minimal (outbound pings only), adding redundancy such as RAID 1 or 5, will only reduce your capacity and not provide any real benefits to you. All files are locally generated during testing (to-date) and once your build is complete, drive activity will be drastically reduced.

Once testing progresses to a point where there is actual data being shared, the question become a bit murky, but redundancy still may not be worth the loss of capacity. Depending on the structure and network activity expected during later testing phases, you might want to start considering local redundancy.

Once Storj does go live, there will be redundancy at a network level, with multiple farmers holding each shard. That redundancy protects the user’s data but doesn’t protect the farmer from drive failures or data corruption. At that point, local redundancy may be appealing but is a decision that must be weighed against storage capacity loss, likelihood of drive failure, drive activity, and many other variables. For those with large amount of storage and high demand clients, it might be beneficial to have local redundancy to protect your investment.

The easy answer here is yes, it is possible to farm/build to multiple paths using a single payout address? The caveat to that statement is that at the present time, only the largest of those builds counts toward your rewards (this may change in the near future).

In order to build to multiple paths, you will need to create two separate builds. There are two basic methods for doing this.

1. Farm/build from two separate computers to two unique file paths

• Run datasev-client normally from both computers, starting with:

1. ‘dataserv-client config --set_payout_address <your counterwallet address>’ (first time only) then;

2. ‘dataserv-client --store_path <your path> --max_size <your size> farm’

2. Farm/build from the same computer to two unique file paths (not on the same drive)

• NOTE: This is the same method you would use if you wanted multiple builds from the same computer but pointing to different payout addresses.

• Run dataserv-client with --config_path <your complete path including file name> as the first argument in ALL command lines

1. In Windows: C:\users\<username>\.storj\

2. In Linux: $HOME/.storj (e.g. /home/<username>/.storj)

3. In Mac: home/.storj/config.json (e.g. <username>/.storj/ (.storj may be a hidden folder)

• You path should end with something like configX.json, where “X” is a unique identifier for each build. You can use the same folder path for all .json files, but to avoid overwriting, the “X” must be different.

• Run through each config and farm command separately and run them simultaneously

1. FIRST PATH X: ‘dataserv-client --config_path <your full path/configX.json> config --set_payout_address <your counterwallet address>’ (first time only) then;

2. FIRST PATH X: ‘dataserv-client --config_path <your full path/configX.json> --store_path <your path X> --max_size <your size> farm’

3. SECOND PATH Y: ‘dataserv-client --config_path <your full path/configY.json> config --set_payout_address <your counterwallet address>’ (first time only) then;

4. SECOND PATH Y: ‘dataserv-client --config_path <your full path/configY.json> --store_path <your path Y> --max_size <your size> farm’

• The use of a batch file our other automated method can be beneficial to avoid leaving something out or accidentally running the wrong configuration to the wrong folder.

Either method you use, each build will have the same payout address, but unique auth and wallet addresses. Each build will show up separately on the stats page. Each build will have exactly the same files in the same order per the deterministic build method used in the client (payout address is the seed).

There is currently no support for a single farm/build command to multiple paths. To utilize multiple physical drives on a single build, you will want to use JBOD (spanning), RAID or other multi-drive implementations in your OS prior to starting dataserv-client.

Deleting all of your shards and starting from scratch is a last resort measure. Unless it is absolutely needed, you shouldn’t do it. It takes time and you would just be recreating the exact same files that you already created once.

There are some instances when rebuilding from 0 is absolutely necessary, some obvious but some are specific to the way farm works.

1. MOST IMPORTANT REASON: If you change your payout address for ANY reason (want to use different counterwallet, didn’t use your payout address to start with, forgot to set payout address, etc), you will need to farm/build from zero shards. Your payout address is currently the seed for all hash creation and if you switch this number, the shards you have won’t match the seed and will be ignored, wasting drive space.

2. If you drive fails and you no longer have access to all the shards that you created, you may need to start over on a new drive. A shard repair function is scheduled to be in the next release and this may assist with missing shards, allowing you to continue without rebuilding.

There are more often situations that DON’T require a complete rebuild. The following are issues and scenarios that do not (typically) require a complete rebuild.

1. Your farm/build crashes in mid-process

2. You change your store_path (you can just copy the files in the old location to the new one before you restart farm)

3. You get errors. (the vast majority of errors will not require a rebuild)

4. You change your max_size.

5. You aren’t showing up on the status page.

6. You upgrade your client to the newest release (recommended). EXCEPTION: If there is a request/recommendation that you rebuild from zero.

7. You have shards that aren’t 128MB. The next release of the client will have a repair function built into farm.

We do not condone the use of illegal content on our platform, but the nature of the platform prevents us from having any control on what is stored or shared by users. We believe decentralized technologies will have a lasting, positive effect on society. However, such technologies can only flourish in the long-term if they work within and evolve with a society’s legal and ethical norms.

This can be made possible through shard graylisting. Anyone could make a graylist indicating the unique hash of a shard that is associated with certain decrypted content. Then, the farmer could decide to opt-in to such a graylist if they don't wish to be party to distribution of such content (e.g. child exploitation, violent terror videos, etc.).

The only way a shard could be associated with its decrypted content is if someone publicly distributed the download information and the decryption keys, thus giving up the privacy of the content to make it publicly accessible. Content that is kept private will always be private. When someone posts the download information and the public keys online for mass distribution, they are voluntarily giving up the privacy of their content by letting the public at large be able to access it and decrypt it. Hashes and keys are completely different things. Deriving the hash of a file or a chunk in no way allows you to determine the contents of the chunk.

For someone to put something on a graylist, you'd have to know how to download all the chunks, how they were encrypted and have decryption keys to see what content was. If a farmer only has a small chunk of an encrypted file, let's say, then even if you had the keys you would not be able to decrypt unless you had all the chunks and knew how to reassemble them and in what order. So users could share ANYTHING they want because it's private. But if they post it on a message board then it can be greylisted.

No, graylists will always be opt-in and users can choose which greylist the follow. Greylisting does not remove the file from the network. Since it is content driven, a user may want to honor an ISIS video beheading greylist, but not follow Snowden leak greylists. You can't greylist a file that you don't know the encryption key to.

No, graylists are an optional feature available to individual DriveShare operators to enable. Furthermore, graylists will be created by individual users, not a central body. All greylists must be public and open. If someone abuses a greylist, that list should be forked.

Some people may be wary of allowing obscene or violent content to be hosted or distributed through their nodes. Some people have to realize that there needs to be a shift in belief on all sides for us to make widespread use of decentralized tools a reality. There are institutions and organizations that have only ever known and felt comfortable with top-down, centralized methods of enforcement or management. What we're offering is a completely decentralized way for folks to be empowered and follow their own ethics and beliefs. If you disempower people entirely, they may become afraid and try to lash out with centralized hammers (e.g. outright bans, etc.).

We have to realize that not everyone in the public, etc. share our beliefs and you could imagine that the MSM could easily paint a picture that the network allows terrorist, CP people, etc. to share with impunity and ease. Those kinds of things are like a dare to regulators, and then basically you leave it to them to try and come up with ways to stop what they think is wrong. They usually don't care as much about decentralization, so their "solutions" are usually broad and heavy. It also creates an "us vs. them" mentality. By coming up with a decentralized solution that doesn't violate the values of the project, it helps people with different beliefs feel more comfortable

Because graylist subscriptions will be distributed and managed by peers, can change over time, and are only relevant when file shard contracts are declined, it is impossible to verify that a given node subscribes to any graylist. A node could hypothetically broadcast what graylists it subscribes to, but given the decentralized nature of the network, there's no guarantee that that information would be accurate.

There is no singular greylist. There will be many graylists with different content categories. For example, one might be for snuff while the other might be for beheading videos. For example a user running a MetaDisk gateway node and a farmer doesn't want people watching ISIS beheading videos on its node, totally cool with distributing Snowden leaks. He also may not want to deal with video distribution and DMCA request so he disables that too. For any other traffic happy to route that, and get paid his bandwidth fees.

At the end of the day users will be providing a service, and they get to choose what service they provide. They could follow US law and collect their fees. But perhaps someone more legally open in Sweden, will open up their gateway nodes to any content. Users will be able to control their nodes as they feel more comfortable with. If AirBNB for your hard drive is an apt analogy, someone may not want to accept a drunken junkie into their home. But they are more than welcome to. So why force them to do it?

SJCX is a token that allows you to purchase storage or earn money for renting your free Hard Drive space. SJCX is a Counterparty asset that uses the Bitcoin blockchain for its transactions.

There are currently 4 different exchanges where you can buy SJCX:

• ShapeShift

• Poloniex

• Counterparty

• Bittrex

We have a supply calculator here. This will show you exactly how many SJCX have been released at the moment you check. It is updated in real time.

There will ever only be 500 million SJCX; no more can be created. SJCX is a locked asset on the Counterparty protocol, more info can be found here.

Yes. You can read more about this here.

Many users coming from the Bitcoin space ask us why we created a new token named Storjcoin X (“SJCX”). There is a mix of technical and economic reasons why we felt a new token was needed. SJCX is built with Counterparty, which uses the Bitcoin blockchain. We have plans to implement Bitcoin in the future when Storj is more stable (ideally using sidechains).

1. Bitcoin is too Expensive - For standard storage providers 1 GB of storage goes $0.03 per month. So what if I want to store 1 MB and do payments every hour? Each payment would be $0.000000042. One satoshi, as of time of writing, is worth $0.0000037. This means Bitcoin would place some economic restrictions on the network.

2. Micropayment Lockup - We plan on using micropayment channels, which require locking up coins on the blockchain for the duration of the channel. We would much rather lock up lots of SJCX, than hundreds of thousands of dollars worth of Bitcoin while we’re still testing the protocol.

3. Economic Isolation - Bitcoin price fluctuates heavily for a wide variety of factors. Currency volatility can directly impact the profitability of nodes, and cause problems for the network. Having a separate token that is transacted widely within the network, but has little interaction outside the network, more directly ties currency price to network health.

We are using the Counterparty protocol which means coins are created not mined. We created 500M SJCX, then locked the token. No more SJCX can or will be created. Around 10% of these have been released to the public via crowdsale and other methods.

The funds are currently held in a multisig address controlled by Storj Labs Inc. We have followed, and will continue to follow, the guidelines of usage set by the crowdsale terms.

While we lack the technical capability to prevent the sale of SJCX wallets/addresses, we do not condone this. Selling a wallet means sharing your private keys with another individual. Sharing your keys permanently damages the privacy of that wallet as there is no way to revoke the original owner's access. The original owner will still be able to move funds from the wallet at any time in the future.

In addition, we will not change the posted SJCX address whitelist for any reason unless an original crowdsale participant--eligible for testing rounds A/B--was mistakenly left off.

Crowdsale Start: July 18, 2014 at 08:00:00 AM EDT

Crowdsale End: August 18, 2014 at 23:59:59 PM EDT

Terms

We reserve the right to have more crowdsales in the future to fund new projects and ideas, and support development of ongoing projects.

Not at the moment. We will make announcements well in advance when we decide on further projects. We continuously discuss ideas both within the team and with our community on our forum, and on our social media channels.

If you think you have what it takes, you can submit your interest by filling out our form here. We are always looking for talented volunteers. We do check all submissions and will get in touch if we need your skills. The next team member could be you!

Our typical policy is that anyone who wants to freelance, or be part of the Storj dev team must put in useful pull requests on our GitHub, before we consider working with them. There are plenty of repos and open issues to look at.

This is not a guarantee for employment, but we found that people who were excited about building the open-source tool-set perform exponentially better than the people we hired directly. If you have any questions on our repos or how things are built, we would be happy to invite you to our developer chat so you can ask the team directly.

For your code to be merged, you have to agree to our CLA

The Storj team is distributed around the world, we pride ourself for having staff from different cultural, social, and educational backgrounds with a shared passion for our goals. The tools we use to collaborate allow anyone in the world to contribute to the project.