Sia Coin Updated details

  • What is Sia?

    A storage marketplace enabling buyers to rent space from sellers with extra disk space

    Made for Developers

    Sia was made to be integrated as your storage backend. You only pay for the storage you use, and there is no commitment. Get started with our API Quickstart Guide .


    Sia is a decentralized network consisting of many nodes around the world. Data is stored redundantly on a diverse subset of these nodes, meaning there’s no single or central point of failure.

    Competitively Priced

    Sia is a storage marketplace. The price of storage on the network is determined by the free market equilibrium, often well below the price of centralized storage. Compare Sia to other storage solutions .

    How Sia Works

    Sia is an actively developed decentralized storage platform. Users all over the world contribute disk storage from their computers to form a decentralized network. Anybody with siacoins can rent storage from this network, and hosts are

    paid for their contributions. A combination of smart contracts, erasure coding, and encryption ensure secure, private, and reliable decentralized storage. You can download and use Sia today!

    A smart contract on the blockchain ensures through the use of cryptographic proofs of storage that hosts are only paid if they keep the file for the entire duration of the contract. Employment of erasure codes such as Reed Solomon codes

    guarantees high file uptime even if most of the hosts on the network are unreliable or have frequent outages. All data is encrypted client-side and padded, preventing hosts from snooping the contents of the files and even from guessing what

    the file might be based on the filesize.

    The distrubuted nature of the Sia network enables many optimizations in latency, throughput, reliability, and security. The decentralized nature of the Sia network enables anyone with storage to get paid, lowering the barrier to entry and

    reducing the overall price of cloud storage.

    The Technology

    The foundation of Sia is a proof of work blockchain. Storage contracts are a new type of transaction that get enforced
    by the blockchain. Sia's hashing algorithm is blake2b. p2pool and multisig wallets are both supported on Sia.

    When a file is uploaded to Sia, a storage contract is created containing the Merkle root of the file, a reward for the
    host, and a penalty for the host (both in siacoins). After an agreed-upon duration, the host is required to prove that
    the file is still available by providing a random Merkle proof. If the proof is valid, the host is rewarded; otherwise,
    the host is penalized. Random numbers are generated deterministically using the most recent block as a seed.

    Sia has support for two way payment channels, and two way contract diffs. Among other things, this provides massive
    scalability, and eliminates the need for untrustworthy 0-confirmation transactions. Once you join a payment channel
    network, all transactions within that network will be instant and final, with no risk of a double spend.

    Reliability is achieved by using erasure coding in a massively distributed environment. Erasure coding allows a file to
    be split into many pieces, such that the original file can be recovered using only a few of them. For example, you can
    take a 50 MB file, break it into 200 pieces that are 1 MB each, and then you can recover the original file from *any* 50
    of the pieces. This method has the same overhead as creating 4 complete copies of the file, yet is much more reliable
    because it's much less likely that 151 out of 200 hosts will go offline than it is that 4 out of 4 hosts will go

    As the network grows, we will apply statistical analysis to determine the redundancy required to provide 99.9999%
    reliability on files. It is likely that 3x overhead is absurd overkill, and statistical analysis will give an accurate
    picture of how much overhead is required.

    Using 200 hosts to store a file means that downloads can be massively parallel. Even if the average Sia host does not
    have quick upload speeds, the massive parallelism enabled by Sia means that downloads will be blazing fast anyway. In
    addition, you can choose to connect only to the datacenters that are the closest and the fastest. This optimization
    (known as a CDN) is a hugely expensive project for a traditional cloud storage service, but for Sia it is a natural
    consequence of the decentralized network.

    As security is a top priority of Sia, all encryption is performed locally; the people storing your files will have no
    ability to see what you have uploaded. Not only is every file encrypted separately, every *piece* of every file is
    encrypted separately, and hosts are not told which pieces are part of the same file.

    The Cryptocurrency

    Sia uses a new cryptocurrency, called the siacoin. The developers will mine the first 100 blocks or so before releasing

    the code + miner to the public. Other than these first blocks, there is no premine for siacoins. The first block
    reward will be 300,000 siacoins. Each block reward after that will be one siacoin smaller than the previous block reward
    (299,999, then 299,998, and so on). When the block reward reaches 30,000, all remaining blocks will give a 30,000
    siacoin reward. The block time is 10 minutes. Each siacoin is composed of 10^24 indivisible units.

    The most important features of Sia can only be accessed by using siacoins. All storage contracts and all Sia payment
    channels require owning siacoins. This requirement means that as Sia grows in usage, so too will demand for siacoins.
    As demand grows, the price will increase. If Sia is being used for billions of dollars of storage, billions of dollars
    of siacoins will be required. The value of the siacoin is inextricably tied to the amount of storage in use on the Sia

    Sia has a second cryptocurrency, called the Siafund. 3.9% of all successful storage contract payouts go to the holders
    of the siafunds. There are 10,000 siafunds total, and all 10,000 are completely premined. Sia's parent company, Nebulous
    Inc., holds approximately 8750 of these siafunds. The remaining siafunds were sold in a crowdfund which helped to
    finance Sia's early development. The primary goal of siafunding is to provide a way to finance the development of Sia
    without relying on donations or a premine. More people using Sia means more funding available to hire more developers.

    Standard transactions are not subject to the fee, and neither are failed storage contracts (where the host was offline
    or lost the file).

    The Business Plan

    The long term goal of Sia is to be the backbone storage layer of the Internet. All long term storage will be performed
    on Sia. All movies and music will be streamed from Sia. All images will be embedded from Sia. All businesses will use
    Sia as a backend for cloud storage. Sia intends to replace Bittorrent, Amazon S3, Amazon Glacier, Microsoft OneDrive,
    and all backend cloud storage services. We intend to fully disrupt a many billion dollar industry.

    Sia is meant to be a Platform that other applications can build off of. The beta has a first draft API for developers to
    use, found here.

    Over the next few months, we are focusing on building out the api and creating an example application that replaces
    Bittorrent. If you have ideas for things that you want to build which will use Sia, please get in touch with us. Sia is
    completely open source, and you can use the API without getting explicit permission or paying any royalties or licensing

    The Future

    The promise of Sia is a decentralized network of small datacenters that, taken together, comprise the world's fastest,
    cheapest, and most secure cloud storage platform. Today, being a major cloud storage player requires having datacenters,
    building trust within the market, reaching customers, and competing with giants such as Amazon, Google, and Microsoft.
    Breaking into this market is a multi-billion dollar endeavor.

    Sia changes that, by enabling small, efficient datacenters to sell their storage without market trust and without a
    marketing budget. Sia lowers the barrier to entry, and in doing so creates a wealth of cheap storage for its users.
    Anyone with an Internet connection and a cheap source of storage can make money.

    The long term goal of Sia is to become a serious competitor to existing cloud storage platforms, including Dropbox,
    Google Drive, and OneDrive. We envision a future where even massive services such as Netflix and YouTube will use Sia to
    deliver the best user experience to their customers.

    We are looking forward to the data storage revolution. Help us make it happen.

    Network Pulse


    Total File Contracts


    Million SC

    Total Contract Cost

    General Statistics



    Current Block


    Total Coins

    20.78 billion siacoins


    13,955 TH

    Estimated Hashrate

    21,861 GH/s

    Maturity Timestamp

    18:35, Nov 25, 2016

    Active File Contracts


    Total File Contract Cost

    31,611,853 siacoins

    Total File Contract Size

    27.114793605658 TB

    Successful Storage Proofs




    For users

    Linux — 64-bit

    macOS — 64-bit

    Windows — 64-bit

    Sia Daemon

    For developers

    Linux — 64-bit

    API Quickstart Guide

    macOS — 64-bit

    API Quickstart Guide

    Windows — 64-bit

    API Quickstart Guide



    The official GPU miner

    Source code on GitHub

    Alternate Miner

    A GPU miner for Sia in Go

    Source code on GitHub

    Built on Sia

    Block explorer

    Sia Blockchain Explorer


    Next generation NAS powered by Sia

    Sia Cluster

    Data farm monitoring and management tool for Sia

    Sia GNOME Shell Extension

    Sia Cloud Storage Extension for GNOME Shell

    Sia PULSE

    Analytics tool for Sia

    Discover more


    Blockchain Explorer



    Developer Docs

    Github - UI









  • Things you can do with Sia

    Sia is fundamentally a cloud storage platform. And, when compared to other types of cloud storage, it has the following advantages:Decentralization. Only the uploader controls the files. Nobody can spy on the data, nobody can prevent you from downloading the data, and the data cannot be forcibly deleted from the network.Price advantage. Uploading to Sia is extremely cheap. As of posting, storage was approximately $2.00 / TB / Month, which can be compared to Amazon's $21 / TB / Mo. Unlike Dropbox, Sia is metered, which means you only pay for what you use. 100 GB costs $0.20 per month, and 1100 GB costs $2.20 per month, etc.Geographic diversity. When data is uploaded to Sia, it is uploaded all around the world. Outages due to DDoS attacks in North America don't affect the data, because it's also replicated in four other continents across a large number of nodes.Sia makes the most sense for write-seldom, read-often data, however it is also a good substitute for most things that you would put on Amazon Glacier or Amazon S3. Here are some examples of things that work very well for Sia:Computer snapshots. A computer snapshot often contains an enormous amount of personal information. Whether it's information about your friends, your health, your finances, or your passwords, you usually don't want corporations to have full access to your data, especially in a time when the new hot thing is to do as much data mining as possible. Sia's security can provide great peace-of-mind when backing up your computer to the cloud.A media center. While security is not as much of a concern with media, media often takes up a large amount of storage, and Sia is one of the cheapest ways to store and retrieve data online. $2 per month gets you enough to store 1000 GB of media.Research Data Warehouse. A lot of scientific research produces massive amounts of data. Whether it's genome sequencing, particle colliding, or something else, scientists are often forced to filter and discard valuable data for financial reasons. Cheaper solutions such as tape or Amazon Glacier often result in headaches and slowdowns when it's time for the data to be used. Sia as a platform is cheaper than both tape and Glacier, without needing to wait a long time to fetch the data.More creative ideas:Life recorder. A fun idea is to record your entire life through either a camera in your glasses or pocket or somewhere similar - such that your camera can see and record everything you do. This can create a mountain of data, and until the introduction of Sia this may have been intractable to store. However, storing an entire year's worth of SD video (480p, 8 hours per day) on Sia would only cost around $5 per month.Web archive. Websites disappear, comments get deleted, data gets lost. Centralized archives preserve some of this, but often take snapshots infrequently and the data is stored in centralized places. Sia could potentially be used to save frequent snapshots of your favorite websites automatically, primarily being leveraged as a cheap backup source.FUSE. FUSE would allow all data added to, removed from, or altered within a directory to be added to Sia with no further interaction from the user. Sia does not handle tiny files very well yet, so you would not want to run your entire computer out of Sia, however a FUSE implementation would be a great catch-all for all sorts of data, including programs, games, and web-downloads.Blockchain database. It is possible to use Sia as storage for a blockchain. The Bitcoin blockchain currently stands at close to 100 GB, which can be a burden on your local machine but is very small compared to the scales of typical cloud storage. The raw blockchain data doesn't change, which makes it a great candidate for storage on Sia, and would be an excellent way to reduce the burden of running a full node without reducing the amount of security.

  • Sia v1.0.4 and v1.0.4-LTS Released

    • andard Release: Release: we are releasing v1.0.4, which is very similar to v1.0.3 except with a few bug fixes. The graphical client has some upgrades that allow you to more easily see file redundancy, move files around, and more gracefully upload and download entire folders.More significant is the introduction of our LTS releases. The LTS releases are slower to adopt features, which generally means more stability. Our next series of releases will be featuring major changes to the host, the wallet, and the renter. While we will be testing our new releases as much as possible, with changes this large bugs in production are inevitable.The LTS releases are primarily targeted at companies, exchanges, and services which rely heavily on Sia's stability. LTS releases will only upgrade to other LTS releases, and LTS releases will not include upgrades such as instant-wallet-unlocking until we are confident that no new bugs have been introduced.For most users, we recommend using our non-LTS releases, as LTS is over-cautious. We test every release, and we have lots of safety features to protect funds or data from being lost. LTS is primarily for users who will experience great disruption even if there are only minor bugs. 1

    Log in to reply

    1 out of 1

  • Secure Password Management using NACL and Go

    Last weekend, I finished up a project that had been in the back of my mind for a while. The project was not an original idea; it's a password manager. At its most basic, a password manager is an encrypted volume in which you store your myriad unique passwords for all the various services you use. Many find that a text file and GPG is sufficient, but most prefer the usability improvements that utilities such as LastPass, KeePass(X), and 1Password provide. However, these all have problems that I could not easily ignore. LastPass is centralized and closed source, leaving you trusting an unauditable service that holds all your data. 1Password is also closed source. KeePass is a monstrously complex application, complete with support for plugins, browser integration, and dozens of other features, all of which are incidental to the main function of a password manager and are potentially exploitable. All of the above store the entirety of your credentials in memory for long periods of time.

    After feeling disillusioned with the current offerings of password managers, a colleague introduced me to pass, a password manager inspired by the UNIX philosophy. pass is clearly a step closer to what I wanted out of a password manager. Unfortunately, pass also failed a cursory security audit. An attacker with access to your .password-store data directory learns:

    • How many passwords you have
    • The names for each password (usually these are the sites associated with the passwords)
    • The usernames associated with each name

    Exasperated, I decided to write masterkey. The goals were now well defined:

    • Provide a simple, convenient interface for securely storing passphrases and other secrets
    • Use existing, well-audited, hard to mess up cryptography.
    • Write clean, well tested, readable and easily auditable code.
    • Assume a more aggressive threat model than most other password managers. Specifically, avoid storing decrypted credentials in memory, and don't leak metadata.

    Completing these goals represented a quantifiable improvement in terms of security over the popular password managers, and a quantifiable improvement in usability over the bare bones GPG-textfile method.

    The Interface

    masterkey is operated via a REPL, a type of interactive command line interface. Like other password managers, the user only has to enter their master passphrase once at the beginning of the session. I took some inspiration from Cobra, and built a small package that creates an interactive prompt and can register arbitrary commands and pass arguments to those commands. The code is available here (handy godoc link), and may serve to be useful for others looking to build interactive CLI applications using Go. The secure stateful nature of masterkey's vault means it is also amendable to a GUI, and will likely be endowed with a web interface at some point.

    The Core Algorithm

    masterkey uses NACL for authenticated symmetrical encryption and Scrypt for key derivation. A random nonce is generated every time a masterkey vault is created. This nonce is used to encrypt the data and to salt the user's passphrase. The resulting derived key, encrypted data, and nonce are then stored in memory. masterkey uses a REPL to provide an interface to interact with the vault, and each time the vault is accessed it is decrypted and re-encrypted. The result of this algorithm is that an attacker who somehow gains access to the memory of masterkey only knows how to decrypt the vault for the current session, since the nonce changes each time the vault is used and only the derived secret key is stored in memory, not the passphrase. The attacker is also faced with the challenge of determining exactly where in memory the secret key and the encrypted data are, which is a nontrivial task since both are cryptographically random. In comparison, an attacker may simply string dump 1Password or KeePassX and use simple regular expressions to extract all credentials.


    masterkey Github Repo

  • December 2016 Update + Roadmap

    Core Development

    This month we ended up dropping a lot of the work that we've been doing on the wallet. It was decided that the core usability bottleneck for Sia was the uploading speeds, and also Sia up until this point is not actually very proactive about punishing bad hosts. We've spent a large part of November and will continue to spend December on these things, because they really should be our strengths.We have some really exciting news. We re-wrote the uploading algorithm, and uploads are now going at full speed all the time. Our home connection is pretty slow, only 15mbps, but my tests on the live network were getting between 12 and 16mpbs constantly. This can be compared to our v1.0.4 release, which had the connection inching along at something closer to 0.5mpbs constantly. So, at the very least it's a 10x - 20x speedup, but my guess is that it's actually a lot faster - our home connection is the bottleneck here, not the Sia network.It's not ready for release yet, there are some clear bugs with the new algorithms. But it's super promising, and fixing the bugs will only speed things up further.We've also made big changes to the download code. One of the biggest features is that downloads no longer need to wait 30+ minutes to get started, they will usually start in 60 seconds or less. Downloads have been overhauled just like uploads, and are also seeing significant speedups not just in latency but also in throughput.

    Release Schedule


    We're hoping to have v1.1.0-RC1 out in the next week or so. The primary feature v1.1.0 is going to be improved upload and download speeds, however there will also be updated code to better detect and utilize superior hosts - meaning generally faster speeds, better redundancy (6x redundancy over good hosts is much better than 6x redundacy over mediocre hosts), all while providing lower prices. v1.1.0 is going to reduce the default redundancy from 6x to 4x because of our algorithm improvements, which means lower prices and faster upload times, on top of the improvements that are already there.The full v1.1.0 will likely be released the first or second week of January. The code has changed in significant ways and that means we will have to do a substantial amount of testing. We will be aiming to release one RC per week until the software is proven stable.


    This release is target for around February and will feature upgrades to the host and wallet. Hosts will be faster, will be able to handle larger contracts and renewals, and will be performing proof-of-burn as the final securty countermeasure in Sia. This will also feature upgrades to the host plugin in the UI, giving users access to more of the host's settings, and also giving users a tool to gauge how well they are doing and what steps they could be taking to improve the amount of data on their machine.The wallet has been receiving incremental changes in a separate development branch for several months now, and those changes will finally be released in v1.2.0. Most notably the wallet will unlock instantly, however we will also fix errors related to the 'transaction is too big for the transaction pool' class of errors, we will be updating the seed-recovery code to not need a restart to find your balance, and we'll be fixing a few other stability issues as well.There's a very good chance that either v1.1.0 or v1.2.0 will have the ability to repair files without having the file locally. Meaning, once a file gets past about 1.5x redundancy, it'll be safe to delete from your local machine and Sia will still be able to (though more slowly) get the file to its full 4x redundancy. It should be noted that Sia can only repair files if it is running, so even though you will be able to delete the file locally you will still have to keep Sia on in the background for a few hours per week to do repairs.


    This release is farther away, slated likely for April or May. There are a few features that we are considering for v1.3.0, but we haven't finalized the roadmap. Here's a list of potential things we will be adding:

    • General speed and scalability improvements.
    • Ability to share files.
    • Ability to set price vs. performance preferences, including abiltiy to blacklist or whitelist hosts.

    Within 2017

    Here are a few things that we may have by the end of 2017:

    • Ability to recover your files using only your wallet seed.
    • Support for mobile wallets.

    Other Noteworthy Developements

    Minebox Presale

    For those unfamiliar with, Minebox is a storage device that integrates tightly with the Sia network. You can use it like any traditional NAS, however any unused storage space can be rented out over the Sia network for profitability, and all data stored locally on the Minebox can easily be backed up to the Sia network.Nebulous HiringNebulous is currently looking to expand the team! You can find a full description of the available positions at

    Overall Health of Sia

    Despite what the price may indicate, things are going very well at Sia. On the development size Sia is making substantial improvements. Faster uploads, faster downloads, and an ever growing set of tests to improve stability. On the business side, Sia is making progress evangelizing to enterprises, and while we can share anything yet there are several large companies in our pipeline. The Sia team has also received more invitations to speak at conferences, including places like London.

  • Siacoin Release Sia v1.1.0

    This is a minor release that improves renter performance and adds "defrag" behavior to the wallet. Previously, we have had issues with the wallet accumulating too many small outputs and thus being unable to fund large transactions. This isn't an issue for most users, but it can affect high-volume wallets, notably exchanges. The new wallet will regularly consolidate small outputs into one larger output.

    Thanks to the new renter algorithm designed by @DavidVorick, we are seeing upload/download speeds that saturate most residential connections! This is a huge improvement over the previous algorithm. However, memory usage may be substantially higher than before. We are working to reduce memory usage in the next release without compromising speed.

    As before, you should be able to upgrade to v1.1.0 by running siac update. If something goes wrong, you can always update manually -- but please file a bug report or get in touch on our Slack.

    Thanks as always to our contributors, users, and fans, and a special shout-out to @BitcoinErrorLog who submitted a PR to this release!

  • Siacoin (SC)  Release  v1.1.1

    This is a minor release focusing on the renter and hostdb. The renter would previously slow down considerably after about 100 GB of data total had been uploaded, but now will maintain high speeds for much longer than that. While the total amount of data can now easily reach multiple TB, individual files are advised to stay below 100 GB. The hostdb is smarter about scanning and ranking hosts, and you can see more in-depth output using the siac hostdb -v command.

    IMPORTANT NOTE: Unfortunately, our upgrades to the Renter require a full rescan of the blockchain. As a result, if you are upgrading from an older version, siad may take a long time to load the first time you run it. On an HDD, this may take up to an hour. On an SSD it should take closer to 10 minutes.

    You should be able to upgrade to v1.1.1 by running siac update. If something goes wrong, you can always update manually -- but please file a bug report or get in touch on our [email protected] who submitted a PR to this release


  • March 2017 Update + Roadmap

    We are introducing a new, ongoing roadmap for Sia. It's a public Trello board listing all of our current activities and future planned activities. You can also vote for your favorite cards/tasks. Check it out here:

    Recent Development

    The past few months have been very busy for Sia. One of our biggest accomplishments was the release of v1.1.0 and v1.1.1, which each provided substantial speedups to uploads and downloads on the renter. We have also released a competitive website - a just-for-fun place to show off how much you have uploaded.

    The new uploading code was so efficient that many of our hosts have hit full capacity, and this has resulted in a new type slowdown. Renters who are newly forming contracts know to avoid hosts without much available storage, but renters who have already formed contracts do not currently recognize that they need to form new ones when their hosts are full. Our next major set of upgrades for the renter is going to be focusing on host selection, and making sure that the renter is continuously making sure it has the best possible selection of hosts. This will also help with the occasional download issues that users are seeing.

    Upcoming Development

    Below is the list of things that we'll be working on over the next 4-8 weeks.


    We've promised instant wallet unlocking a few times, but we're finally finishing and releasing instant wallet unlocking. @nemo is currently fully focused on finishing the upgrades that we need, and then we will be able to release v.1.2.0 with instant wallet unlocking. The instant wallet unlocking code will also enable us to reduce the memory usage of Sia by about 500 MB.

    Beyond instant wallet unlocking, the wallet will also be upgraded to allow loading from a wallet seed without needing to restart Sia, and will also now find all coins. The current version does not always find all of the coins, we've had to help people make manual adjustments to their configs to get everything working. That will no longer be needed with the new wallet code.


    Unfortunately, hosts have not been correctly submitting storage proofs. v1.1.2 will have a hotfix for two of the issues relating to hosts incorrectly handling their storage contracts and this should resolve 90% of the problems. The other 10% will be resolved through upgraded monitoring and testing that will be launched in v1.2.0.

    There is a second host bug where Windows hosts will occasionally corrupt and lose all of their contracts following a power failure. The fix is unfortunately more substantial, and will not be ready until v1.2.0.

    v1.2.0 will see substantial changes to the host, particularly to the file management. In addition to fixing the corruption bug, the host will have greatly improved performance and scalability, and Windows users will no longer need to run their hosts as the admin user (Linux and Mac users already do not need to run their hosts as admin).

    The upgrade from v1.1.1 to v1.2.0 for hosts could take a while. If you have hundreds of GBs on your host, the upgrade could even take a few hours. While unfortunate, it should be the most expensive upgrade for a long time, and it is well worth it. The new host code is much faster, much more scalable, much more reliable, and overall better for your filesystem.


    We are always continuously monitoring renter performance, and right now the biggest problem is clearly host quality. When hosts fill up with storage, or get overwhelmed with bandwidth requests, the renter is not very good about identifying that the host has lost quality and needs to be replaced. Our next major upgrade for the renter is therefore ongoing monitoring of host quality, and making sure that new hosts are brought in to replace faulty hosts.

    This should help a lot, both with performance and with file reliability.


    Related to host quality and host performance, we will be adding proof of burn to Sia, likely in v1.2.0. The proof of burn will close the final major security gap in the Sia code, more or less 'completing' the core design for the storage protocol. There is of course much to do beyond that in terms of performance and features, but Sia's base will essentially be complete.

    When the feature is released, we will also release an updated hosting guide explaining the proof-of-burn process.


    File sharing will probably not be in v1.2.0. But it may be in v1.2.1 or v1.2.2, and it's something we're very excited to be bringing back to the community. The file sharing we will be adding today will be a simplified type of sharing, where all that is traded is the .sia files. If the receiver of the file is already connected to enough hosts to download the file, then the file can just be downloaded without hassle. Otherwise, the receiver will pick some of the cheaper hosts and form new file contracts with them, allowing them to download that file, and any future files they receive that are shard on that host.

    Those file contracts that get created will not be used for uploading, only for downloading. They will also not be renewed.


    Today, if your renter folder corrupts, you will more or less lose all of your files. The same code that enables file sharing however will also enable file recovery (essentially you can share your files with yourself). You will be able to create a backup of all your Sia files, and if something goes wrong and you lose your renter directory, you will have a few weeks (4-6) to re-download your files and get them back. While this is not as good as being able to recover your files using just a seed, it is a significant improvement to losing everything. Furthermore, it means you can back up multiple TBs of data using a usb stick that's just a few GBs.

    This is of course not the end of the improvements, as time continues we will make it increasingly easy to recover your files in the event of disaster.


    I am almost embarrassed that things are still this way, but currently on Sia if you delete the file locally, the redundancy will constantly degrade, and performance can also suffer substantially. So largely, you need to keep your files locally even as you upload them to Sia.

    Either v1.2.1 or v1.2.2 will have an upgrade to fix this. You will be able to delete your files locally once they are uploaded beyond 1.5x redundancy, and Sia will be able to keep them safely online after that.

    That's all the time I have for today, however I hope to make a follow up post with some updates on our long term mission and our business developments at some point soon. In short, our long term mission remains to replace all existing centralized cloud storage solutions and CDNs, and our business development is going well.

  • Siacoin (SC) Release Sia v1.1.2

    This is a patch release that adds a new asynchronous download endpoint (/renter/downloadasync) and fixes a bug that interfered with host storage proof submission. Hosts are strongly encouraged to upgrade before their proof windows end.


  • Using Sia as a Storage Back-End for Nextcloud

    Nextcloud is a self-hosted alternative to dropbox: it provides a web interface for storing and retrieving your files, using several different storage backends. It integrates with AWS, Dropbox, and Google Cloud, so it was only natural that an integration with Sia was something we desired. This blog post acts as a walkthrough for people already running Nextcloud, guiding you through the process of using Sia with Nextcloud.

    Setting up a Sia Node

    Running Nextcloud with Sia requires running a full Sia node. This guide will walk you through the process of setting one up on your Nextcloud server, and assumes basic linux system administration knowledge.

    Download the latest Sia release that supports Nextcloud, v1.1.2, available here. Unzip the release to your preferred installation directory, and start up a node by running siad. You may also want to set up siad as a service on your server.

    Once you have started a siad instance, you should allow the blockchain to fully synchronize. This can take a fair bit of time, you can view the progress by running siac, the other binary packaged in the release.

    After the blockchain has fully synced, create a new wallet by running siac wallet init. Make sure you keep the seed that is displayed after this command executes safe, it’s the passphrase you will use to unlock your wallet and can also be used to recover your wallet. Note that currently you cannot recover your files from this seed, though this is a planned feature. Now that you’ve initialized a wallet, run siac wallet unlock and provide your seed to unlock your wallet.

    Now, you’ll want to acquire some Siacoin (SC). The usual process for this is to first get Bitcoin, then use an exchange (Yunbi, Poloniex,, and Bitsquare all have Siacoin) to convert from BTC to SC. Once you’ve done this, use siac wallet address to get an address you can receive coins on, and send your SC from your exchange to that address.

    The final step is to set an allowance. A Sia allowance is a recurring amount that you allocate to file storage, download, and upload. You can use the siac renter setallowance command to set your allowance. It takes two parameters, amount and period, where amount is the amount of SC you will be setting aside and the period is the duration of the allowance. The allowance will automatically renew halfway through the period. After you set your allowance, you’re ready to install the Sia Nextcloud app and start uploading and downloading from the Nextcloud interface.

    Setting up your Nextcloud installation

    First, you’ll need to enable external storage on your Nextcloud installation, if you haven’t done so already. Nextcloud provides some good docs on how to do that here. After you’ve enabled external storages, you’ll need to install the Sia external storage app, available here. After you’ve installed the Sia app, add a new external storage from the external storage app. From the dropdown, select Sia. In the ‘API Address’ field, input the default api address, localhost:9980. After doing so, you should see the status indicator turn to green, indicating that you’re ready to start uploading files to Sia.


    The Nextcloud integration is one of the first major integrations of Sia into another storage product, we hope to be able to announce a few more in the coming months. You can check out the source code, report bugs, or request features for the Sia Nextcloud app on our github repo: We’ll be constantly improving the core Sia product as well as the integrations, so you may want to follow the rest of our Github pages to stay in the loop.

    Nextcloud has published a corresponding blog post here

  • Siacoin (SC) Release v1.2.0


  • Siacoin (Sia) January-April 2017 Update

    In our effort to make Sia development as transparent as possible, we’ve decided to start a new initiative: regular triannual updates to the Sia community.

    Startups typically provide regular reporting to their investors, but the crypto space is special. Our users, whether they buy or sell storage, mine, or develop innovative applications, all use and hold Siacoin. Many also hold Siafunds. For these reasons, we consider it our responsibility to provide as much up to date information as possible.

    This January-April update will provide you with a snapshot of everything Sia. We will publish the next update in August.

    Development In the last four months we have released Andromeda (1.1.0) and Blue Moon (1.2.0), with a couple smaller updates in between. Andromeda brought wallet defragmentation, which greatly increased wallet reliability for power users like exchanges. It also enabled massive speed improvements — up to 300Mbps upload speeds, which is crazy fast!

    Blue Moon brought some large usability improvements, with updates to the UI, but its biggest improvement was instant wallet unlocking. Previously, it took 20 or so minutes to unlock the Sia wallet. Now, in Blue Moon, wallet unlock takes only seconds. This has been in the works for a long time, and was one of our biggest feature requests. Instant wallet unlock greatly increases Sia’s usability.

    It’s important to realize that Sia is fully decentralized with its own proof-of-work blockchain. As a company, we could shut down tomorrow, yet everything would still continue to function. This separates us from others in the decentralized storage space. This also makes development more challenging — it’s why feature like instant wallet unlock and reduced blockchain sync time are on the roadmap.

    Over time, we believe that only truly decentralized networks will win the battle against existing, centralized storage companies like Amazon.

    In the next couple months we will further increase Sia’s usability and better position the software as a viable cloud storage solution for businesses. We will do this by introducing the ability to repair files without retaining a local copy. This will allow our users to use Sia as a true cloud storage solution, and allow us to properly compete with Amazon.


    Last month we announced our integration with Nextcloud, the popular open-source alternative to Dropbox and Google Drive. Nextcloud users now have the ability to expand their storage capacity with private, decentralized cloud storage by integrating with Sia.

    The integration, which exists as an app on the Nextcloud app store, allows Nextcloud users to add a Sia folder to their private cloud. Users can simply add files to the folder and they will automatically upload to the Sia network.

    This makes Sia more usable than ever before. Previously, Sia users could only upload files through the Sia-UI (manually) or via the Sia API. Now, by adding the Nextcloud app, users can simply add a Sia folder to their Nextcloud configuration.

    We built the Nextcloud integration, and we will be looking to build more integrations with popular services in the future.


    On the business side, we have updated the website homepage and will be making more updates to the website in the next month. We have migrated our blog to Medium and have posted some great new blog posts. We did a popular Reddit AMA. We also created a public roadmap.

    Our community has been growing. We passed 2100 members in our Slack. Our community members have built some great things: a crowdsourced Wiki, SiaPulse, and SiaHub. A really cool project, SiaDrive, is launching soon — this allows users to mount Sia as a drive on Windows computers (and soon Mac/Linux).

    Another amazing contributor product (and startup), Minebox — a NAS device tightly integrated with Sia — launched its presale. The device serves as a personal cloud and backup solution, while also storing backups of your files on the Sia network. At the same time, it acts as a host on the network, which generates money in the form of Siacoin.

    Speaking of Siacoin, we have a current market cap of over $20 million (according to Coincap).


    We’ve experienced great network growth over the last four months. We currently have 100 terabytes of file contracts on the network and a total capacity of almost 1 petabyte.

    As you can see from the below chart, contract size has rapidly increased from about 37 terabytes on December 31 (block height 85000) to 100 terabytes today (block height 101771). That’s a 170% increase in the last four months. We expect to continue this trend.

    Our number of hosts is also up substantially, from 75 on December 31 to 145 today, a 93% increase. We also expect to continue this trend.

    What’s Next

    Over the next year, we will continue to improve the software (through updates like file sharing, video streaming, and faster blockchain sync), grow the community, and start to bring in business customers.

    Our goal in the next couple years is to make Sia a viable competitor to Amazon S3 and other major centralized cloud services.

    In the long term, we want Sia to be the storage layer of the internet!

    See our public roadmap for more details.

    Notable Blog Posts

    Please let us know if you have any questions! You can learn more or say hello on our website, wiki, forum, Slack, Github, or Twitter!


    Zach Herbert

    @SiaTechHQ operations. @HarvardHBS MBA student & Bitcoin Club President. Mechanical engineer. Obsessed with Apple, Tesla, and Bitcoin!

  • Siacoin (sia) Release v1.2.1

    This is a patch release that fixes bugs in the new host and wallet. This release also includes a fix for a security vulnerability that especially impacts hosts.

    The first time you unlock the wallet should be moderately faster, especially on HDDs.

    If you are upgrading a host from v1.1.2 to v1.2.1, the upgrade will be significantly faster compared to upgrading from v1.1.2 to v1.2.0. It can still take 6-12 hours for larger hosts, but previous upgrade times of several days should no longer happen.

    A siac renter allowance cancel command was also added for canceling your current allowance.

    Thanks to @mtlynch for contributing to this release! And also thanks to the contributor (kept anonymous) who discovered and responsibly disclosed the security vulnerability.


  • Siacoin- Want to deflate the token bubble? Fix the market cap indicator.

    The token world is getting crazy, but last week’s Gnosis ICO pushed us over the edge. Gnosis investors bought up approximately 4.2% of the total GNO token supply for $12.5 million (250,000 ETH), giving the project a market capitalization of $298 million (as of April 24).

    To be clear: this means ICO investors valued Gnosis — an unproven platform that is yet to be launched — at about $300 million. Moreover, the GNO token does not have any actual purpose except to exchange for WIZ tokens at some point in the future.

    We at Sia feel that this ICO insanity cannot continue in its current form — something must give. If the bubble bursts, it will inflict damage on every token, including those that are most reputable.

    Many in the community want to slow and eventually stop this trend. We think that, while investors are by no means rational, they need access to the best possible information in order to make informed decisions. However, it is clear that investors are completely misvaluing most tokens. So what gives?

    Our hypothesis: the market cap indicator is highly flawed.

    Market cap is so powerful because it allows investors to quickly assess total valuation of an asset. A flawed market cap calculation means that investors are not able to properly value a token without doing extensive research.

    There are two major inputs to market cap: total supply, which is required to properly calculate present market cap, and inflation, which can be used to predict future total supply and therefore future market cap.

    Total Supply

    Every site we could find that lists out tokens by price, volume and market cap does so based on circulating supply rather than total supply. Circulating supply indicates how many coins are in circulation, but does not include coins held by the project. By contrast, total supply includes coins in circulation + coins held by the project.

    Even worse, these sites don’t specifically tell users the differences between total and circulating supply. It seems that everyone is doing it wrong, and all but the most informed investors are being misled.

    This flies in the face of basic valuation principles. When valuing a stock, for example, we value the market cap by calculating (share price)*(shares in circulation + shares held by company). We call this combo shares outstanding. We are not currently portraying token market caps this way, and it really throws off the results.

    Data pulled from on May 2, 2017. Coins with 24h volume < $300,000 are excluded. Discrepancies are highlighted in orange.

    See for yourself above. seems to be the the only site that allows users to opt to view tokens by total supply in existence, rather than just the supply in circulation. When we view the top tokens by circulating supply (left), the list looks fairly predictable: Bitcoin, Ethereum, Ripple, and so on. But when we view by total supply (right), we see some crazy results:

    • Ripple’s market cap has more than doubled.
    • FargoCoin is in the top five.
    • Gnosis’ market cap increased from $95 million to $861 million.
    • Stellar Lumens’ market cap increased from $45 million to $487 million.
    • Golem’s market cap increased from $186 million to $230 million.
    • Storjcoin’s market cap increased from $23 million to $228 million.

    We recommend updating all default metrics from circulating supply to total supply.

    Implementing this fix allows us to get a better picture of market cap today, but it does nothing to help us value future market cap. For this, we turn to inflation.


    Inflation is the major driver of future market cap. As more tokens are brought into existence, outstanding tokens are diluted. Tokens with healthy inflation rates can often preserve their price per token, but tokens with extremely high levels of inflation should decrease over time.

    In the token world, we have the wonderful benefit of codified inflation rates. This allows us to estimate the inflation over time for most tokens, and therefore estimate the future market cap. However, sites and exchanges are not properly conveying this information to investors, and therefore the majority of investors are likely not factoring this into their valuations.

    Take Zcash for example. It has a current market cap of $110 million with a total supply of 1.2 million ZEC, but over the next five years 9.8 million ZEC will enter existence. This super-high inflation will drastically increase supply each year, which in turn will affect the market cap. There is no way, however, for the average investor to quickly discover this inflation factor.

    We recommend adding a new metric called inflation factor that indicates how the market cap could be affected over the next five years by token inflation.

    Inflation factor = (new supply over 5 years) / (current total supply) * 100%.

    For example, there is currently a total supply of 25.6 billion Siacoin. In the next five years, the supply will have increased by 21.9 billion. Therefore the Siacoin inflation factor is (21.9 billion) / (25.6 billion) * 100% = 85.5>#/p###

    This means that the total Siacoin supply will increase by about 85.5% over the next 5 years. Investors should factor this information into the current Siacoin price.

    Below are inflation factor calculations for the top fifteen tokens by circulating supply (we used circulating supply rather than total supply because those are the top coins with which most investors are familiar):

    Data pulled from on May 2, 2017. Coins with 24h volume < $300,000 are excluded. Max new coins field was calculated from publicly available inflation data for each coin. It’s possible there are inaccuracies, but the general concept of inflation factor still applies. Inflation factors highlighted in green.

    Introducing the inflation factor metric would allow investors to more easily evaluate how a token’s total supply will change over time, and therefore build that inflation risk into the token price.

    Action Plan

    We suspect that investors are overvaluing many tokens due to the unclear market cap statistic.

    Here is our list of recommendations to remedy this issue:

    1. Replace the existing flawed market cap metric with total market cap on sites such as
    2. Add a new field called inflation factor.
    3. Add both metrics to exchanges.

    Over the next week, we will be reaching out to,,, and others to request that they institute these recommendations. We will also reach out to Poloniex, Kraken, Bittrex, and other major exchanges.

    It will most likely take a unified effort in the crypto community to fix the market cap metric, but together we can get every site and exchange to provide this crucial information to investors. We recommend you email or tweet to your favorite comparison site or exchange, and share this blog post with your network.

    Together, we can hopefully stop this bubble before it bursts.

    Zach cowrote this blog post with David Vorick.

  • SiaCoin (SC) Release v1.2.2

    This is a patch release that fixes bugs in the new wallet and host.

    Hosts will now gracefully handle absent storage folders, and wallets will always show the correct balance when loading or recovering seeds. First-time wallet unlock is faster, and memory consumption has been reduced.

    The renter will also accurately report the redundancy of files, accounting for contracts that have gone offline.

    This release includes over 2500 lines of new testing and bug-fixes. Thanks to @vevarm for providing manpage generation for siac.


  • SiaCoin (SIA) Growing Pains

    For the past month we’ve been working closely with Poloniex and Bittrex to fix wallet issues that were preventing deposits and withdrawals. It appears things are now starting to function as expected. Bittrex withdrawals have been working for several days, and Poloniex is clearing out its backlog of failed withdrawals. Most new Poloniex withdrawals are successful, and many users are receiving withdrawals from weeks ago.

    Thank you all so much for your patience and support as we worked with the exchanges to fix the issues. In this post, we will explain what went wrong, how we responded, and what we are doing to make sure these issues don’t reoccur anytime soon.

    What Went Wrong

    Overall, the wallet issues were caused by a major spike in transaction volume on the Sia blockchain.

    We plan for growth, but we were not expecting so much growth, so fast, without warning. Siacoin entered May with a market cap of ~$30M, and quickly increased to over $400M by early June. As users transferred their coins out of exchanges, and became hosts and renters on the Sia network, the number of transactions significantly grew.

    This huge spike in transaction volume meant that our transaction pool (aka mempool), at 2 MB in size, occasionally filled up at peak times. If the pool is full, new transactions get thrown away. Since miners pick transactions from the pool to form blocks, any transaction that is not included in the pool will not be added to the Sia blockchain.

    This is our fault. We made the decision two years ago to cap the transaction pool at 2 MB, due to significant performance issues above that size, and postponed the engineering work that would allow for a larger pool.

    So, as users requested withdrawals from Poloniex and Bittrex, the exchanges broadcasted the transactions to the network — but didn’t check to make sure they actually were added to the blockchain. The transactions were marked as complete as soon as they were broadcasted. This caused a lot of confusion, since users with completed transactions were not seeing their coins appearing in their wallets.

    How We Responded

    After receiving user reports of Poloniex wallet issues, we emailed them on May 22 to ask if we could help. We provided a quick fix on May 27 that would allow exchanges to re-broadcast transactions that were not added to the transaction pool. Poloniex re-enabled the wallet on May 30, but had to disable it overnight due to similar problems occurring (the transaction pool quickly filled up again, and they were not rebroadcasting transactions automatically).

    We continued to communicate with Poloniex, and provided them with the IP addresses of a major mining pool on May 31 (so that they could broadcast transactions directly to the pool), and better logging on June 1. We then implemented a send-to-many endpoint on June 5, so that exchanges could batch up to 250 withdrawals in a single transaction.

    Poloniex implemented these fixes and went back online on June 8. They are working through the backlog, and we expect them to finish that today. This means things should be pretty much back to normal.

    We worked with Bittrex simultaneously to implement the fixes and they responded really fast — getting back up and running in just a few days.

    In total, we merged 14 fixes into the Sia code in a span of two weeks. These include both the short-term fixes mentioned above and long-term upgrades to allow the Sia network to better scale as transaction volume continues to increase.

    Fixes and Upgrades

    1. Add support for getting and sending raw transactions Allows exchanges to grab a raw transaction associated with an ID and re-broadcast it to the network.
    2. Add logging to the wallet Improve logging so that exchanges can more easily know if a transaction confirmed.
    3. Try reverted transactions in tpool Update() Every reverted transaction will now be retried to be added in the pool. Long-term upgrade for transaction pool to make reorgs less disruptive.
    4. Add logging for failed transaction sends Further improved logging.
    5. Prune unconfirmed transactions older than 12 blocks from the tpool Allows transaction pool to naturally clear of glut, preventing obtuse network fragmentation.
    6. Add API support for send-to-many Allows exchanges to process 25x the withdrawals per hour, using 1/3 the blockchain space per withdrawal.
    7. Add market based transaction accepting and fee estimation Add a fee market to allow high priority transactions to go through.
    8. Tpool block estimation Help drive intelligent fee estimation.
    9. Optimize Block.MerkleRoot by replacing tree.PushObject calls Performance optimization to safely allow for a bigger transaction pool.
    10. Add /tpool/fee endpoint Allow visibility into fee market prices.
    11. Add support for user-set txn fees Allow users to choose their own fees.
    12. Optimize Transaction.ID() by adding direct calls to MarshalSia Optimization to allow safe larger transaction pool.
    13. New Block Fee Estimation Algo More optimal fee estimation.
    14. Switch to diff-based updates for tpool Scalability upgrade with stress tests to allow safe larger transaction pool.

    Next Steps

    Most of the above pull requests focus on long-term upgrades to allow the Sia network to better scale.

    We’ll be increasing the size of the transaction pool from 2mb to 5mb, with the ability to automatically grow further if there are large quantities of high-fee transactions. We will also be creating a fee market, similar to Bitcoin, so that miners can prioritize transactions based on fees. With the upgrades implemented, the Sia network should be able to safely scale by an order of magnitude.

    These scalability upgrades are a main priority, and will be included in the v1.3.0 Capricorn release later this month, along with other important features like remote file repair — which will allow Sia serve as a viable cloud backup solution. In order to experience these scalability upgrades, a large portion of Sia users will need to upgrade to v1.3.0 upon its release.

    Once again, thank you all so much for your patience and support in this time of extreme growth!

  • Sia Coin Choosing ASICs for Sia

    We recently announced that we would be manufacturing and selling ASICs for Sia, an announcement that received a lot more heat and controversy than I was expecting. People primarily seemed to be concerned with mining centralization, and what happens if a small number of groups end up controlling all the hashrate — groups that may well include the developers, as the developers are the ones making the chips.

    We feel strongly however that ASICs are the right move, because as the rest of this post explains, GPU based mining is a false panacea that ultimately leaves a cryptocurrency far more vulnerable to attack. The relative decentralization gained from having the active hashrate controlled by a larger number of parties is far outweighed by the fact that the currency ends up being far more vulnerable to 51% attacks by centralized parties. Not only this, but you decouple the mining from the incentives — in Bitcoin, miners lose big when the price drops. In the GPU mined altcoin world, the price dropping means that miners just hop to a more profitable coin.

    This post dives deep into the mechanics of Proof of Work, and outlines why GPU based mining and ASIC resistance really is a bad choice, especially for smaller cryptocurrencies.

    A Primer on Proof of Work

    We’ve seen a lot of discouraging things play out in Bitcoin. At points, mining pools have controlled more than 51% of the hashrate, and today something like 80% of all Bitcoin mining chips are produced by a single company, a company that has not shied away from using their monopoly to make political moves. Ultimately you only need about 5 mining pools to get 51% of the hashrate in Bitcoin, and 10 to hit 75%.

    The story is actually a bit worse in Ethereum — 3 pools control more than 60% of the hashrate, and 6 pools will get you over 85%. I have tried to get information about how much of this hashrate is everyday users and how much is massive datacenters. Not surprisingly, the massive datacenters are not eager to advertise themselves, and it’s difficult to get a good feel for the distribution. We know however though that there are very large Ethereum mining farms, and that these farms are able to use economies of scale to get significantly better cost efficiencies and energy efficiencies than what you can get with your GPU at home. Make no mistake, the centralization pressures that drove Bitcoin to where it is today are active in the Ethereum ecosystem as well — GPU mining is not a safe haven.

    If you are a GPU mined PoW coin that is not Ethereum, the situation is a lot worse. But before we get too much further with that, let’s step back and talk about the function and mechanics of Proof of Work. In Bitcoin (and blockchains generally), what we really care about is transaction finality. We want to know when we receive money that it’s our money, and that nobody can take that money away from us in the future. Proof of Work provides a powerful stamp that says ‘this history cannot be changed without doing a lot of work’. When we get money in Bitcoin, we know that the only way we can lose that money is if an alternate history appears that doesn’t include our payment, and that alternate history has more work than the history we see.

    We also know that alternate histories are really, really expensive. Proof of Work provides an ingenious tether to resources in the physical world — we know that a block requires doing a ton of computation, and we know from the laws of physics that this type of computation is inherently very energy expensive. (There are types of computation that don’t require much energy, or at least they require very little. PoW is not among them.) We know when we see a Bitcoin block, it took tens of thousands of dollars in electricity to produce, even using the most sophisticated hardware in the world. If someone is also making an alternate history, they are required by the laws of physics to also be spending at least that much money on their alternate history.

    In terms of guarantees from the laws of physics, this is more or less where it stops. A Bitcoin block costs tens of thousands of dollars to produce, and a one block double-spend necessarily costs tens of thousands of dollars. If people are waiting 6 blocks, then an attacker trying to execute a 6 block double-spend is going to need to spend over one hundred thousand dollars executing their attack.

    When you think about the sheer volume of transactions on the Bitcoin network, this doesn’t paint a great picture, especially when you consider that an attacker could double-spend multiple people/services/exchanges all at once. If we stop here, it more or less becomes unsafe for the aggregate transaction volume of a single block to exceed the block reward. In practical terms though, an attacker is unlikely to be able to simultaneously double-spend every single participant in a block, especially if there are hundreds or thousands of participants, and many of them have trust with each other (meaning, you trust your friend not to double spend you when they send money, or you otherwise have some recourse if the transaction does get double-spent).

    Luckily for Bitcoin, we are able to go a step farther than just counting the amount of money in electricity that would need to be spent to execute a double spend. We know that the requirement for building an alternate history is more than just a requirement of spending money on electricity. You need hardware that can convert that electricity into an alternate history. And even better, we know that the original history is going to be extended by all the non-attacking miners on the network, so you need access to more hardware than the rest of the network combined — a 51% attack.

    Caveat: What matters is not only the volume of hardware, but the speed and efficiency of that hardware as well. The speed at which your hardware can convert electricity into Proof of Work is called hashrate, and for any double spend attempt to succeed, you need more hashrate than the rest of the network combined. And the efficiency of your hardware determines exactly how much money on electricity you’ll have to spend to produce that alternate history. If your hardware is half as efficient (most mining hardware can see significant speed boosts if they are willing to sacrifice efficiency), then a one hundred thousand dollar attack turns into a two hundred thousand dollar attack.

    In Bitcoin, if you are using hardware other than Bitcoin-specific ASICs to attack the network, your efficiency is going to drop by a factor of a thousand or more. The hundred thousand dollar attack becomes a hundred million dollar attack. For this reason, we don’t typically worry about things like supercomputers — an entire supercomputer mining Bitcoin is overpowered by a handful ASICs, and the energy costs to produce a full alternate history are strictly prohibitive. If you are going to attack Bitcoin, you need Bitcoin ASICs, end of story.

    We also know that ASICs are very expensive, and they are exclusively useful for Bitcoin mining. So if you have an ASIC, and you aren’t using it for mining today, you’ve pretty much wasted your money. It’s therefore unlikely that there is significant hashrate in the world that isn’t actively mining on the Bitcoin network — any meaningful amount of such hashrate is a LOT of wasted dollars.

    It is for this reason that, when talking about Bitcoin security, we usually ignore the raw energy costs of creating a block and instead focus on the active hashrate, and worry about what it would take to get 51% of the hashrate to rally together and attempt an attack against the network. It’s largely unrealistic (even when you consider governments) that there is meaningful hashrate out there which is not actively mining on Bitcoin.

    Bitcoin has one more layer of defense, and that’s through the incentive model. If you are going to try to build an alternate history, you are going to need access to billions of dollars of specialized hardware. This hardware can only make money by mining Bitcoin, which means the value of the hardware is inherently tied to the price of Bitcoin. If you attack the Bitcoin network and the attack is noticed, it is likely to shake confidence and drop the value of the coin. The value of your billions of dollars of hardware is going to drop right alongside it. So this hundred thousand dollar attack actually has secondary costs that are far, far more substantial. And I can guarantee you that any large “reorg” (when one version of blockchain history is replaced by another) is going to be noticed by the market, especially if that reorg involves large successful double spends.

    As a quick recap:

    1. Proof of Work provides a cryptographic assurance that a certain amount of money needs to be spent to create an alternate history. Therefore, any attack (double-spend or otherwise) using alternate histories must minimally have a payoff that is larger than the cost to create that alternate history (even if you already have 100% of the hashrate).
    2. The original history is being continuously extended by the network. A successful alternate history requires having more hashrate than the rest of the network combined. So the barrier for creating alternate histories is higher than just being able to afford the electricity, you also need access to billions of dollars of hardware.
    3. Specialized hardware is both faster and more energy efficient than standard hardware, by so many orders of magnitude that at least in Bitcoin and other ASIC mined coins, using ASICs is the only practical means to build an alternate history.
    4. ASICs are very expensive, and inherently useful exclusively for mining that particular coin. So if the ASIC is not mining, it’s just wasted money, and it’s a LOT of wasted money. This makes it unlikely that a meaningful number of ASICs exist today which are not actively mining, simply because its so expensive for them to exist and then do nothing. For ASIC mined coins only, this allows us to worry less about how expensive it is to build an alternate history and instead focus more on who owns the existing hashrate — that hashrate likely represents all practical hashrate that can be applied to attack the network.
    5. For ASIC mined coins only, there is a very large amount of hardware that is useful exclusively for mining a particular coin. If the value of that coin falls, the value of the hardware necessarily falls with it. Performing attacks that could shake market confidence, scare away users, or otherwise affect the price of the coin ends up being a lot more expensive for the owner of the hashrate than just the money spent on electricity — they also have to consider the losses they incurred when the value of their hardware dropped.

    Application to GPU-based Coins

    The disadvantages of GPUs start most obviously at the fourth point — with ASIC mined coins, it’s typically safe to assume that all of the visible hashrate represents more or less all of the global hashrate that could exist on a coin. In a GPU or CPU based coin, this simply isn’t true. And if you are one of the smaller GPU coins (like Sia is today), you actually have high visibility into hashrate that exists which is not on your network.

    To put it in concrete terms, the Ethereum network has an estimated 2 million GPUs mining on it. The two largest pools in Ethereum have about 500,000 GPUs each, and the next largest has about 250,000 GPUs on it (all rough estimates). In contrast, the Sia network only has an estimated 200,000 GPUs mining on it. That means there are 3 Ethereum pools that are powerful enough to 51% attack the Sia network today. Instead of being in a situation like Bitcoin where there are 5 pools that combined could control 51% of the hashrate, in Sia there are 3 pools that we know of which are each large enough individually to perform a full 51% attack on our network. It’s a substantially worse situation!

    And this is only the hashrate we know about. There are machine learning data centers with tens of thousands, and potentially millions of GPUs. Because things like this tend to be secret (Google would not want the competition to know how much they spend on machine learning computation), we have no idea if there are other parties or datacenters in the world completely unrelated to cryptocurrency that are also capable of launching 51% attacks, even against Ethereum.

    We also don’t enjoy any security related to the value of the hardware. If the price of Sia falls, all the GPUs actively mining Sia can be pointed to another coin. And if nothing else, they can be sold on Ebay, or even be used to participate in research networks. Attacking Sia with GPUs in a way that causes the price of the coin to fall does not destroy the value of the hardware required to perform the attack. The cost of the attack is therefore reduced to merely the cost of the electricity, which means the payoff of the attack needs only to match the electricity cost, and the attack itself can be spread across multiple participants.

    To put it in concrete terms again, the cost of mining a block on Sia in terms of electricity is somewhere between $500 and $2000. If an Ethereum miner decides to attack Sia, they will also lose out on whatever profit they were making from mining Ethereum (margins tend to be low, but we’ll be generous), so we’ll call it $5000 to mine a block. 6 blocks would therefore cost about $30,000.

    Between ShapeShift, Poloniex, Bittrex, OTC trading, etc, it’s very likely that an attacker would be able to convert far more than $30,000 into another cryptocurrency in the space of a single block. Any escrow is likely going to release funds after 6 blocks (if not sooner), which means a single double-spend would allow the miner to successfully steal back the full $30,000 that they lost in creating the double-spend. And because they received payment in other cryptocurrency, the victims have no recourse.

    This is an attack that is openly available to any of the large Ethereum miners, and it can be executed against any of the smaller (where smaller means 1/4th the size of Ethereum — so at this point in time… all of them) GPU mined coins. Most PoW altcoins today are sitting ducks to double-spends, and ASICs are the solution.

    Most PoW altcoins today are sitting ducks to double-spends, and ASICs are the solution.

    When people think about mining centralization, they typically think only inside the scope of the single coin. Who are the miners of that coin, and how bad is the centralization there? Those are good questions to ask in Bitcoin, but you only get the luxury of focusing on those questions in Bitcoin because ASICs firmly protect the coin against external hashrate. GPU based coins don’t enjoy these protections whatsoever. When considering the security of a GPU coin, you have to look at everyone who is able to execute a 51% attack, which includes miners and mining pools on other coins, and also includes datacenters and farms that have large volumes of GPUs for other reasons (e.g. machine learning).

    Doubts about ASIC Resistance

    The earlier parts of this post explain why ASIC resistance is not desirable. But even if it were desirable, I have doubts about how effective ASIC resistance really can be.

    It boils down to a pretty simple fundamental argument. If you have a chip that is useful for general stuff (video gaming, computing, etc.), or anything that’s not strictly relevant to mining, then it’s going to have circuits and design decisions that it made to cater to these general uses. And you can always make a cheaper/faster/simpler chip just by cutting out the pieces that allow it to be useful for more general purposes.

    The cost of producing chips is really high. Now that we’re producing chips ourselves, I’m well aware of the barriers. I don’t know the exact prices, but my guess is that even if you have the specification for a GPU, the cost of actually producing a batch of them is going to be between tens of millions and hundreds of millions of dollars. And if the ASIC resistant algorithm is effective, you might only be able to save 15% on your chip costs and electricity costs. So ASICs aren’t going to appear until the block rewards are enough that a 15% advantage is going to cover the tens of millions to hundreds of millions that you had to spend producing the chip.

    But as soon as one party is able to overcome that barrier, it’s pretty much game over for everyone else. They get to enjoy the advantages of the 15% efficiency boost, and anyone else who wants to compete is going to need to front tens of millions of dollars, and it’s going to take 6 to 9 months (at minimum) for them to get their chips. And that means your only options at that point are centralization or a PoW shift.

    In fairness, we haven’t seen any ASICs yet for the recent ASIC resistance algorithms, despite high block rewards. The threat of losing your entire investment because the coin hardforked is a very serious threat, potentially enough to keep ASICs at bay.

    Maybe ASIC resistance is possible in practice. I’m skeptical, but so far it has worked. Even so, it’s not desirable, because you leave yourself open to all the GPU-coin problems discussed earlier.

    On the Impotence of 51% Attacks

    A lot of people seem to have the impression that you can do anything you want if you have 51% of the hashrate. 51% attacks are a lot less powerful than I think most people realize, and it’s one of the greatest strengths of Bitcoin. Miners are beholden to the consensus rules. If miners create an illegal block, it doesn’t matter how much hashrate they have or how much they extend the illegal chain — full nodes will just ignore them. This means that miners are unable to change consensus rules like the coin inflation or block size. Miners are unable to steal money that was never sent to them, and they can’t force full nodes off of the network.

    This fact, combined with all the other incentives that more or less force Bitcoin miners to keep the market + price happy, means that Bitcoin enjoys a huge amount of security even in the face of the miner centralization that plagues it today. It is of course a far better situation if there is nobody who controls even 1% of the hashrate, but the situation today is not a dystopia. The miners have relatively little power, despite their hashrate centralization.

    Still, miners with 51% hashrate are able to double-spend at will; they are able to censor transactions at will; and if they want, they can even mine exclusively empty blocks, effectively killing off the currency. But all of these actions have market-based consequences, and ultimately nullify billions of dollars of mining hardware. At least for ASIC coins, the incentives protect the network against these types of manipulation (though not entirely — a government for example may decide that censoring certain transactions is worth the resulting decline in value).

    That said, we would rather not rely on incentives where we do not need to, and we will work to keep the hashrate for Sia as decentralized as possible. A network where the largest miner has 1% of the hashrate is far better than a network where 5 miners make up 51% of the hashrate, and we will do everything we can to steer Sia towards the path of greatest decentralization.

    The Economics of Preventing Hashrate Monopolies

    One of the controversial things that we have said is that we will not sell enough chips to any single party for them to own more than 20% of the hashrate. This has seemed alarmingly high for many, especially juxtaposed against the ideal of having no miner above 1% total hashrate.

    Unfortunately, we can’t control what people do. Chip manufacturing is decentralized, and if somebody has the means to produce their own chips, there’s nothing we can do to stop them. If there’s someone out there looking to buy 30% of the hashrate on the network, and we refuse to sell to them, they can probably just go make their own chips. And once they’ve crossed the R&D hurdle there’s nothing stopping them from selling 20% hashrate to other interested large buyers.

    If we as chip manufacturers want to stay relevant, we have to be competitive. If we close ourselves off to large buyers, we will have significantly less capital than the competitor who does not, and we will lose the market to them. The ASIC game is very much about capital. A batch of 28nm ASICs costs millions of dollars, whether you want 100 chips or 10,000 chips, you are going to be paying on the order of millions of dollars. And if you want 16nm chips, you are going to be paying tens of millions of dollars. That means making the jump to 16nm ASICs requires tens of millions in sales.

    If we close ourselves off to large buyers, we may not be able to produce 16nm chips and a competitor may be able to. That means that the competitor will have a monopoly over Sia hashrate the way Bitmain effectively lords over the Bitcoin hashrate.

    If this sounds like bad situation, it’s because it is a bad situation. But as the rest of this post has argued, it’s far superior to the situation you are in when you have a GPU based algorithm. ASICs are bad, but GPUs are an outright systemic risk.

    As chip manufacturers, we have to balance the goal of getting hashrate into the wide diversity of hands possible with the requirement that our chips MUST be competitive, and being competitive more or less comes down to how much money you have. We have to operate such that nobody else can have significantly more money than us, or we will become obsolete.

    One of the biggest reasons that we chose to make the first batch of Sia ASICs was that we really wanted to make sure that the first batch made it into the hands of the community. The advantage that ASICs have over GPUs is enormous, and if the first ASIC chips were made by someone who intended to hold a mining monopoly, likely the only recourse would be a PoW hardfork. There’s a large first mover advantage, because if you are the first ASIC you get to collect 100% of the block reward, and anybody who tries to compete with you will only be able to collect 50% (assuming they even have comparable hardware).

    Why Not Proof of Stake or Proof of Capacity?

    I’ll start with Proof of Capacity because that’s the easier one. Proof of Capacity suffers from the same exact problems as GPU mining: it’s commodity hardware, and there’s a LOT of it out there that could be used to 51% attack our network. Further, if the coin price goes down, the miners wouldn’t care because they can just sell their hardware on the Sia network, or on Ebay, and they will still be able to use it for profit.

    I’ll note that this isn’t a problem for the storage on Sia network, and that’s because of one super key difference. When you put data onto the Sia network, you get to pick which hosts end up with your data. If there’s a bad or malicious host, you have no requirement to use them. Mining is not this way though, if someone has mining resources they can force themselves onto the network. So Sia the platform enjoys protections that don’t exist if we use hard drive capacity for mining.

    Proof of Stake is more difficult to address, because there are a lot of highly technical reasons that it doesn’t work, but there’s also a lot of optimism that developments like Slasher are able to address the core problems and result with a working, secure Proof of Stake system. One of the leading Proof of Stake researchers, Vlad Zamfir, will openly tell you that a secure Proof of Stake system is very hard to achieve, that his designs are not finished, and that anyone looking to create a Proof of Stake system with security properties that rival Proof of Work has a long road ahead of them. I more or less agree, with the caveat that I think Proof of Stake is inherently insecure, and that the problems in front of it today are unsolvable in theory, let alone in practice.

    Even if we assume that Proof of Stake is solvable, it has an unavoidable property that I really dislike. Once you get stake in a Proof of Stake system, by following the rules and being attentive you can guarantee that you never lose that stake. If someone were to get 51% control, they have that control forever. And it’s true at smaller amounts too, if someone gets 5% control, they have that control forever. Proof of Work is different, because maintaining control requires actively burning electricity. And at any point in time, someone else can come along and burn electricity themselves, which reduces the total percentage of hashrate that you have. Essentially, with Proof of Work, you have to remain active, competitive, and invested to maintain control. And if the userbase doesn’t like you, they can potentially fund their own miners to regain control.

    There’s a lot more I could talk about, but really any serious discussion about Proof of Stake needs to be it’s own blog post. For now, I’m happy enough to say that I don’t think it’s the right move for Sia. We have enough hard problems that we’re solving already, we don’t need to add another to our plate. Especially because Proof of Work is already really, really good. Even with the centralization risks, even with the energy waste, Proof of Work is an amazing way to build consensus, and I think it’s the best foundation for Sia.


    There’s a lot more that I could talk about, but we have to draw the line somewhere and this post is already very long. I can say that there are multiple factors that went into this decision that I didn’t have time for in this post, and all of them relate to keeping Sia as decentralized as possible.

    The choice for ASICs is distasteful, because the disadvantages are more visible vs. other choices we could make, but I strongly believe that ASICs are far and away the best long term decision. Exploring why required a deep dive into all the components that make Proof of Work viable at all, but hopefully you’ve walked away for a deeper appreciation of everything that Bitcoin does well. Proof of Work is a very impressive system, and it’s impressive in spite of all the miner centralization that plagues it. If you want true decentralization and trustlessness, it is the only solution that has stood the test of time.


    David Vorick

  • Sia Coin - How to Put Data on the Sia Network

    It has recently come to my attention that we don’t have much documentation about uploading files to the Sia network. It is our goal that the user experience becomes so intuitive that documentation is not necessary. Unfortunately, the user experience is not very intuitive yet, and so I’ve written this post to help fill the gap between what you can figure out intuitively from our current UI, and what you need to know to make the most out of Sia.

    Step One: Synchronizing the Blockchain

    Sia is foremost about security, and about not needing to trust anyone. This is more powerful than mere decentralization — instead of just having your data in multiple places, you have your data set up in a way that there is no single point of failure, including the humans in charge of protecting your data. It’s about having sovereignty — the freedom to know that you are in control of what happens to your data and nobody else.

    This requires a blockchain, and unfortunately getting the full benefit of a blockchain requires you to download and verify the entire thing. For Sia, this means downloading about 6 GB, and it takes a few hours on an SSD, and a few days on an HDD.

    As soon as you start Sia, it’s going to connect to the network and start downloading the blockchain. You will be able to see the progress as it downloads, and you will not be able to do much until the blockchain download completes.

    It is unfortunate, and we are working on making blockchain download take less time, but I urge you not to under-value the benefit of downloading the blockchain. Lite clients (which don’t download the whole blockchain) are vulnerable to a lot of attacks that full nodes are not, and lite client users really are more like ‘guests’ to the network than actual users.

    Step Two: Get Siacoin

    The Sia network runs on siacoins. You need them to upload, to download, and it’s how both hosts and miners are paid. Sia needs to use a native asset to automatically execute contracts — if we used something like the US Dollar, there would be some custodian of the dollars who would have to approve every contract and every payment. That custodian would be a source of centralization. Cryptocurrency is a requirement for decentralized payments.

    The easiest way to get a small amount of siacoin is through You can convert any cryptocurrency to siacoin with minimal hassle. You can also trade for Sia on Poloniex, Yunbi, Bittrex, and a handful of other cryptocurrency exchanges. If you don’t have any cryptocurrency, you can start by getting Bitcoin.

    Step Three: Creating Contracts

    This is probably the most confusing part of Sia, and it’s something we’re actively working on improving. The biggest issue here is that blockchains aren’t scalable. If we had to put a transaction on the blockchain every time someone uploaded files, not only would uploading be very slow, it would also mean that only a few thousand people could ever use the network. We solve this problem using incremental contracts. They are a little complicated, but ultimately not so hard to understand.

    Instead of creating a new blockchain transaction every time we pay a host, we create a contract with the host that locks up our money. That locked up money has 2 payouts: one for you, and one for the host. Initially, it says that you get all of the money back and the host doesn’t get any money at all. But as we upload and download, we update the contract to say that the host gets a little money, and then more and more as we keep using the host. The scalability comes from the fact that we only need to broadcast the version of the contract to the blockchain. Over the course of a month, we can pay the host thousands or even millions of times, and in the end only a single blockchain transaction is created.

    When you hit ‘Create Allowance’, your renter goes and forms 50 incremental contracts with hosts, though generally we just call them ‘Contracts’. You put some amount of money into these contracts which you then spend as you upload and download. The process of creating contracts takes about an hour, and cannot be interrupted. There is also no indication of progress in v1.2.2, however we will be adding a progress indicator in v1.3.0.

    The UI has a nice indicator for your balance, which should say something like ‘220 SC Spend / 500 SC Allocated’. What this means is that the total value of the contracts that you formed is about 500 SC, and that you’ve got about 280 SC left to spend.

    You may notice that immediately upon creating your allowance, it says that some of the money has already been spent. This is because you have to pay transaction fees, and contract fees. Those 50 contracts are each a transaction which goes onto the blockchain, and that means you need to pay fees. The host is also going to have to put storage proofs onto the blockchain, and you pay for the transaction fees of the storage proofs up-front a

    Over time, some of your hosts will inevitably disappear. As this happens, your files will be automatically repaired, restoring them to the original redundancy. The repair operation is moderately expensive, so it only triggers once you’ve lost half of your redundant hosts (in a 10-of-30 scheme, it’ll trigger when only 20 of your hosts are left).s well. Finally, there is the siafund fee that pays the developers.

    The contract system on Sia operates similar to a utility bill. You pay for 3 months in advance, and then whatever you didn’t use is returned to you at the end of the three months.

    If you use the UI, the number of contracts you form is fixed, and the hosts you choose is selected automatically based on a bunch of factors, including price, age, and uptime. The UI is not intended to be for power users, so if you want more customization, you’ll have to use either the command line or the API. The command line can be operated from the ‘Terminal’ tab in the UI. Run the command renter -h to see a list of options. The API documentation can be found here:

    Step Four: Uploading Files

    You can upload a file using the ‘Upload Files’ button. You can upload just a single file, or a whole folder. Currently, the atomic size for Sia is 40MB. We are working on improving this, but currently it means that if you upload a bunch of tiny files, they will upload as though they were a full 40MB each. We therefore recommend zipping up small files before uploading them to Sia.

    Files are uploaded at 3x redundancy to 30 hosts. What this means is that 30 hosts end up with fragments of your data, and out of those hosts any 10 are enough to recover the original data. The magic that makes this possible is an algorithm called Reed-Solomon codes, and it was actually invented in 1960. The result is that as long as your hosts are 90% reliable each, your data has 99.999999999999999% overall reliability. It’s a very powerful way to protect data, even when the individual hosts themselves are on home connections and constantly unplugging, rebooting, or losing power. It also means that up to 20 of your hosts can run away, and your files are still able to be recovered. As the network stabilizes and the software improves, we will be switching to 20-of-50, which has the benefit of only 2.5x total redundancy, while still being about equivalently reliable (more hosts means you can get away with less redundancy).

    The UI displays the redundancy of each file. As the file uploads, you will see this redundancy increasing. Red means ‘file cannot be recovered’, yellow means ‘file has low redundancy’, and green means ‘file is safe’.

    Step Five: Maintaining Your Files

    Contracts by default only last for 3 months. When the contract expires, the host deletes all the data, because they are no longer being paid to store it. To prevent data loss, your client will automatically renew your contracts with the hosts. To do this though, the client needs to be running, and it needs the wallet to be unlocked (because it has to pay for the time extension on the data). Your client will renew your contracts when there are six weeks remaining in the contracts. The contracts will extend the time back out to 3 months, and you will have to pay for the additional 6 weeks of data storage that the host is committing to.

    Over time, some of your hosts will inevitably disappear. As this happens, your files will be automatically repaired, restoring them to the original redundancy. The repair operation is moderately expensive, so it only triggers once you’ve lost half of your redundant hosts (in a 10-of-30 scheme, it’ll trigger when only 20 of your hosts are left). The repair operation does not happen automatically, your client needs to be running so it can deal with the encryption — hosts are not allowed to do the repairs themselves, because enabling them to do repairs actually also gives them the opportunity to cheat.

    This means that you should let your client run overnight at least once a month, so that it can perform all of the housekeeping on your files. If you have a lot of files and a slow upload speed, you may want to let it run for a few days, because re-uploading files that have lost redundancy can take a while. You can tell the progress of the repair by looking at the redundancy for each file and folder. If it is green, it means the file is good to go, and no more work is necessary. If it is yellow, it means you should let Sia run until the file has been repaired.

    I hope this helps everyone who was confused about how to use Sia, and what it’s doing behind the scenes to protect your data. Eventually we hope that this information is a lot more intuitive, and that the user experience gives you confidence and understanding without needing to reference any documentation. In the meantime, we’re happy to help in any way we can.

  • Sia Coin - Announcing Sia Bounties

    Sia Bounties are here! Today marks the start of an ongoing series of bounties, each between $1k and $10k, paid and denominated in Siacoin. We will be posting our first bounty in the next hour on Github under the “bounty” label.

    As the core team, our primary focus is building the Sia core software, but we know there are countless opportunities to integrate Sia as a backend storage solution for existing apps. As we improve Sia and add new features, these integrations will become even more important. Sia Bounties will allow us to reward our contributors for building integrations between Sia and popular apps and platforms.

    Where will the funding come from? After watching the burst of activity that followed the recent and successful Blockstack-Sia bounty, a group of Sia enthusiasts took note, quietly organized a “donor’s club,” and brought us a proposal for Sia Bounties (the group wishes to remain anonymous).

    We would like to recognize them for their generosity, and look forward to growing and rewarding our amazing developer community from their ongoing donations. If any of you reading this would like to donate 100k SC or more per quarter, we will put you in touch with the the donor group.

    As money’s involved, we thought it a good idea to lay out some basic information and ground rules for bounties:

    • Good places to discuss bounties are #bounties (for nontechnical discussion) and #app-dev (for technical discussion) in our Slack.
    • Every Bounty Project will be clearly specified, with specific requirements for bounty payout. Now, knowing the Sia community, we are aware that by simply meeting some minimum requirement, you won’t stop developing. But meeting ALL the minimums is when a bounty will get paid.
    • Certain bounties are expected to be quite large in scope (and payout) and thus likely require formation of a team. In these instances the team is responsible for providing an agreed statement as part of their bounty submission for how the bounty will be distributed along with the necessary Siacoin addresses to distribute the funds across.
    • A bounty will only be paid once to one submission and, unless specified otherwise, it will be paid to the first individual or team to meet ALL the criteria set out for the bounty. This may be changed in special cases for larger bounties.
    • All projects have a time period where they are useful to the development and growth of Sia and likewise all bounties will have an expiration date. Submissions will not be accepted after the expiration date, unless the bounty is renewed.
    • In the event of multiple submissions in the same time period, Sia and the Donors will evaluate each submission and serve as tiebreakers.
    • Sia and the Donors reserves the right to modify/clarify/expand any bounty requirements and payouts. We will keep this honest and transparent, and the reasons for any and all changes and ultimately bounty awards will be published.

  • Siacoin (SIA) Release v 1.3.0 Capricorn 

    This is a minor release that introduces a number of long-awaited features.

    The most prominent features are remote file repair and wallet lookahead. Remote file repair allows Sia to automatically repair your files even after the original file data has been deleted from your machine. It works by downloading data from hosts, expanding it to the desired redundancy, and reuploading the redundant pieces to other hosts. This is a crucial feature for Sia because hosts that go offline or fail to meet quality requirements must be replaced. Note that in order for remote file repair to work, the file must report at least 1x redundancy.

    Wallet lookahead means that the wallet will pre-generate the next n addresses for its seed, and watch the blockchain for them. (Remember, each address corresponds to a particular seed index.) For example, even if the user has only created 5 addresses from their seed, the wallet may internally be keeping track of the next 100 addresses. This functionality is mainly useful for people who use the same seed on multiple computers: before this fix, their wallet balance could be reported incorrectly, which caused some (understandable) anxiety.

    v1.3.0 also contains a number of additions to our API:

    • /wallet/changepassword route, allowing users to change their wallet password
    • Upgraded /wallet/sendsiacoins to allow sending one output to multiple recipients (primarily useful for exchanges)
    • New /tpool endpoints for getting raw transaction data and transaction fee estimations
    • /host/estimatescore endpoint for estimating your host's score, as seen by renters

    We have also switched our gateway multiplexer from muxado to smux, which should improve stability and performance, and modified the gateway connection protocol to require fewer roundtrips while sending more actionable information.

    Finally, there were many internal bug fixes and optimizations, including transaction pool speed-ups, fixes for the renter stalling, and faster initial blockchain download. One of the fixes that I'll appreciate most is converting this horrible-looking stack [email protected] worked with @johnathanhowell to implement remote file repair

  • @ChrisSchinnerl worked with @lukechampine to implement wallet lookahead, among other fixes
  • @GlenDC worked with @lukechampine to implement the muxado->smux transition and gateway protocol changes
  • @starius worked with @DavidVorick to improve initial blockchain download speed
  • @elopio contributed packaging metadata for a Sia snap package
  • @aiorla made good use of a new JSON type in Go 1.8
  • @jnmclarty@mharkus@mtlynch@petabytestorage@rudibs@S-anasol, and @skynode fixed up a bunch of documentation
  • @moimael added some flags to our release packaging to reduce the size of Sia binaries
  • Contributors have also helped keep the issue tracker under control by answering common questions and marking duplicates. This is part of an ongoing effort to rein in our issue tracker, which we plan to start pruning more aggressively in the coming weeks.


Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.