github.com/fozzysec/SiaPrime@v0.0.0-20190612043147-66c8e8d11fe3/doc/whitepaper.tex (about) 1 \documentclass[twocolumn]{article} 2 \usepackage{amsmath} 3 4 \begin{document} 5 \frenchspacing 6 7 \title{Sia: Simple Decentralized Storage} 8 9 \author{ 10 {\rm David Vorick}\\ 11 Nebulous Inc.\\ 12 david@nebulouslabs.com 13 \and 14 {\rm Luke Champine}\\ 15 Nebulous Inc.\\ 16 luke@nebulouslabs.com 17 } 18 19 \maketitle 20 21 \subsection*{Abstract} 22 This is the original Sia Protocol whitepaper. As SiaPrime is a fork of Sia, it 23 describes the foundation of this project as well. Questions or suggestions 24 should be forwarded to the authors referenced above. 25 26 The authors introduce Sia, a platform for decentralized storage. 27 Sia enables the formation of storage contracts between peers. 28 Contracts are agreements between a storage provider and their client, defining what data will be stored and at what price. 29 They require the storage provider to prove, at regular intervals, that they are still storing their client's data. 30 31 Contracts are stored in a blockchain, making them publicly auditable. 32 In this respect, Sia can be viewed as a Bitcoin derivative that includes support for such contracts. 33 Sia will initially be implemented as an altcoin, and later financially connected to Bitcoin via a two-way peg. 34 35 \section{Introduction} 36 Sia is a decentralized cloud storage platform that intends to compete with existing storage solutions, at both the P2P and enterprise level. 37 Instead of renting storage from a centralized provider, peers on Sia rent storage from each other. 38 Sia itself stores only the storage contracts formed between parties, defining the terms of their arrangement. 39 A blockchain, similar to Bitcoin \cite{btc, btcdg}, is used for this purpose. 40 41 By forming a contract, a storage provider (also known as a \textit{host}) agrees to store a client's data, and to periodically submit proof of their continued storage until the contract expires. 42 The host is compensated for every proof they submit, and penalized for missing a proof. 43 Since these proofs are publicly verifiable (and are publicly available in the blockchain), network consensus can be used to automatically enforce storage contracts. 44 Importantly, this means that clients do not need to personally verify storage proofs; they can simply upload their file and let the network do the rest. 45 46 We acknowledge that storing data on a single untrusted host guarantees little in the way of availability, bandwidth, or general quality of service. 47 Instead, we recommend storing data redundantly across multiple hosts. 48 In particular, the use of erasure codes can enable high availability without excessive redundancy. 49 50 Sia will initially be implemented as a blockchain-based altcoin. 51 Future support for a two-way peg with Bitcoin is planned, as discussed in ``Enabling Blockchain Innovations with Pegged Sidechains'' \cite{side}. 52 The Sia protocol largely resembles Bitcoin except for the changes noted below. 53 54 \section{General Structure} 55 Sia's primary departure from Bitcoin lies in its transactions. 56 Bitcoin uses a scripting system to enable a range of transaction types, such as pay-to-public-key-hash and pay-to-script-hash. 57 Sia opts instead to use an $M$--of--$N$ multi-signature scheme for all transactions, eschewing the scripting system entirely. 58 This reduces complexity and attack surface. 59 60 Sia also extends transactions to enable the creation and enforcement of storage contracts. 61 Three extensions are used to accomplish this: contracts, proofs, and contract updates. 62 Contracts declare the intention of a host to store a file with a certain size and hash. 63 They define the regularity with which a host must submit storage proofs. 64 Once established, contracts can be modified later via contract updates. 65 The specifics of these transaction types are defined in sections \ref{sec:contracts} and \ref{sec:storage}. 66 67 \section{Transactions} 68 A transaction contains the following fields: \\ 69 70 \noindent 71 \begin{tabular}{ l | l } 72 \textbf{Field} & \textbf{Description} \\ \hline 73 Version & Protocol version number \\ 74 Arbitrary Data & Used for metadata or otherwise \\ 75 Miner Fee & Reward given to miner \\ 76 Inputs & Incoming funds \\ 77 Outputs & Outgoing funds (optional) \\ 78 File Contract & See: File Contracts (optional) \\ 79 Storage Proof & See: Proof of Storage (optional) \\ 80 Signatures & Signatures from each input \\ 81 \end{tabular} 82 83 \subsection{Inputs and Outputs} 84 An output comprises a volume of coins. 85 Each output has an associated identifier, which is derived from the transaction that the output appeared in. 86 The ID of output $i$ in transaction $t$ is defined as: 87 \[ 88 H(t || \text{``output''} || i) 89 \] 90 where $H$ is a cryptographic hashing function, and ``output'' is a string literal. 91 The block reward and miner fees have special output IDs, given by: 92 \[ 93 H(H(\text{Block Header}) || \text{``blockreward''}) 94 \] 95 Every input must come from a prior output, so an input is simply an output ID. 96 97 Inputs and outputs are also paired with a set of \textit{spend conditions}. 98 Inputs contain the spend conditions themselves, while outputs contain their Merkle root hash \cite{merkle}. 99 100 \subsection{Spend Conditions} 101 Spend conditions are properties that must be met before coins are ``unlocked'' and can be spent. 102 The spend conditions include a time lock and a set of public keys, and the number of signatures required. 103 An output cannot be spent until the time lock has expired and enough of the specified keys have added their signature. 104 105 The spend conditions are hashed into a Merkle tree, using the time lock, the number of signatures required, and the public keys as leaves. 106 The root hash of this tree is used as the address to which the coins are sent. 107 In order to spend the coins, the spend conditions corresponding to the address hash must be provided. 108 The use of a Merkle tree allows parties to selectively reveal information in the spend conditions. 109 For example, the time lock can be revealed without revealing the number of public keys or the number of signatures required. 110 111 It should be noted that the time lock and number of signatures have low entropy, making their hashes vulnerable to brute-forcing. 112 This could be resolved by adding a random nonce to these fields, increasing their entropy at the cost of space efficiency. 113 114 \subsection{Signatures} 115 Each input in a transaction must be signed. 116 The cryptographic signature itself is paired with an input ID, a time lock, and a set of flags indicating which parts of the transaction have been signed. 117 The input ID indicates which input the signature is being applied to. 118 The time lock specifies when the signature becomes valid. 119 Any subset of fields in the transaction can be signed, with the exception of the signature itself (as this would be impossible). 120 There is also a flag to indicate that the whole transaction should be signed, except for the signatures. 121 This allows for more nuanced transaction schemes. 122 123 The actual data being signed, then, is a concatenation of the time lock, input ID, flags, and every flagged field. 124 Every such signature in the transaction must be valid for the transaction to be accepted. 125 126 \section{File Contracts} 127 \label{sec:contracts} 128 A file contract is an agreement between a storage provider and their client. 129 At the core of a file contract is the file's Merkle root hash. 130 To construct this hash, the file is split into segments of constant size and hashed into a Merkle tree. 131 The root hash, along with the total size of the file, can be used to verify storage proofs. 132 133 File contracts also specify a duration, challenge frequency, and payout parameters, including the reward for a valid proof, the reward for an invalid or missing proof, and the maximum number of proofs that can be missed. 134 The challenge frequency specifies how often a storage proof must be submitted, and creates discrete \textit{challenge windows} during which a host must submit storage proofs (one proof per window). 135 Submitting a valid proof during the challenge window triggers an automatic payment to the ``valid proof'' address (presumably the host). 136 If, at the end of the challenge window, no valid proof has been submitted, coins are instead sent to the ``missed proof'' address 137 (likely an unspendable address in order to disincentivize DoS attacks; see section \ref{subsec:host-protect}). 138 Contracts define a maximum number of proofs that can be missed; if this number is exceeded, the contract becomes invalid. 139 140 If the contract is still valid at the end of the contract duration, it \textit{successfully terminates} and any remaining coins are sent to the valid proof address. 141 Conversely, if the contract funds are exhausted before the duration elapses, or if the maximum number of missed proofs is exceeded, the contract \textit{unsuccessfully terminates} and any remaining coins are sent to the missed proof address. 142 143 Completing or missing a proof results in a new transaction output belonging to the recipient specified in the contract. 144 The output ID of a proof depends on the contract ID, defined as: 145 \[ 146 H(\text{transaction} || \text{``contract''} || i) 147 \] 148 where $i$ is the index of the contract within the transaction. 149 The output ID of the proof can then be determined from: 150 \[ 151 H(\text{contract ID} || \text{outcome} || W_i) 152 \] 153 Where $W_i$ is the window index, i.e. the number of windows that have elapsed since the contract was formed. 154 The outcome is a string literal: either ``validproof'' and ``missedproof'', corresponding to the validity of the proof. 155 156 The output ID of a contract termination is defined as: 157 \[ 158 H(\text{contract ID} || \text{outcome}) 159 \] 160 Where outcome has the potential values ``successfultermination'' and ``unsucessfultermination'', corresponding to the termination status of the contract. 161 162 File contracts are also created with a list of ``edit conditions,'' analogous to the spend conditions of a transaction. 163 If the edit conditions are fulfilled, the contract may be modified. 164 Any of the values can be modified, including the contract funds, file hash, and output addresses. 165 As these modifications can affect the validity of subsequent storage proofs, contract edits must specify a future challenge window at which they will become effective. 166 167 Theoretically, peers could create ``micro-edit channels'' to facilitate frequent edits; see discussion of \mbox{micropayment} channels, section \ref{sec:uptime}. 168 169 \section{Proof of Storage} 170 \label{sec:storage} 171 Storage proof transactions are periodically submitted in order to fulfill file contracts. 172 Each storage proof targets a specific file contract. 173 A storage proof does not need to have any inputs or outputs; only a contract ID and the proof data are required. 174 175 \subsection{Algorithm} 176 Hosts prove their storage by providing a segment of the original file and a list of hashes from the file's Merkle tree. 177 This information is sufficient to prove that the segment came from the original file. 178 Because proofs are submitted to the blockchain, anyone can verify their validity or invalidity. 179 Each storage proof uses a randomly selected segment. 180 The random seed for challenge window $W_i$ is given by: 181 \[ 182 H(\text{contract ID} || H(B_{i-1})) 183 \] 184 where $B_{i-1}$ is the block immediately prior to the beginning of $W_i$. 185 186 If the host is consistently able to demonstrate possession of a random segment, then they are very likely storing the whole file. 187 A host storing only 50\% of the file will be unable to complete approximately 50\% of the proofs. 188 189 \subsection{Block Withholding Attacks} 190 The random number generator is subject to manipulation via block withholding attacks, in which the attacker withholds blocks until they find one that will produce a favorable random number. 191 However, the attacker has only one chance to manipulate the random number for a particular challenge. 192 Furthermore, withholding a block to manipulate the random number will cost the attacker the block reward. 193 194 If an attacker is able to mine 50\% of the blocks, then 50\% of the challenges can be manipulated. 195 Nevertheless, the remaining 50\% are still random, so the attacker will still fail some storage proofs. 196 Specifically, they will fail half as many as they would without the withholding attack. 197 198 To protect against such attacks, clients can specify a high challenge frequency and large penalties for missing proofs. 199 These precautions should be sufficient to deter any financially-motivated attacker that controls less than 50\% of the network's hashing power. 200 Regardless, clients are advised to plan around potential Byzantine attacks, which may not be financially motivated. 201 202 \subsection{Closed Window Attacks} 203 Hosts can only complete a storage proof if their proof transaction makes it into the blockchain. 204 Miners could maliciously exclude storage proofs from blocks, depriving themselves of transaction fees but forcing a penalty on hosts. 205 Alternatively, miners could extort hosts by requiring large fees to include storage proofs, knowing that they are more important than the average transaction. 206 This is termed a \textit{closed window attack}, because the malicious miner has artificially ``closed the window.'' 207 208 The defense for this is to use a large window size. 209 Hosts can reasonably assume that some percentage of miners will include their proofs in return for a transaction fee. 210 Because hosts consent to all file contracts, they are free to reject any contract that they feel leaves them vulnerable to closed window attacks. 211 212 \section{Arbitrary Transaction Data} 213 Each transaction has an arbitrary data field which can be used for any type of information. 214 Nodes will be required to store the arbitrary data if it is signed by any signature in the transaction. 215 Nodes will initially accept up to 64 KB of arbitrary data per block. 216 217 This arbitrary data provides hosts and clients with a decentralized way to organize themselves. 218 It can be used to advertise available space or files seeking a host, or to create a decentralized file tracker. 219 220 Arbitrary data could also be used to implement other types of soft forks. 221 This would be done by creating an ``anyone-can-spend'' output but with restrictions specified in the arbitrary data. 222 Miners that understand the restrictions can block any transaction that spends the output without satisfying the necessary stipulations. 223 Naive nodes will stay synchronized without needing to be able to parse the arbitrary data. 224 225 \section{Storage Ecosystem} 226 Sia relies on an ecosystem that facilitates decentralized storage. 227 Storage providers can use the arbitrary data field to announce themselves to the network. 228 This can be done using standardized template that clients will be able to read. 229 Clients can use these announcements to create a database of potential hosts, and form contracts with only those they trust. 230 231 \subsection{Host Protections} 232 \label{subsec:host-protect} 233 A contract requires consent from both the storage provider and their client, allowing the provider to reject unfavorable terms or unwanted (e.g. illegal) files. 234 The provider may also refuse to sign a contract until the entire file has been uploaded to them. 235 236 Contract terms give storage providers some flexibility. 237 They can advertise themselves as minimally reliable, offering a low price and a agreeing to minimal penalties for losing files; 238 or they can advertise themselves as highly reliable, offering a higher price and agreeing to harsher penalties for losing files. 239 An efficient market will optimize storage strategies. 240 241 Hosts are vulnerable to denial of service attacks, which could prevent them from submitting storage proofs or transferring files. 242 It is the responsibility of the host to protect themselves from such attacks. 243 244 \subsection{Client Protections} 245 \label{subsec:client-protect} 246 Clients can use erasure codes, such as regenerating codes \cite{reg}, to safeguard against hosts going offline. 247 These codes typically operate by splitting a file into $n$ pieces, such that the file can be recovered from any subset of $m$ unique pieces. 248 (The values of $n$ and $m$ vary based on the specific erasure code and redundancy factor.) 249 Each piece is then encrypted and stored across many hosts. 250 This allows a client to attain high file availability even if the average network reliability is low. 251 As an extreme example, if only 10 out of 100 pieces are needed to recover the file, then the client is actually relying on the 10 most reliable hosts, rather than the average reliability. 252 Availability can be further improved by rehosting file pieces whose hosts have gone offline. 253 Other metrics benefit from this strategy as well; the client can reduce latency by downloading from the closest 10 hosts, or increase download speed by downloading from the 10 fastest hosts. 254 These downloads can be run in parallel to maximize available bandwidth. 255 256 \subsection{Uptime Incentives} 257 \label{sec:uptime} 258 The storage proofs contain no mechanism to enforce constant uptime. 259 There are also no provisions that require hosts to transfer files to clients upon request. 260 One might expect, then, to see hosts holding their clients' files hostage and demanding exorbitant fees to download them. 261 However, this attack is mitigated through the use of erasure codes, as described in section \ref{subsec:client-protect}. 262 The strategy gives clients the freedom to ignore uncooperative hosts and work only with those that are cooperative. 263 As a result, power shifts from the host to the client, and the ``download fee'' becomes an ``upload incentive.'' 264 265 In this scenario, clients offer a reward for being sent a file, and hosts must compete to provide the best quality of service. 266 Clients may request a file at any time, which incentivizes hosts to maximize uptime in order to collect as many rewards as possible. 267 Clients can also incentivize greater throughput and lower latency via proportionally larger rewards. 268 Clients could even perform random ``checkups'' that reward hosts simply for being online, even if they do not wish to download anything. 269 However, we reiterate that uptime incentives are not part of the Sia protocol; they are entirely dependent on client behavior. 270 271 Payment for downloads is expected to be offered through preexisting micropayment channels \cite{mpc}. 272 Micropayment channels allow clients to make many consecutive small payments with minimal latency and blockchain bloat. 273 Hosts could transfer a small segment of the file and wait to receive a micropayment before proceeding. 274 The use of many consecutive payments allows each party to minimize the risk of being cheated. 275 Micropayments are small enough and fast enough that payments could be made every few seconds without having any major effect on throughput. 276 277 \subsection{Basic Reputation System} 278 Clients need a reliable method for picking quality hosts. 279 Analyzing their history is insufficient, because the history could be spoofed. 280 A host could repeatedly form contracts with itself, agreeing to store large ``fake'' files, such as a file containing only zeros. 281 It would be trivial to perform storage proofs on such data without actually storing anything. 282 283 To mitigate this Sybil attack, clients can require that hosts that announce themselves in the arbitrary data section also include a large volume of time locked coins. 284 If 10 coins are time locked 14 days into the future, then the host can be said to have created a lock valued at 140 coin-days. 285 By favoring hosts that have created high-value locks, clients can mitigate the risk of Sybil attacks, as valuable locks are not trivial to create. 286 287 Each client can choose their own equation for picking hosts, and can use a large number of factors, including price, lock value, volume of storage being offered, and the penalties hosts are willing to pay for losing files. 288 More complex systems, such as those that use human review or other metrics, could be implemented out-of-band in a more centralized setting. 289 290 \section{Siafunds} 291 Sia is a product of Nebulous Incorporated. 292 Nebulous is a for-profit company, and Sia is intended to become a primary source of income for the company. 293 Currency premining is not a stable source of income, as it requires creating a new currency and tethering the company's revenue to the currency's increasing value. 294 When the company needs to spend money, it must trade away portions of its source of income. 295 Additionally, premining means that one entity has control over a large volume of the currency, and therefore potentially large and disruptive control over the market. 296 297 Instead, Nebulous intends to generate revenue from Sia in a manner proportional to the value added by Sia, as determined by the value of the contracts set up between clients and hosts. 298 This is accomplished by imposing a fee on all contracts. 299 When a contract is created, 3.9\% of the contract fund is removed and distributed to the holders of \textit{siafunds}. 300 Nebulous Inc. will initially hold approx. 88\% of the siafunds, and the early crowd-fund backers of Sia will hold the rest. 301 302 Siafunds can be sent to other addresses, in the same way that siacoins can be sent to other addresses. 303 They cannot, however, be used to fund contracts or miner fees. 304 When siafunds are transferred to a new address, an additional unspent output is created, containing all of the siacoins that have been earned by the siafunds since their previous transfer. 305 These siacoins are sent to the same address as the siafunds. 306 307 \section{Economics of Sia} 308 The primary currency of Sia is the siacoin. 309 The supply of siacoins will increase permanently, and all fresh supply will be given to miners as a block subsidy. 310 The first block will have 300,000 coins minted. 311 This number will decrease by 1 coin per block, until a minimum of 30,000 coins per block is reached. 312 Following a target of 10 minutes between blocks, the annual growth in supply is:\\ 313 314 \tabcolsep=0.11cm \noindent 315 \begin{tabular}{ l | *{7}{c} } 316 Year & 1 & 2 & 3 & 4 & 5 & 8 & 20 \\ \hline 317 Growth & 90\% & 39\% & 21\% & 11.5\% & 4.4\% & 3.2\% & 2.3\% 318 \end{tabular} \\ 319 320 There are inefficiencies within the Sia incentive scheme. 321 The primary goal of Sia is to provide a blockchain that enforces storage contracts. 322 The mining reward, however, is only indirectly linked to the total value of contracts being created. 323 324 The siacoin, especially initially, is likely to have high volatility. 325 Hosts can be adversely affected if the value of the currency shifts mid-contract. 326 As a result, we expect to see hosts increasing the price of long-term contracts as a hedge against volatility. 327 Additionally, hosts can advertise their prices in a more stable currency (like USD) and convert to siacoin immediately before finalizing a contract. 328 Eventually, the use of two-way pegs with other crypto-assets will give hosts additional means to insulate themselves from volatility. 329 330 % \section{Under Consideration} 331 % The primary foundation of Sia has been established above. 332 % Other considerations, such as mining algorithms, block time, etc., can be assumed to mirror those found in Bitcoin. 333 334 % Giving careful attention to ``A Treatise on Altcoins'' \cite{alts}, we are considering the following changes to Sia for the overall improvement of the cryptocurrency. 335 % We caution that these propositions have not yet been rigorously examined from a security standpoint. 336 337 % \subsection{Flexible Contracts} 338 % Contracts, in their present form, are fairly strict. 339 % There is a set penalty for each missed storage proof, and a termination upon $n$ total missed storage proofs. 340 % Increased flexibility in the penalty schedule may be desirable. 341 342 % Contracts are also permanent, creating what is essentially an uneditable file on the network. 343 % There may be value in enabling clients and hosts to negotiate an updated file hash or other updated contract terms. 344 % Updating the terms of the contract would require consent from all parties. 345 346 % \subsection{Proof of Existence Windows} 347 % In an attempt to partially resolve the closed window attacks, we could use a proof of existence strategy. 348 % A host can create a hash of the storage proof which they submit to the blockchain within the window. 349 % The host then has a greatly extended window in which they can demonstrate that the proof of storage was created during the required window. 350 351 % This has two advantages. 352 % First, an attacker cannot selectively exclude proof of existence hashes, because there's no way to figure out who owns each hash. 353 % Either the attacker doesn't include any unknown proof of existence hashes, or the attacker risks including undesired proof of existence hashes. 354 % Second, this allows hosts to submit small transactions to the network during peak hours and then the larger transactions when the traffic has died down. 355 356 % A further improvement would enable Merkle Tree proofs of existence. 357 % This would enable a host to submit multiple proofs of storage in a single proof of existence hash. 358 359 % % delete/expand this section? 360 % \subsection{Siafund the Miner fees} 361 % Have some portion of siafunds contribute to the miner fees, which ensures that miners have compensation so long as Sia is being used for its core purpose - storage. 362 363 % \subsection{Miner Fee Adjustments} 364 % If a block has miner fees which are significantly higher than the fees in the current block, there is incentive for miners to re-mine the previous block and change who gets the miner fees. 365 % This can be mitigated by putting all of the fees into a pool which pays out 50\% every block, making re-mining unprofitable for any party with less than 50\% of the network hashing power. 366 % Link to discussion threads of this potential change. 367 368 % Additionally, miners have incentives not to propagate high fee transactions, because this will prevent other miners from mining the transaction and collecting the fees. 369 % It may be possible to construct a system using fee deterioration that means a miner has the highest expected total reward when the transaction is mined as soon as possible - regardless of who mines the transaction. 370 % Link to discussion threads of this potential change. 371 372 % \subsection{More Frequent Target Adjustments} 373 % % This section could use a few citations, but the discussion on this seems pretty well scattered. I could find things like the Kimoto Gravity Well, but other than alts.pdf I couldn't find any comments by respected individuals. I know that these discussions are out there, I've seen them before, just can't find them. 374 % Bitcoin adjusts its block difficulty every 2016 blocks, with a target of 10 minutes per block. 375 % This often means that the final blocks in a difficulty window are produced faster than 10 minutes (sometimes substantially) on account of rapid growth in available mining power. 376 % To mitigate this effect, we are considering adjusting the difficulty after every block. 377 378 % % I don't understand this paragraph 379 % The bi-weekly adjustments to the Bitcoin difficulty can also cause coordinated drops in mining power---all at once, miners lose a percentage of their dollars-per-energy efficiency. 380 % Difficulty adjustments every block creates a much smoother function for when mining rigs are no longer profitable. 381 382 % The clamp on mining growth can also be increased. 383 % The clamp serves to prevent an attacker from being easily manipulating the difficulty. 384 % % 2,016,000 what? 385 % In Bitcoin, raising the difficulty from 1000 to 4000 requires a minimum of 2,016,000 of work, and the difficulty can adjust by a maximum of 4x every week. 386 % If the difficulty is being adjusted every block, however, and clamped at 1.001\% per block, an attacker will need 3,000,050 work to raise the difficulty from 1000 to 4000. 387 % At this rate, the difficulty can shift by a maximum of 7.5x every week, which both increases the flexibility of the difficulty and makes difficulty raising attacks more difficult. 388 389 % Though the difficulty will be adjusted every block, it will still be adjusted according to the amount of time taken to produce the previous 2016 blocks, preventing randomly fast or slow blocks from having large impact on the network. 390 391 % \subsection{Committing to State} 392 % One thing that could allow for substantially lighter weight clients is if the miners committed to the current state of the network, instead of just to the new transactions. 393 % This would mean creating a structure for a database that represents the state of the network and hashing it. 394 % We could follow suggestions similar to those presented in ``Ultimate blockchain compression'' \cite{ubc}. 395 396 % \subsection{Variance Enforced Merge Mining} 397 % Bitcoin enforces a number of leading 0s on a winning block. 398 % Sia could enforce something like a single leading 1, followed by a bunch of leading 0s. 399 % This creates the property that no hash is ever valid for both Bitcoin and Sia. 400 401 % The value to this is that the number of payouts a miner gets from finding blocks goes up. 402 % The total payout is still the same, but the number of payouts increases by the number of blocks that would have been valid for both. 403 % A block that solves the coin with the highest difficulty will always be valid for both blockchains. 404 % (I need to read more about merge mining before I publish this section) 405 406 \section{Conclusion} 407 Sia is a variant on the Bitcoin protocol that enables decentralized file storage via cryptographic contracts. 408 These contracts can be used to enforce storage agreements between clients and hosts. 409 After agreeing to store a file, a host must regularly submit storage proofs to the network. 410 The host will automatically be compensated for storing the file regardless of the behavior of the client. 411 412 Importantly, contracts do not require hosts to transfer files back to their client when requested. 413 Instead, an out-of-band ecosystem must be created to reward hosts for uploading. 414 Clients and hosts must also find a way to coordinate; one mechanism would be the arbitrary data field in the blockchain. 415 Various precautions have been enumerated which mitigate Sybil attacks and the unreliability of hosts. 416 417 Siafunds are used as a mechanism of generating revenue for Nebulous Inc., the company responsible for the release and maintenance of Sia. 418 By using Siafunds instead of premining, Nebulous more directly correlates revenue to actual use of the network, and is largely unaffected by market games that malicious entities may play with the network currency. 419 Miners may also derive a part of their block subsidy from siafunds, with similar benefits. 420 Long term, we hope to add support for two-way-pegs with various currencies, which would enable consumers to insulate themselves from the instability of a single currency. 421 422 We believe Sia will provide a fertile platform for decentralized cloud storage in trustless environments. 423 424 \onecolumn 425 \begin{thebibliography}{9} 426 427 \bibitem{btc} 428 Satoshi Nakamoto, 429 \emph{Bitcoin: A Peer-to-Peer Electronic Cash System}. 430 431 \bibitem{merkle} 432 R.C. Merkle, 433 \emph{Protocols for public key cryptosystems}, 434 In Proc. 1980 Symposium on Security and Privacy, 435 IEEE Computer Society, pages 122-133, April 1980. 436 437 \bibitem{cpr} 438 Hovav Shacham, Brent Waters, 439 \emph{Compact Proofs of Retrievability}, 440 Proc. of Asiacrypt 2008, vol. 5350, Dec 2008, pp. 90-107. 441 442 \bibitem{reg} 443 K. V. Rashmi, Nihar B. Shah, and P. Vijay Kumar, 444 \emph{Optimal Exact-Regenerating Codes for Distributed Storage at the MSR and MBR Points via a Product-Matrix Construction}. 445 446 \bibitem{side} 447 Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Peolstra, Jorge Timon, Pieter Wuille, 448 \emph{Enabling Blockchain Innovations with Pegged Sidechains}. 449 450 \bibitem{alts} 451 Andrew Poelstra, 452 \emph{A Treatise on Altcoins}. 453 454 \bibitem{ibf} 455 Gavin Andresen, 456 \emph{O(1) Block Propagation}, 457 https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 458 459 \bibitem{hdw} 460 Gregory Maxwell, 461 \emph{Deterministic Wallets}, 462 https://bitcointalk.org/index.php?topic=19137.0 463 464 \bibitem{ubc} 465 etotheipi, 466 Ultimate blockchain compression w/ trust-free lite nodes, \newline 467 https://bitcointalk.org/index.php?topic=88208.0 468 469 \bibitem{poc} 470 Gregory Maxwell, 471 \emph{Proof of Storage to make distributed resource consumption costly.} \newline 472 https://bitcointalk.org/index.php?topic=310323.0 473 474 \bibitem{mpc} 475 Mike Hearn, 476 \emph{Rapidly-adjusted (micro)payments to a pre-determined party},\newline 477 https://en.bitcoin.it/wiki/Contracts\#Example\_7:\_Rapidly-adjusted\_.28micro.29payments\_to\_a\_pre-determined\_party 478 479 \bibitem{btcdg} 480 Bitcoin Developer Guide, 481 https://bitcoin.org/en/developer-guide 482 483 484 \end{thebibliography} 485 486 \end{document}