BlockStorage/siadrive
Archived
1
0
Fork 0
Code Activity

Changes

Browse Source
This commit is contained in:
Scott E. Graves
2017-03-22 23:44:56 -05:00
parent 5b60aefc8b
commit 8c75352f5c
32 changed files with 43 additions and 5756 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
3rd_party/CEF/create_common.cmd vendored
View File

@@ -15,7 +15,7 @@ wget --no-check-certificate https://storage.googleapis.com/chrome-infra/depot_to
unzip -o -q -d depot_tools\ depot_tools.zip || goto :ERROR
del /q depot_tools.zip || goto :ERROR
pushd depot_tools
call update_depot_tools.bat || goto :ERROR
call update_depot_tools.bat
popd
goto :END

4
3rd_party/Sia-v1.1.1-windows-amd64/01 - siad test.cmd vendored
View File

@@ -1,4 +0,0 @@
@echo off
pushd "%~dp0%"
siad -d .\data

21
3rd_party/Sia-v1.1.1-windows-amd64/LICENSE vendored
View File

@@ -1,21 +0,0 @@
The MIT License (MIT)
Copyright (c) 2016 Nebulous Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

108
3rd_party/Sia-v1.1.1-windows-amd64/README.md vendored
View File

@@ -1,108 +0,0 @@
# [![Sia Logo](http://sia.tech/img/svg/sia-green-logo.svg)](http://sia.tech) v1.1.1 (Andromeda)
=========
[![Build Status](https://travis-ci.org/NebulousLabs/Sia.svg?branch=master)](https://travis-ci.org/NebulousLabs/Sia)
[![GoDoc](https://godoc.org/github.com/NebulousLabs/Sia?status.svg)](https://godoc.org/github.com/NebulousLabs/Sia)
[![Go Report Card](https://goreportcard.com/badge/github.com/NebulousLabs/Sia)](https://goreportcard.com/report/github.com/NebulousLabs/Sia)
Sia is a new decentralized cloud storage platform that radically alters the
landscape of cloud storage. By leveraging smart contracts, client-side
encryption, and sophisticated redundancy (via Reed-Solomon codes), Sia allows
users to safely store their data with hosts that they do not know or trust.
The result is a cloud storage marketplace where hosts compete to offer the
best service at the lowest price. And since there is no barrier to entry for
hosts, anyone with spare storage capacity can join the network and start
making money.
![UI](http://i.imgur.com/iHoGqoL.png)
Traditional cloud storage has a number of shortcomings. Users are limited to a
few big-name offerings: Google, Microsoft, Amazon. These companies have little
incentive to encrypt your data or make it easy to switch services later. Their
code is closed-source, and they can lock you out of your account at any time.
We believe that users should own their data. Sia achieves this by replacing
the traditional monolithic cloud storage provider with a blockchain and a
swarm of hosts, each of which stores an encrypted fragment of your data. Since
the fragments are redundant, no single host can hold your data hostage: if
they jack up their price or go offline, you can simply download from a
different host. In other words, trust is removed from the equation, and
switching to a different host is painless. Stripped of these unfair
advantages, hosts must compete solely on the quality and price of the storage
they provide.
Sia can serve as a replacement for personal backups, bulk archiving, content
distribution, and more. For developers, Sia is a low-cost alternative to
Amazon S3. Storage on Sia is a full order of magnitude cheaper than on S3,
with comparable bandwidth, latency, and durability. Sia works best for static
content, especially media like videos, music, and photos.
Distributing data across many hosts automatically confers several advantages.
The most obvious is that, just like BitTorrent, uploads and downloads are
highly parallel. Given enough hosts, Sia can saturate your bandwidth. Another
advantage is that your data is spread across a wide geographic area, reducing
latency and safeguarding your data against a range of attacks.
It is important to note that users have full control over which hosts they
use. You can tailor your host set for minimum latency, lowest price, widest
geographic coverage, or even a strict whitelist of IP addresses or public
keys.
At the core of Sia is a blockchain that closely resembles Bitcoin.
Transactions are conducted in Siacoin, a cryptocurrency. The blockchain is
what allows Sia to enforce its smart contracts without relying on centralized
authority. To acquire siacoins, use an exchange such as [Poloniex](https://poloniex.com), [Yunbi](https://yunbi.com), or
[Bitsquare](https://bitsquare.io).
To get started with Sia, check out the guides below:
- [How to Store Data on Sia](https://blog.sia.tech/getting-started-with-private-decentralized-cloud-storage-c9565dc8c854)
- [How to Become a Sia Host](https://blog.sia.tech/how-to-run-a-host-on-sia-2159ebc4725)
- [Using the Sia API](https://blog.sia.tech/api-quickstart-guide-f1d160c05235)
Usage
-----
Sia is ready for use with small sums of money and non-critical files, but
until the network has a more proven track record, we advise against using it
as a sole means of storing important data.
This release comes with 2 binaries, siad and siac. siad is a background
service, or "daemon," that runs the Sia protocol and exposes an HTTP API on
port 9980. siac is a command-line client that can be used to interact with
siad in a user-friendly way. There is also a graphical client, [Sia-UI](https://github.com/NebulousLabs/Sia-UI), which
is the preferred way of using Sia for most users. For interested developers,
the siad API is documented [here](doc/API.md).
siad and siac are run via command prompt. On Windows, you can just double-
click siad.exe if you don't need to specify any command-line arguments.
Otherwise, navigate to its containing folder and click File->Open command
prompt. Then, start the siad service by entering `siad` and pressing Enter.
The command prompt may appear to freeze; this means siad is waiting for
requests. Windows users may see a warning from the Windows Firewall; be sure
to check both boxes ("Private networks" and "Public networks") and click
"Allow access." You can now run `siac` (in a separate command prompt) or Sia-
UI to interact with siad. From here, you can send money, upload and download
files, and advertise yourself as a host.
Building From Source
--------------------
To build from source, [Go 1.7 must be installed](https://golang.org/doc/install)
on the system. Then simply use `go get`:
```
go get -u github.com/NebulousLabs/Sia/...
```
This will download the Sia repo to your `$GOPATH/src` folder, and install the
`siad` and `siac` binaries in your `$GOPATH/bin` folder.
To stay up-to-date, run the previous `go get` command again. Alternatively, you
can use the Makefile provided in this repo. Run `git pull origin master` to
pull the latest changes, and `make release-std` to build the new binaries. You
can also run `make test` and `make test-long` to run the short and full test
suites, respectively. Finally, `make cover` will generate code coverage reports
for each package; they are stored in the `cover` folder and can be viewed in
your browser.

1217
3rd_party/Sia-v1.1.1-windows-amd64/doc/API.md vendored
View File

File diff suppressed because it is too large Load Diff

399
3rd_party/Sia-v1.1.1-windows-amd64/doc/Consensus.md vendored
View File

@@ -1,399 +0,0 @@
Consensus Rules
===============
This document is meant to provide a good high level overview of the Sia
cryptosystem, but does not fully explain all of the small details. The most
accurate explanation of the consensus rules is the consensus package (and all
dependencies).
This document will be more understandable if you have a general understanding
of proof of work blockchains, and does not try to build up from first
principles.
Cryptographic Algorithms
------------------------
Sia uses cryptographic hashing and cryptographic signing, each of which has
many potentially secure algorithms that can be used. We acknowledge our
inexperience, and that we have chosen these algorithms not because of our own
confidence in their properties, but because other people seem confident in
their properties.
For hashing, our primary goal is to use an algorithm that cannot be merge mined
with Bitcoin, even partially. A secondary goal is hashing speed on consumer
hardware, including phones and other low power devices.
For signing, our primary goal is verification speed. A secondary goal is an
algorithm that supports HD keys. A tertiary goal is an algorithm that supports
threshold signatures.
#### Hashing: blake2b
[blake2b](http://en.wikipedia.org/wiki/BLAKE_%28hash_function%29#BLAKE2 "Wiki page") has been chosen as a hashing algorithm because it is fast, it has had
substantial review, and it has invulnerability to length extension attacks.
Another particularly important feature of BLAKE2b is that it is not SHA-2. We
wish to avoid merge mining with Bitcoin, because that may result in many
apathetic Bitcoin miners mining on our blockchain, which may make soft forks
harder to coordinate.
#### Signatures: variable type signatures
Each public key will have an specifier (a 16 byte array) and a byte slice
containing an encoding of the public key. The specifier will tell the
signature verification which signing algorithm to use when verifying a
signature. Each signature will be a byte slice, the encoding can be
determined by looking at the specifier of the corresponding public key.
This method allows new signature types to be easily added to the currency in
a way that does not invalidate existing outputs and keys. Adding a new
signature type requires a hard fork, but allows easy protection against
cryptographic breaks, and easy migration to new cryptography if there are any
breakthroughs in areas like verification speed, ring signatures, etc.
Allowed algorithms:
ed25519: The specifier must match the string "ed25519". The public key
must be encoded into 32 bytes. Signatures and public keys will need to
follow the ed25519 specification. More information can be found at
ed25519.cr.yp.to
entropy: The specifier must match the string "entropy". The signature will
always be invalid. This provides a way to add entropy buffers to
SpendCondition objects to protect low entropy information, while being able
to prove that the entropy buffers are invalid public keys.
There are plans to also add ECDSA secp256k1 and Schnorr secp256k1. New
signing algorithms can be added to Sia through a soft fork, because
unrecognized algorithm types are always considered to have valid signatures.
Currency
--------
The Sia cryptosystem has two types of currency. The first is the Siacoin.
Siacoins are generated every block and distributed to the miners. These miners
can then use the siacoins to fund file contracts, or can send the siacoins to
other parties. The siacoin is represented by an infinite precision unsigned
integer.
The second currency in the Sia cryptosystem is the Siafund, which is a special
asset limited to 10,000 indivisible units. Each time a file contract payout is
made, 3.9% of the payout is put into the siafund pool. The number of siacoins
in the siafund pool must always be divisible by 10,000; the number of coins
taken from the payout is rounded down to the nearest 10,000. The siafund is
also represented by an infinite precision unsigned integer.
Siafund owners can collect the siacoins in the siafund pool. For every 10,000
siacoins added to the siafund pool, a siafund owner can withdraw 1 siacoin.
Approx. 8790 siafunds are owned by Nebulous Inc. The remaining siafunds are
owned by early backers of the Sia project.
There are future plans to enable sidechain compatibility with Sia. This would
allow other currencies such as Bitcoin to be spent in all the same places that
the Siacoin can be spent.
Marshalling
-----------
Many of the Sia types need to be hashed at some point, which requires having a
consistent algorithm for marshalling types into a set of bytes that can be
hashed. The following rules are used for hashing:
- Integers are little-endian, and are always encoded as 8 bytes.
- Bools are encoded as one byte, where zero is false and one is true.
- Variable length types such as strings are prefaced by 8 bytes containing
their length.
- Arrays and structs are encoded as their individual elements concatenated
together. The ordering of the struct is determined by the struct definition.
There is only one way to encode each struct.
- The Currency type (an infinite precision integer) is encoded in big endian
using as many bytes as necessary to represent the underlying number. As it
is a variable length type, it is prefixed by 8 bytes containing the length.
Block Size
----------
The maximum block size is 2e6 bytes. There is no limit on transaction size,
though it must fit inside of the block. Most miners enforce a size limit of
16e3 bytes per transaction.
Block Timestamps
----------------
Each block has a minimum allowed timestamp. The minimum timestamp is found by
taking the median timestamp of the previous 11 blocks. If there are not 11
previous blocks, the genesis timestamp is used repeatedly.
Blocks will be rejected if they are timestamped more than three hours in the
future, but can be accepted again once enough time has passed.
Block ID
--------
The ID of a block is derived using:
Hash(Parent Block ID + 64 bit Nonce + Block Merkle Root)
The block Merkle root is obtained by creating a Merkle tree whose leaves are
the hash of the timestamp, the hashes of the miner outputs (one leaf per miner
output), and the hashes of the transactions (one leaf per transaction).
Block Target
------------
For a block to be valid, the id of the block must be below a certain target.
The target is adjusted once every 500 blocks, and it is adjusted by looking at
the timestamps of the previous 1000 blocks. The expected amount of time passed
between the most recent block and the 1000th previous block is 10e3 minutes. If
more time has passed, the target is lowered. If less time has passed, the
target is increased. Each adjustment can adjust the target by up to 2.5x.
The target is changed in proportion to the difference in time (If the time was
half of what was expected, the new target is 1/2 the old target). There is a
clamp on the adjustment. In one block, the target cannot adjust upwards by more
more than 1001/1000, and cannot adjust downwards by more than 999/1000.
The new target is calculated using (expected time passed in seconds) / (actual
time passed in seconds) * (current target). The division and multiplication
should be done using infinite precision, and the result should be truncated.
If there are not 1000 blocks, the genesis timestamp is used for comparison.
The expected time is (10 minutes * block height).
Block Subsidy
-------------
The coinbase for a block is (300,000 - height) * 10^24, with a minimum of
30,000 \* 10^24. Any miner fees get added to the coinbase to create the block
subsidy. The block subsidy is then given to multiple outputs, called the miner
payouts. The total value of the miner payouts must equal the block subsidy.
The ids of the outputs created by the miner payouts is determined by taking the
block id and concatenating the index of the payout that the output corresponds
to.
The outputs created by the block subsidy cannot be spent for 50 blocks, and are
not considered a part of the consensus set until 50 blocks have transpired.
This limitation is in place because a simple blockchain reorganization is
enough to invalidate the output; double spend attacks and false spend attacks
are much easier to execute.
Transactions
------------
A Transaction is composed of the following:
- Siacoin Inputs
- Siacoin Outputs
- File Contracts
- File Contract Revisions
- Storage Proofs
- Siafund Inputs
- Siafund Outputs
- Miner Fees
- Arbitrary Data
- Transaction Signatures
The sum of all the siacoin inputs must equal the sum of all the miner fees,
siacoin outputs, and file contract payouts. There can be no leftovers. The sum
of all siafund inputs must equal the sum of all siafund outputs.
Several objects have unlock hashes. An unlock hash is the Merkle root of the
'unlock conditions' object. The unlock conditions contain a timelock, a number
of required signatures, and a set of public keys that can be used during
signing.
The Merkle root of the unlock condition objects is formed by taking the Merkle
root of a tree whose leaves are the timelock, the public keys (one leaf per
key), and the number of signatures. This ordering is chosen specifically
because the timelock and the number of signatures are low entropy. By using
random data as the first and last public key, you can make it safe to reveal
any of the public keys without revealing the low entropy items.
The unlock conditions cannot be satisfied until enough signatures have
provided, and until the height of the blockchain is at least equal to the value
of the timelock.
The unlock conditions contains a set of public keys which can each be used only
once when providing signatures. The same public key can be listed twice, which
means that it can be used twice. The number of required signatures indicates
how many public keys must be used to validate the input. If required signatures
is '0', the input is effectively 'anyone can spend'. If the required signature
count is greater than the number of public keys, the input is unspendable.
There must be exactly enough signatures. For example, if there are 3 public
keys and only two required signatures, then only two signatures can be included
into the transaction.
Siacoin Inputs
--------------
Each input spends an output. The output being spent must exist in the consensus
set. The 'value' field of the output indicates how many siacoins must be used
in the outputs of the transaction. Valid outputs are miner fees, siacoin
outputs, and contract payouts.
Siacoin Outputs
---------------
Siacoin outputs contain a value and an unlock hash (also called a coin
address). The unlock hash is the Merkle root of the spend conditions that must
be met to spend the output.
File Contracts
--------------
A file contract is an agreement by some party to prove they have a file at a
given point in time. The contract contains the Merkle root of the data being
stored, and the size in bytes of the data being stored.
The Merkle root is formed by breaking the file into 64 byte segments and
hashing each segment to form the leaves of the Merkle tree. The final segment
is not padded out.
The storage proof must be submitted between the 'WindowStart' and 'WindowEnd'
fields of the contract. There is a 'Payout', which indicates how many siacoins
are given out when the storage proof is provided. 3.9% of this payout (rounded
down to the nearest 10,000) is put aside for the owners of siafunds. If the
storage proof is provided and is valid, the remaining payout is put in an
output spendable by the 'valid proof spend hash', and if a valid storage proof
is not provided to the blockchain by 'end', the remaining payout is put in an
output spendable by the 'missed proof spend hash'.
All contracts must have a non-zero payout, 'start' must be before 'end', and
'start' must be greater than the current height of the blockchain. A storage
proof is acceptable if it is submitted in the block of height 'end'.
File contracts are created with a 'Revision Hash', which is the Merkle root of
an unlock conditions object. A 'file contract revision' can be submitted which
fulfills the unlock conditions object, resulting in the file contract being
replaced by a new file contract, as specified in the revision.
File Contract Revisions
-----------------------
A file contract revision modifies a contract. File contracts have a revision
number, and any revision submitted to the blockchain must have a higher
revision number in order to be valid. Any field can be changed except for the
payout - siacoins cannot be added to or removed from the file contract during a
revision, though the destination upon a successful or unsuccessful storage
proof can be changed.
The greatest application for file contract revisions is file-diff channels - a
file contract can be edited many times off-blockchain as a user uploads new or
different content to the host. This improves the overall scalability of Sia.
Storage Proofs
--------------
A storage proof transaction is any transaction containing a storage proof.
Storage proof transactions are not allowed to have siacoin or siafund outputs,
and are not allowed to have file contracts.
When creating a storage proof, you only prove that you have a single 64 byte
segment of the file. The piece that you must prove you have is chosen
randomly using the contract id and the id of the 'trigger block'. The
trigger block is the block at height 'Start' - 1, where 'Start' is the value
'Start' in the contract that the storage proof is fulfilling.
The file is composed of 64 byte segments whose hashes compose the leaves of a
Merkle tree. When proving you have the file, you must prove you have one of the
leaves. To determine which leaf, take the hash of the contract id concatenated
to the trigger block id, then take the numerical value of the result modulus
the number of segments:
Hash(file contract id + trigger block id) % num segments
The proof is formed by providing the 64 byte segment, and then the missing
hashes required to fill out the remaining tree. The total size of the proof
will be 64 bytes + 32 bytes * log(num segments), and can be verified by anybody
who knows the root hash and the file size.
Storage proof transactions are not allowed to have siacoin outputs, siafund
outputs, or contracts. All outputs created by the storage proofs cannot be
spent for 50 blocks.
These limits are in place because a simple blockchain reorganization can change
the trigger block, which will invalidate the storage proof and therefore the
entire transaction. This makes double spend attacks and false spend attacks
significantly easier to execute.
Siafund Inputs
--------------
A siafund input works similar to a siacoin input. It contains the id of a
siafund output being spent, and the unlock conditions required to spend the
output.
A special output is created when a siafund output is used as input. All of the
siacoins that have accrued in the siafund since its last spend are sent to the
'claim spend hash' found in the siafund output, which is a normal siacoin
address. The value of the siacoin output is determined by taking the size of
the siacoin pool when the output was created and comparing it to the current
size of the siacoin pool. The equation is:
((Current Pool Size - Previous Pool Size) / 10,000) * siafund quantity
Like the miner outputs and the storage proof outputs, the siafund output cannot
be spent for 50 blocks because the value of the output can change if the
blockchain reorganizes. Reorganizations will not however cause the transaction
to be invalidated, so the ban on contracts and outputs does not need to be in
place.
Siafund Outputs
---------------
Like siacoin outputs, siafund outputs contain a value and an unlock hash. The
value indicates the number of siafunds that are put into the output, and the
unlock hash is the Merkle root of the unlock conditions object which allows the
output to be spent.
Siafund outputs also contain a claim unlock hash field, which indicates the
unlock hash of the siacoin output that is created when the siafund output is
spent. The value of the output that gets created will depend on the growth of
the siacoin pool between the creation and the spending of the output. This
growth is measured by storing a 'claim start', which indicates the size of the
siafund pool at the moment the siafund output was created.
Miner Fees
----------
A miner fee is a volume of siacoins that get added to the block subsidy.
Arbitrary Data
--------------
Arbitrary data is a set of data that is ignored by consensus. In the future, it
may be used for soft forks, paired with 'anyone can spend' transactions. In the
meantime, it is an easy way for third party applications to make use of the
siacoin blockchain.
Transaction Signatures
----------------------
Each signature points to a single public key index in a single unlock
conditions object. No two signatures can point to the same public key index for
the same set of unlock conditions.
Each signature also contains a timelock, and is not valid until the blockchain
has reached a height equal to the timelock height.
Signatures also have a 'covered fields' object, which indicates which parts of
the transaction get included in the signature. There is a 'whole transaction'
flag, which indicates that every part of the transaction except for the
signatures gets included, which eliminates any malleability outside of the
signatures. The signatures can also be individually included, to enforce that
your signature is only valid if certain other signatures are present.
If the 'whole transaction' is not set, all fields need to be added manually,
and additional parties can add new fields, meaning the transaction will be
malleable. This does however allow other parties to add additional inputs,
fees, etc. after you have signed the transaction without invalidating your
signature. If the whole transaction flag is set, all other elements in the
covered fields object must be empty except for the signatures field.
The covered fields object contains a slice of indexes for each element of the
transaction (siacoin inputs, miner fees, etc.). The slice must be sorted, and
there can be no repeated elements.
Entirely nonmalleable transactions can be achieved by setting the 'whole
transaction' flag and then providing the last signature, including every other
signature in your signature. Because no frivolous signatures are allowed, the
transaction cannot be changed without your signature being invalidated.

239
3rd_party/Sia-v1.1.1-windows-amd64/doc/Developers.md vendored
View File

@@ -1,239 +0,0 @@
Developer Environment
=====================
Sia is written in Go. To build and test Sia, you are going to need a working go
environment, including having both $GOROOT/bin and $GOPATH/bin in your $PATH.
For most Linux distributions, Go will be in the package manager, though it may
be an old version that is incompatible with Sia. Once you have a working Go
environment, you are set to build the project. If you plan on cross compiling
Sia, you may need to install Go from source. You can find information on that
[here](http://golang.org/doc/install/source).
Sia has has a development build, an automated testing build, and a release
build. The release build is the only one that can synchronize to the full
network. To get the release build, it is usually sufficient to run `go get -u
github.com/NebulousLabs/Sia/...`. This will download Sia and its dependencies
and install binaries in $GOPATH/bin.
After downloading, you can find the Sia source code in
$GOPATH/src/github.com/NebulousLabs/Sia. To build the release binary, run
`make release-std` from this directory. To build the release binary with a
(slow) race detector and an array of debugging asserts, run `make release`. To
build the developer binary (which has a different genesis block, faster block
times, and a few other tweaks), just run `make`.
If you intend to contribute to Sia, you should start by forking the project on
GitHub, and then adding your fork as a "remote" in the Sia git repository via
`git remote add [fork name] [fork url]`. Now you can develop by pulling changes
from `origin`, pushing your modifications to `[fork name]`, and then making a
pull request on GitHub.
If you see an error like the one below, it means that you either forgot to run
`make dependencies`, or you cloned the project into a path that the go tool
does not recognize (usually the wrong path, or symbolic links were somehow
involved).
```
consensus/fork.go:4:2: cannot find package "github.com/NebulousLabs/Sia/crypto" in any of:
/usr/lib/go/src/github.com/NebulousLabs/Sia/crypto (from $GOROOT)
/home/user/gopath/src/github.com/NebulousLabs/Sia/crypto (from $GOPATH)
```
Developer Conventions
=====================
This file is meant to help a developer navigate the codebase and develop clean,
maintainable code. Knowing all of these conventions will also make it easier to
read and code review the Sia project.
The primary purpose of the conventions within Sia is to keep the codebase
simple. Simpler constructions means easier code reviews, greater accessibility
to newcomers, and less potential for mistakes. It is also to keep things
uniform, much in the spirit of 'go fmt'. When everything looks the same,
everyone has an easier time reading and reviewing code they did not write
themselves.
Documentation
-------------
All structs, functions, and interfaces must have a docstring.
Anytime that something is left unfinished, place a comment containing the
string 'TODO:'. This sends a clear message to other developers, and creates a
greppable way to find unfinished parts of the codebase. 'TODO' statements are
currently discouraged. As the codebase matures, 'TODO' statements will become
increasingly frowned upon. 'TODO' statements should not document feature
requests, but instead document incompleteness where the incompleteness causes
disruption to user experience or causes a security vulnerability.
Documentation should give a sense of what each function does, but should also
give a sense of the overall architecture of the code. Where useful, examples
should be provided, and common pitfalls should be explained. Anything that
breaks other conventions in any way needs to have a comment, even if it is
obvious why the convention had to be broken.
The goal of the codebase is to be accessible to newbies. Anything more advanced
than what you would expect to remember from an 'Intro to Data Structures' class
should have an explanation about what the concept it is and why it was picked
over other potential choices.
Code that exists purely to be compatible with previous versions of the
software should be tagged with a 'COMPATvX.X.X' comment. Examples below.
```go
// Find and sort the outputs.
outputs := getOutputs()
// TODO: actually sort the outputs.
```
```go
// Disallow unknown agents.
//
// COMPATv0.4.0: allow a blank agent to preserve compatibility with
// 'siac' v0.4.0, which did not set an agent.
if agent != "SiaAgent" && agent != "" {
return errors.New("unrecognized agent!")
}
```
Naming
------
Names are used to give readers and reviewers a sense of what is happening in
the code. When naming variables, you should assume that the person reading your
code is unfamiliar with the codebase. Short names (like 'cs' instead of
'consensusSet') should only be used when the context is immediately obvious.
For example 'cs := new(ConsensusSet)' is immediately obvious context for 'cs',
and so 'cs' is appropriate for the rest of the function.
Data structures should never have shortened names. 'FileContract.mr' is
confusing to anyone who has not used the data structure extensively. The code
should be accessible to people who are unfamiliar with the codebase. One
exception is for the variable called 'mu', which is short for 'mutex'. This
exception is made because 'mu' appears in many data structures.
When calling functions with obscure parameters, named variables should be used
to indicate what the parameters do. For example, 'm := NewMiner(1)' is
confusing. Instead, use 'threads := 1; m := NewMiner(threads)'. The name gives
readers a sense of what the parameter within 'NewMiner' does even when they are
not familiar with the 'NewMiner' function. Where possible, functions with
obscure, untyped inputs should be avoided.
The most important thing to remember when choosing names is to cater to people
who are unfamiliar with the code. A reader should never have to ask 'What is
`cs`?' on their first pass through the code, even though to experienced
developers it is obvious that `cs` refers to a consensus.ConsensusSet.
Control Flow
------------
Where possible, control structures should be minimized or avoided. This
includes avoiding nested if statements, and avoiding else statements where
possible. Sometimes, complex control structures are necessary, but where
possible use alternative code patterns and insert functions to break things up.
Example:
```go
// Do not do this:
if err != nil {
return
} else {
forkBlockchain(node)
}
// Instead to this:
if err != nil {
return
}
forkBlockchain(node)
```
Mutexes
-------
All exported functions from a package and/or object need to be thread safe.
Usually, this means that the first lines of the function contain a `Lock();
defer Unlock()`. Simple locking schemes should be preferred over performant
locking schemes. As will everything else, anything unusual or convention
breaking should have a comment.
Non-exported functions should not do any locking, unless they have a special
prefix to the name (explained below). The responsibility for thread-safety
comes from the exported functions which call the non-exported functions.
Maintaining this convention minimizes developer overhead when working with
complex objects.
Functions prefixed 'threaded' (example 'threadedMine') are meant to be called
in their own goroutine (`go threadedMine()`) and will manage their own
thread-safety.
Error Handling
--------------
All errors need to be checked as soon as they are received, even if they are
known to not cause problems. The statement that checks the error needs to be
`if err != nil`, and if there is a good reason to use an alternative statement
(such as `err == nil`), it must be documented. The body of the if statement
should be at most 4 lines, but usually only one. Anything requiring more lines
needs to be its own function.
Example:
```go
block, err := s.AcceptBlock()
if err != nil {
handleAcceptBlockErr(block, err)
return
}
```
Sanity Checks
-------------
Some functions make assumptions. For example, the 'addTransaction' function
assumes that the transaction being added is not in conflict with any other
transactions. Where possible, these explicit assumptions should be validated.
Example:
```go
if build.DEBUG {
_, exists := tp.usedOutputs[input.OutputID]
if exists {
panic("incorrect use of addTransaction")
}
}
```
In the example, a panic is called for incorrect use of the function, but only
in debug mode. This failure will be invisible in production code, but the code
will have higher performance because the code should never fail anyway.
If the code is continually checking items that should be universally true,
mistakes are easier to catch during testing, and side effects are less likely
to go unnoticed.
Sanity checks and panics are purely to check for developer mistakes. A user
should not be able to trigger a panic, and no set of network communications or
real-world conditions should be able to trigger a panic.
Testing
-------
The test suite code should be the same quality as the rest of the codebase.
When writing new code in a pull request, the pull request should include test
coverage for the code.
Most modules have a tester object, which can be created by calling
`createXXXTester`. Module testers typically have a consensus set, a miner, a
wallet, and a few other relevant modules that can be used to build
transactions, mine blocks, etc.
In general, testing that uses exclusively exported functions to achieve full
coverage is preferred. These types of tests seem to find more bugs and trigger
more asserts.
Any testing provided by a third party which is both maintainable and reasonably
quick will be accepted. There is little downside to more testing, even when the
testing is largely redundant.

74
3rd_party/Sia-v1.1.1-windows-amd64/doc/Encoding.md vendored
View File

@@ -1,74 +0,0 @@
Encoding
========
The encoding package converts arbitrary objects into byte slices, and vice
versa. Objects are encoded as binary data, without type information. The
decoder will attempt to decode its input bytes into whatever type it is
passed. For example:
```go
Marshal(int64(3)) == []byte{3, 0, 0, 0, 0, 0, 0, 0}
var x int64
Unmarshal([]byte{3, 0, 0, 0, 0, 0, 0, 0}, &x)
// x == 3
```
Note that this leads to some ambiguity. Since an `int64` and a `uint64` are
both 8 bytes long, it is possible to encode an `int64` and successfully decode
it as a `uint64`. As a result, it is imperative that *the decoder knows
exactly what it is decoding*. Developers must rely on context to determine
what type to decode into.
The specific rules for encoding Go's builtin types are as follows:
Integers are little-endian, and are always encoded as 8 bytes, i.e. their
`int64` or `uint64` equivalent.
Booleans are encoded as one byte, either zero (false) or one (true). No other
values may be used.
Nil pointers are equivalent to "false," i.e. a single zero byte. Valid
pointers are represented by a "true" byte (0x01) followed by the encoding of
the dereferenced value.
Variable-length types, such as strings and slices, are represented by an
8-byte unsigned length prefix followed by the encoded value. Strings are
encoded as their literal UTF-8 bytes. Slices are encoded as the concatenation
of their encoded elements. For example:
```go
// slice len: 1 string len: 3 string data
Marshal([]string{"foo"}) == []byte{1,0,0,0,0,0,0,0, 3,0,0,0,0,0,0,0, 'f','o','o'}
```
Maps are not supported; attempting to encode a map will cause `Marshal` to
panic. This is because their elements are not ordered in a consistent way, and
it is imperative that this encoding scheme be deterministic. To encode a map,
either convert it to a slice of structs, or define a `MarshalSia` method (see
below).
Arrays and structs are simply the concatenation of their encoded elements.
Byte slices are not subject to the 8-byte integer rule; they are encoded as
their literal representation, one byte per byte.
All struct fields must be exported. (For some types this is a bit awkward, so
this rule is subject to change.) The ordering of struct fields is determined
by their type definition. For example:
```go
type foo struct {
S string
I int
}
Marshal(foo{"bar", 3}) == append(Marshal("bar"), Marshal(3)...)
```
Finally, if a type implements the SiaMarshaler interface, its MarshalSia
method will be used to encode the type. Similarly, if a type implements the
SiaUnmarshal interface, its UnmarshalSia method will be used to decode the
type. Note that unless a type implements both interfaces, it must conform to
the spec above. Otherwise, it may encode and decode itself however desired.
This may be an attractive option where speed is critical, since it allows for
more compact representations, and bypasses the use of reflection.

289
3rd_party/Sia-v1.1.1-windows-amd64/doc/File Contract Negotiation.md vendored
View File

@@ -1,289 +0,0 @@
File Contract Negotiation
=========================
Securing data on Sia requires creating and revising file contracts in an
untrusted environment. Managing data on Sia happens through several protocols:
+ Settings Request - the host sends the renter its settings.
+ Revision Request - the renter will send the host a file contract id, and the
host will send the most recent file contract revision that it knows of for
that file contract, with the signatures. A challenge and response is also
performed to verify that the renter is able to create the signatures to
modify the file contract revision.
+ File Contract Creation - no data is uploaded during the initial creation of a
file contract, but funds are allocated so that the file contract can be
iteratively revised in the future.
+ File Contract Revision - an existing file contract is revised so that data
can be added to an arbitrary place, or removed from an arbitrary place.
+ File Contract Renewal - an existing file contract is renewed, meaning that a
new file contract with a different id is created, but that has the same data.
New funds are added to this file contract, and it can now be modified
separately from the previous contract.
+ Data Request - data is requested from the host by hash.
+ (planned for later) Storage Proof Request - the renter requests that the host
perform an out-of-band storage proof.
+ (planned for later) Metadata Request - the renter requests some metadata
about the file contract from the host, namely the list of hashes that compose
the file. This list of hashes is provided along with a cryptographic proof
that the hashes are valid. The proof is only needed if only a subset of
hashes are being sent.
A frequently seen construction is 'acceptance'. The renter or host may have the
opportunity to accept or reject a communication, which takes the form of a
string. The acceptance string is always the same, and any string that is not
the acceptance string is a rejection. The rejection string can include reasons
why the rejection occurred, but most not exceed 255 bytes. After a rejection,
the connection is always closed.
The protocols described below are numbered. The number indicates when the
communicator is switching. Each pair of numbers is a full round trip of
communications.
All communications attempt to support slow connections and Tor connections. Any
connection with a throughput below 100kbps may struggle to perform the uploads
and downloads, and any connection with a rountrip latency greater than 2
minutes may struggle to complete the protocols.
Settings Request
----------------
The host signs the settings request to prove that the connection has opened to
the right party. Hosts announce on the blockchain and perform burn, therefore
identity is important.
1. The renter makes an RPC to the host, opening a connection. The connection
deadline should be at least 120 seconds.
2. The host sends the renter the most recent copy of its external settings,
signed by the host public key. The connection is then closed.
Revision Request
----------------
The renter requests a recent revision from the host. Often, this request
precedes modifications. A file contract can only be open for revision with one
party at a time. To prevent DoS attacks, the party must authenticate here by
performing a challenge-response protocol during the revision request. Putting
this challenge-response requirement in the revision-request can help improve
privacy, though the host is under no cryptographic or incentive-based
obligation to preserve the privacy of the revision.
1. The renter makes an RPC to the host, opening a connection. The connection
deadline should be at least 120 seconds. The renter sends the file contract
id for the revision being requested.
2. The host writes 32 bytes of random data that the renter must sign for the
renter key in the corresponding file contract.
3. The renter returns the signed challenge.
4. The host verifies the signature from the renter and then sends the renter
the most recent file contract revision, along with the transaction
signatures from both the renter and the host. The connection is then closed.
File Contract Creation
----------------------
A few decisions were made regarding the file contract protocol. The first is
that the renter should not sign the file contract until the host has formally
accepted the file contract. The second is that the host should be the last one
to sign the file contract, as the renter is the party with the strong
reputation system.
Instead of sending a whole transaction each time, the transaction is sent
piecemeal, and only the new parts at each step are sent to the other party.
This minimizes the surface area of data for a malicious party to manipulate,
which means less verification code, which means less chances of having a bug in
the verification code.
The renter pays for the siafund fee on the host's collateral and contract fee.
If a renter opens a file contract and then never uses it, the host does not
lose money. This does put the renter at risk, as they may open up a file
contract and then watch the host leave, but the renter is spreading the risk
over communications with many hosts, and has a reputation system that will help
ensure that the renter is only dealing with upstanding hosts.
1. The renter makes an RPC to the host, opening a connection. The connection
deadline should be at least 360 seconds.
2. The host sends the renter the most recent copy of its settings, signed. If
the host is not accepting new file contracts, the connection is closed.
3. The renter sends a notice of acceptance or rejection. If the renter accepts,
the renter then sends a funded file contract transaction without a
signature, followed by the public key that will be used to create the
renter's portion of the UnlockConditions for the file contract.
4. The host sends an acceptance or rejection of the file contract. If the host
accepts, the host will add collateral to the file contract, and will send
the renter the inputs + outputs for the collateral, followed by any new
parent transactions. The length of any of these may be zero.
5. The renter indicates acceptance or rejection of the file contract. If the
renter accepts, the renter will sign the file contract and send the
transaction signatures to the host. The renter will also send a signature
for a no-op file contract revision that follows the file contract.
6. The host may only reject the file contract in the event that the renter has
sent invalid signatures, so the acceptance step is skipped. The host signs
the file contract and sends the transaction signatures to the renter, and
the host creates and sends a signature for the no-op revision that follows
the file contract. The connection is closed.
File Contract Revision
----------------------
1. The renter makes an RPC to the host, opening a connection. The minimum
deadline for the connection is 600 seconds. The renter then sends a file
contract ID, indicating the file contract that is getting revised during the
RPC.
2. The host will respond with a 32 byte challenge - a random 32 bytes that the
renter will need to sign.
3. The renter will sign the challenge with the renter key that protects the
file contract. This is to prove that the renter has access to the file
contract.
4. The host will verify the challenge signature, then send an acceptance or
rejection. If accetped, the host will send the most recent file contract
revision for the file contract along with the transaction signagtures that
validate the revision. The host will lock the file contract, meaning no
other changes can be made to the revision file contract until this
connection has closed.
A loop begins. The host sends the most recent revision of the host settings
to the renter, signed. The settings are sent after each iteration of the
loop to enable high resolution dynamic pricing for the host, especially for
bandwidth.
6. The renter may reject or accept the settings + revision. A specific
rejection message will gracefully terminate the loop here. The renter will
send an unsigned file contract revision followed by a batch of modification
actions which the revision pays for. Batching allows the renter to send a
lot of data in a single, one-way connection, improving throughput. The
renter will send a number indicating how many modifications will be made in
a batch, and then sends each modification in order.
A single modification can either be an insert, a modify, or a delete. An
insert is an index, indicating the index where the data is going to be
inserted. '0' indicates that the data is inserted at the very beginning, '1'
indicates that the data will be inserted between the first and second
existing sectors, etc. The index is followed by the 4MB of data. A modify is
an index indicating which sector is being modified, followed by an offset
indicating which data within the sector is being modified. Finally, some
data is provided indicating what the data in the sector should be replaced
with starting from that offset. The offset + len of the data should not
exceed the sector size of 4MB. A delete is an index indicating the index of
the sector that is being deleted. Each operation within a batch is atomic,
meaning if you are inserting 3 sectors at the front of the file contract,
the indexes of each should be '0', '1', '2'.
7. The host indicates either acceptance or rejection of the new revision.
8. The renter signs the revision and sends the signature to the host.
9. The host signs the revision and sends the signature to the renter. Both
parties submit the new revision to the transaction pool. The connection
deadline is reset to 600 seconds (unless the maximum deadline has been
reached), and the loop restarts.
File Contract Renewal
---------------------
1. The renter makes an RPC to the host, opening a connection. The minimum
deadline for the connection is 600 seconds. The renter then sends a file
contract ID, indicating the file contract that is getting revised during the
RPC.
2. The host will respond with a 32 byte challenge - a random 32 bytes that the
renter will need to sign.
3. The renter will sign the challenge with the renter key that protects the
file contract. This is to prove that the renter has access to the file
contract.
4. The host will verify the challenge signature, then send an acceptance or
rejection. If accetped, the host will send the most recent file contract
revision for the file contract along with the transaction signagtures that
validate the revision. The host will lock the file contract, meaning no
other changes can be made to the revision file contract until this
connection has closed. The host sends the most recent revision of the host
settings to the renter, signed. If the host is not accepting new file
contracts, the connection is closed.
5. The renter either accepts or rejects the settings. If accepted, the renter
sends a funded, unsigned file contract to the host, containing the same
Merkle root as the previous file contract, and also containing a renewed
payout with conditional payments to the host to cover the host storing the
data for the extended duration.
6. The host will accept or reject the renewed file contract. If accepted, the
host will add collateral (and miner fees if desired) and send the inputs +
outputs for the collateral, along with any new parent transactions. The
length of any of these may be zero.
7. The renter will accept or reject the host's additions. If accepting, the
renter will send signatures for the transaction to the host. The renter will
also send a signature for a no-op file contract revision that follows the
file contract.
8. The host may only reject the file contract in the event that the renter has
sent invalid signatures, so the acceptance step is skipped. The host signs
the file contract and sends the transaction signatures to the renter, and
the host creates and sends a signature for the no-op revision that follows
the file contract. The connection is closed.
Data Request
------------
1. The renter makes an RPC to the host, opening a connection. The connection
deadline is at least 600 seconds. The renter will send a file contract id
corresponding to the file contract that will be used to pay for the
download.
2. The host will respond with a 32 byte challenge - a random 32 bytes that the
renter will need to sign.
3. The renter will sign the challenge with the public key that protects the
file contract being used to pay for the download. This proves that the
renter has access to the payment.
4. The host will verify the challenge signature, and then send an acceptance or
rejection. If accepted, the host will send the most recent file contract
revision followed by the signautres that validate the revision. The host
will lock the file contract, preventing other connections from making
changes to the underlying storage obligation.
A loop begins. The host sends the most recent external settings to the
renter, signed. The settings are sent each iteration to provide high
resolution dynamic bandwidth pricing.
5. The host will send the renter the most recent file contract revision, along
with the signatures that validate the revision.
A loop begins, which will allow the renter to download multiple batches of
data from the same connection. The host will send the host settings, and the
most recent file contract revision transaction. If there is no revision yet,
the host will send a blank transaction. The host is expected to always have
the most recent revision (the host signs last), the renter may not have the
most recent revision.
6. The renter will accept or reject the host's settings. If accepting, the
renter will send a file contract revision, unsigned, to pay for the download
request. The renter will then send the download request itself.
7. The host will either accept or reject the revision.
8. The renter will send a signature for the file contract revision.
9. The host sends a signature for the file contract revision, followed by the
data that was requested by the download request. The loop starts over, and
the connection deadline is reset to a minimum of 600 seconds.

250
3rd_party/Sia-v1.1.1-windows-amd64/doc/Guide to Contributing to Sia.md vendored
View File

@@ -1,250 +0,0 @@
# Contributing to Sia
#### Table of Contents
* [Get started with Go](#go)
* [Install Go](#install-go)
* [Learn Go]("learn-go")
* [Build Sia](#build-sia)
* [Contribute to the codebase](#contribute)
* [Set up git](#setup-git)
* [Fork the Sia repository](#fork)
* [Write some code](#write)
* [Submit your code for review](#pull)
* [More git resources](#git-resources)
* [Where to start](#where-to-start)
* [Contact us](#contact)
<a name="go"/>
## Get started with Go
<a name="install-go"/>
### Install Go
To install Go on your computer, follow the
[official installation guide][install-go].
You should install the latest [official Go binary][binary] for your system (if
not available, [install from source][source]). If you plan to cross compile
Sia, see [Cross Compilation with Go 1.5][cross] by Dave Cheney.
Now make a workspace directory in which you will store source code and
dependencies. You can choose any filepath except where you installed Go (don't
choose `/usr/local`).
```bash
# make a working directory called golang in your home directory
$ mkdir $HOME/golang
# store base path in an environmental variable
$ echo 'export GOPATH=$HOME/golang' >> $HOME/.profile
# add bin subdirectory to PATH environmental variable
$ echo 'export PATH=$PATH:$GOPATH/bin' >> $HOME/.profile
```
<a name="learn-go"/>
### Learn Go
* To get familiar with the language, start with the official [Tour of Go][tour].
* Move onto [How to Write Go Code][how] to learn how to organize Go packages
and use the go tool.
* Finish with the [Effective Go][effective] guide.
<a name="build-sia"/>
## Build Sia
To build Sia on your machine, enter the following on the command line:
```bash
# Download Sia and its dependencies
# Binaries will be installed in $GOPATH/bin
$ go get -u github.com/NebulousLabs/Sia/...
# Switch to directory containing Sia source code
$ cd $GOPATH/src/github.com/NebulousLabs/Sia
# You have three Sia builds to choose from.
# To build the standard release binary:
$ make release-std
# Or to build the release binary with race detection and an array debugging
# asserts:
$ make release
# Or to build the developer binary (with a different genesis block, faster
# block times, and other changes):
$ make
```
<a name="contribute"/>
## Contribute to the codebase
<a name="setup-git"/>
### Set up git
Install git on your machine according to [these instructions][install-git] in
the Pro Git book.
You will first need to set up global settings using the command line.
```bash
$ git config --global user.name "Your Name"
$ git config --global user.email you@somedomain.com
# Tell git to remember your login information for a certain amount of time.
# Default time is 15 minutes:
$ git config --global credential.helper cache
# Or you can choose a different amount of time:
$ git config --global credential.helper "cache --timeout=[seconds]"
```
<a name="fork"/>
### Fork the Sia repository
While logged into your Github account, navigate to the [Sia repository][sia]
and click the 'Fork' button in the upper righthand corner. Your account now
has a 'forked' copy of the original repo at
`https://github.com/<your GitHub username>/Sia`.
When you installed Sia using `go get`, the go tool put the Sia source code in
$GOPATH/src/github.com/NebulousLabs/Sia. Change to that directory and set up
your fork as a git [remote][remote]:
```bash
$ cd $GOPATH/src/github.com/NebulousLabs/Sia
# Add your fork as a remote. Name it whatever is convenient,
# e.g your GitHub username
$ git remote add <remote name> https://github.com/<username>/Sia.git
```
<a name="write">
### Write some code
Right now your git local repository only has one branch (called 'master' by
default). If you want to make changes, add a new branch and make your changes
there. You should maintain master as an up-to-date copy of the NebulousLabs/Sia
repository's master branch.
To create and checkout a new branch:
```bash
# If you're not already in the right directory:
$ cd $GOPATH/src/NebulousLabs/Sia
# Make sure you're on branch master
$ git checkout master
# Create and checkout a new branch
$ git checkout -b <branch>
```
Now write some code while the new branch is checked out.
Only implement one logical change per branch. If you're working on several
things at once, make multiple branches. To switch between branches you're
working on, you have to stash the changes in the branch you're switching from
by running `git stash`, which tucks away all changes since the last
commit.
```bash
# Stash changes to current branch.
$ git stash
# Checkout other branch.
$ git checkout <branch>
...
# Make changes
...
# Return to first branch:
$ git checkout <branch 1>
# View a list of stashes and their corresponding hashes.
$ git stash list
# Reapply changes from the stash you want to recover and remove that stash from.
# the list
$ git stash pop <hash>
```
To learn more about branching, see
[Using the Fork-and-Branch Git Workflow][branch] and
[Pro Git - Branches in a Nutshell][nutshell].
For more on stashing, see [Pro Git - Stashing and Cleaning][stashing].
Be sure to follow the conventions detailed in
[docs/Developers.md][developers.md]. We will reject pull requests that do not
satisfy these best practices.
Once you've finished making changes, stage and commit your changes then update
your fork on Github:
```bash
# Make sure the code is up to date with the original repo:
$ git checkout master
$ git pull origin master
# Checkout branch with changes.
$ git checkout <branch>
$ git rebase master
# Before every pull request, you should run `make test-long`
# to test your code and fix formatting and style problems.
$ make test-long
# If all goes well, proceed to staging your changed files:
$ git add <changed files>
# Use `git status` to see what files have been staged.
$ git status
# Commit your changes. If you just run `commit`, a text editor will pop up for
# you to enter a description of your changes.
$ git commit -m "Add new tests for CommitSync method"
# Push the changes to your fork on GitHub, which you should have set up as a
# remote already.
$ git push <fork remote> <branch>
```
<a name="pull"/>
### Submit your code for review
Once you've tested your new code and pushed changes to your fork, navigate to
your fork at `https://github.com/<username>/Sia` in your browser.
Switch to the branch you've made changes on by selecting it from the list on
the upper left. Then click 'New pull request' on the upper right.
Once you have made the pull request, we will review your code. We will reject
code that is unsafe, difficult to read, or otherwise violates the conventions
outlined in [docs/Developers.md][developers.md].
Here's a sample code review comment:
![Screenshot](assets/codereview.png)
If you want to tweak code for which you've already submitted a pull request,
push the updated code to your fork with `git push -f <fork remote> <branch>` and
summarize the changes you've made in a comment on the pull request page on
GitHub.
Once we have accepted your changes and merged them into the original repo, you
have some cleanup to do:
```bash
# Update local master branch to reflect changes in origin (the original
# repo).
$ git pull origin master
# Delete the branch you made the pull request from.
$ git branch -d <branch>
# Delete the remote branch on your fork.
$ git push <fork remote> :<branch>
# Update your fork.
$ git push <fork remote> master
```
<a name="git-resources"/>
### More Git resources
* [How to into git (and Github)][luke] by Luke Champine
* [Official resources for learning Git][git]
<a name="where-to-start"/>
## Where to start
If you'd like to contribute to Sia but don't have any specific ideas, writing
tests is a good way to get your feet wet. See [doc/Running and Writing Tests for Sia.md](Running\ and\ Writing\ Tests\ for\ Sia.md) to get started.
<a name="contact"/>
## Contact us
Feel free to ask for help on the #dev channel on [Slack][slack].
[cross]: http://dave.cheney.net/2015/08/22/cross-compilation-with-go-1-5
[binary]: https://golang.org/dl/
[source]: https://golang.org/doc/install/source
[tour]: https://tour.golang.org/welcome/1
[how]: https://golang.org/doc/code.html
[luke]: https://gist.github.com/lukechampine/6418449
[git]: https://git-scm.com/doc
[cheney]: http://dave.cheney.net/2013/06/09/writing-table-driven-tests-in-go
[install-go]: https://golang.org/doc/install
[signup]: https://github.com/join?source=header-home
[effective]: https://golang.org/doc/effective_go.html
[sia]: https://github.com/NebulousLabs/Sia
[branch]: http://blog.scottlowe.org/2015/01/27/using-fork-branch-git-workflow/
[developers.md]: https://github.com/NebulousLabs/Sia/blob/master/doc/Developers.md
[gofmt]: https://golang.org/cmd/gofmt/
[nutshell]: https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
[slack]: http://slackin.siacoin.com
[install-git]: https://git-scm.com/book/en/v2/Getting-Started-Installing-Git
[test-doc]: https://github.com/NebulousLabs/Sia/blob/master/doc/Testing.md
[stashing]: https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning
[remote]: https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes

35
3rd_party/Sia-v1.1.1-windows-amd64/doc/Modules.md vendored
View File

@@ -1,35 +0,0 @@
Module Conventions
==================
Each module has a file/directory where they store persistent data (if
necessary). When module.New is called, the module is responsible for creating
and populating that directory. The logic for saving and loading data belongs in
persist.go.
Modules that depend on external information (such as the state of consensus)
have an update.go to manage fetching and integrating the external information.
If that information is coming from another module, a subscription should be
used. Module subscription uses a ModuleSubscriber interface (which the
subscriber must satisfy) and a ModuleSubscribe method (implemented by the
parent module). As the parent module gets updates, it will call
ReceiveModuleUpdate (the only method of the ModuleSubscriber interface) on all
subscribers, taking care that each subscriber always receives the updates in
the correct order. This method of subscription is chosen to keep information
flow simple and synchronized - a child module should never have information
that the parent module does not (it just causes problems).
For testing, it is often important to know that an update has propagated to all
modules. Any module that subscribes to another must also implement a
ModuleNotify function in subscriptions.go. ModuleNotify returns a channel down
which a struct{} will be sent every time that module receives an update from a
parent module. To keep things simple, a module should not subscribe to the
parent of another module that it is subscribed to. For example, the transaction
pool is subscribed to the consensus set. Therefore, no module should subscribe
to both the transaction pool and the consensus set. All consensus set updates
should be received through the transaction pool. This helps with
synchronization and ensures that no child module ever has information that the
parent module has not yet received (desynchronization).
#### Module Update Flow
consensus -> (host, hostdb, renter, (transaction pool -> miner, wallet))

256
3rd_party/Sia-v1.1.1-windows-amd64/doc/Running and Writing Tests for Sia.md vendored
View File

@@ -1,256 +0,0 @@
# Running and Writing Tests for Sia
Improving test coverage is a great way to start contributing to Sia.
This guide focuses on how to write tests. To learn about making pull requests
to submit the code you've written, see
[doc/Guide to Contributing to Sia.md][guide]. You should also read
[doc/Developers.md][developers] to learn about Sia code conventions and quality
standards.
#### Table of Contents
* [Running tests for Sia](#existing)
* [Updating code before testing](#update)
* [Testing the entire build](#entire)
* [Testing a particular package](#particular)
* [Writing new tests for Sia](#write)
* [A few guidelines](#naming)
* [Basic test format](#basic)
* [Table-driven tests](#table)
* [Questions?](#questions)
<a name="existing"/>
## Running tests for Sia
Go's comprehensive [test package][pkg/testing] makes testing straightforward,
particularly when you use the bundled tools included in the
[Sia makefile][makefile], including `make test`, `make cover`, `make bench`,
and their variants.
<a name="update"/>
### Updating code before testing
If you just want to run existing tests on the codebase as is, you just need to
pull the latest version of the original repo to your master branch. (If that
sentence didn't make sense, go read
[doc/Guide to Contributing to Sia.md][guide].)
```bash
# Make sure you are in the right directory.
$ cd $GOPATH/src/github.com/<your Github username>/Sia
# Also make sure you're working with the right branch.
$ git checkout master
# Pull latest changes from origin, the original Sia repo.
$ git pull origin master
# Update your fork of the repo, which should be set up as a remote.
$ git push <remote> master
```
If you want to run tests on the new code you've added, first make sure the rest
of the code is up to date. New code should be on its own branch (again, see
[doc/Guide to Contributing to Sia.md][guide]).
```bash
# Make sure you are in the right directory.
$ cd $GOPATH/src/github.com/<your Github username>/Sia
# Checkout the branch you made the changes on.
$ git checkout <branch name>
# Stash any tracked but uncommitted changes.
$ git stash
# Then switch back to `master` and update it to match the original repo.
$ git checkout master
$ git pull origin master
# Update your fork of the repo, which you should have set up as a remote.
$ git push <remote> master
# Make the updated `master` the new base of the branch you made the changes on,
# which involves reapplying all the commits made to that branch. Without the
# `--ignore-date` flag, git rebase changes the date on all the commits to the
# current date.
$ git checkout <branch name>
$ git rebase master --ignore-date
# Restore the changes you stashed earlier.
$ git stash pop
```
When you call `rebase`, you may run into some merge conflicts. Luke Champine's
['How to into git and GitHub'][luke] has more details (and many useful tricks).
Once the branch you want to test is up to date, you're ready to run some tests.
<a name="entire"/>
### Testing the entire build
The `make test` command runs all tests (functions starting with `Test` in
`_test.go` files) for each package, setting off a panic for any test that runs
longer than 5s. For verbose output, run `make test-v` (which panics after 15s
instead of 5s). Finally, `make test-long` has verbose output, only panics when
a test takes 5 minutes, and also cleans up your code using `gofmt` and `golint`.
**You should run** `make test-long` **before each pull request.**
Run `make cover` to run all tests for each package and generate color-coded
.html visualizations of test coverage by function for each source file. Open
`cover/<module>.html` in a browser to inspect a module's test coverage. For
example, here's part of the html file generated for the persist package:
![Screenshot](assets/covertool.png)
Meanwhile, `make bench` will call `gofmt` on all packages, then run all
benchmarks (functions starting with `Benchmark` in `_test.go` files).
<a name="particular"/>
### Testing a particular package or function
To run tests for just a certain package, run `make test pkgs=./<package>`. To run
a certain test function, run `make test pkgs=./<package> run=<function>`. The same
goes for `make test-long`, `make cover` and `make bench`.
For example, running `test-long` on the package persist produces this output:
```bash
$ make test-long pkgs=./persist
rm -rf release doc/whitepaper.aux doc/whitepaper.log doc/whitepaper.pdf
gofmt -s -l -w ./persist
go install ./persist
go vet ./persist
go test -v -race -tags='testing debug' -timeout=300s ./persist -run=Test
=== RUN TestOpenDatabase
--- PASS: TestOpenDatabase (0.42s)
=== RUN TestSaveLoad
--- PASS: TestSaveLoad (0.00s)
=== RUN TestSaveLoadFile
--- PASS: TestSaveLoadFile (0.01s)
=== RUN TestSaveLoadFileSync
--- PASS: TestSaveLoadFileSync (0.00s)
=== RUN TestLogger
--- PASS: TestLogger (0.00s)
=== RUN TestLoggerCritical
--- PASS: TestLoggerCritical (0.00s)
=== RUN TestIntegrationRandomSuffix
--- PASS: TestIntegrationRandomSuffix (0.01s)
=== RUN TestAbsolutePathSafeFile
--- PASS: TestAbsolutePathSafeFile (0.00s)
=== RUN TestRelativePathSafeFile
--- PASS: TestRelativePathSafeFile (0.00s)
PASS
ok github.com/NebulousLabs/Sia/persist 1.485s
$
```
<a name="write"/>
## Writing new tests for Sia
When you run `make cover`, you'll notice that many files have pretty low
coverage. We're working on fixing that, but we could use your help.
<a name="naming"/>
### A few guidelines
* The test functions for `filename.go` should go in `filename_test.go` in the
same directory and package.
* A test function name should start with `Test` and clearly convey what is
being tested.
* You should declare function-specific variables and constants locally (inside
the test function) instead of globally (outside the test function). [That
holds in general][global], not just for tests.
* As always, code should adhere to the standards and conventions laid out in
[doc/Developers.md][developers].
<a name="basic"/>
### Basic test format
Suppose we'd like to test the Bar method belonging to type Foo.
```go
// TestFoo checks that the Bar method on type Foo responds correctly to a normal
// input and returns the expected error when given a bad input.
func TestFoo(t *testing.T) {
foo, err := NewFoo()
if err != nil {
// If NewFoo failed, we can't continue testing.
t.Fatal(err)
}
// Try a normal input; should succeed.
err := foo.Bar(3)
if err != nil {
// Report the error, but don't abort the test.
t.Error(err)
}
// Try a bad input; should return an error.
// NOTE: Always prefer to compare to a specific error, rather than
// err == nil
err = Foo.Bar(0)
if err != errDivideByZero {
t.Errorf("expected errDivideByZero, got %v", err)
}
}
```
<a name="table"/>
### Table-driven tests in Go
If you're looking to test a bunch of inputs, write a [table-driven test][table]
with a slice of anonymous structs. For example, see `TestParseFileSize` in
[siac/parse_test.go][parse_test]:
```go
func TestParseFilesize(t *testing.T) {
// Define a table of test cases in the form of a slice of anonymous structs.
tests := []struct {
in, out string
err error
}{
{"1b", "1", nil},
{"1KB", "1000", nil},
{"1MB", "1000000", nil},
{"1GB", "1000000000", nil},
{"1TB", "1000000000000", nil},
{"1KiB", "1024", nil},
{"1MiB", "1048576", nil},
{"1GiB", "1073741824", nil},
{"1TiB", "1099511627776", nil},
{"", "", errUnableToParseSize},
{"123", "123", nil},
{"123TB", "123000000000000", nil},
{"123GiB", "132070244352", nil},
{"123BiB", "", errUnableToParseSize},
{"GB", "", errUnableToParseSize},
{"123G", "", errUnableToParseSize},
{"123B99", "", errUnableToParseSize},
{"12A3456", "", errUnableToParseSize},
{"1.23KB", "1230", nil},
{"1.234KB", "1234", nil},
{"1.2345KB", "1234", nil},
}
// Loop through the table of test cases to make sure ParseFileSize returns
// the expected output and error for each.
for _, test := range tests {
res, err := parseFilesize(test.in)
if res != test.out || err != test.err {
t.Errorf("parseFilesize(%v): expected %v %v, got %v %v", test.in, test.out, test.err, res, err)
}
}
}
```
<a name="questions"/>
## Questions?
Read these if you haven't already:
* [doc/Guide to Contributing to Sia.md][guide]: getting started with Go, Sia,
and git
* [doc/Developers.md][developers]: conventions and quality standards for Sia
code
Some other useful resources, some of which have been linked to already:
* [Golang.org page on the go testing package][pkg/testing]
* [Writing Table-Driven Tests in Go][table]
* [How to Write Benchmarks in Go][cheney-benchmarks]
* [How to into git and GitHub][luke]: an essential introduction to git
And feel free to ask questions on the [#dev channel][slack] on the Sia Slack.
Odds are, someone else is wondering the same thing.
[pkg/testing]: https://golang.org/pkg/testing/
[makefile]: https://github.com/NebulousLabs/Sia/blob/master/Makefile
[luke]: https://gist.github.com/lukechampine/6418449
[guide]: https://github.com/NebulousLabs/Sia/blob/master/doc/Guide%20to%20Contributing%20to%20Sia.md
[developers]: https://github.com/NebulousLabs/Sia/blob/master/doc/Developers.md
[table]: http://dave.cheney.net/2013/06/09/writing-table-driven-tests-in-go
[boltdb_test.go]: https://github.com/NebulousLabs/Sia/blob/master/persist/boltdb_test.go
[cheney-benchmarks]: http://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go
[pkg/testing]: https://golang.org/pkg/testing/
[slack]: https://siatalk.slack.com/messages/dev/
[parse_test]: https://github.com/NebulousLabs/Sia/blob/master/siac/parse_test.go
[global]: http://c2.com/cgi/wiki?GlobalVariablesAreBad

61
3rd_party/Sia-v1.1.1-windows-amd64/doc/Standard.md vendored
View File

@@ -1,61 +0,0 @@
Standard Transaction Rules
==========================
Some transactions will not be accepted by miners unless they appear in a block.
This is equivalent to the 'IsStandard' function in Bitcoin. This file dictates
the rules for standard Sia transactions.
Transaction Size
----------------
Consensus rules limit the size of a block, but not the size of a transaction.
Standard rules however limit the size of a single transaction to 16kb.
A chain of dependent transactions cannot exceed 500kb.
Double Spend Rules
------------------
When two conflicting transactions are seen, the first transaction is the only
one that is kept. If the blockchain reorganizes, the transaction that is kept
is the transaction that was most recently in the blockchain. This is to
discourage double spending, and enforce that the first transaction seen is the
one that should be kept by the network. Other conflicts are thrown out.
Transactions are currently included into blocks using a first-come first-serve
algorithm. Eventually, transactions will be rejected if the fee does not meet a
certain minimum. For the near future, there are no plans to prioritize
transactions with substantially higher fees. Other mining software may take
alternative approaches.
File Contract Rules
-------------------
File Contracts that start in less than 10 blocks time are not accepted into the
transaction pool. This is because a file contract becomes invalid if it is not
accepted into the blockchain by the start block, and this might result in a
cascade of invalidated unconfirmed transactions, which may make it easier to
launch double spend attacks on zero confirmation outputs. 10 blocks is plenty
of time on the other hand for a file contract to make it into the blockchain.
Signature Algorithms
--------------------
Miners will reject transactions that have public keys using algorithms that the
miner does not understand.
Arbitrary Data Usage
--------------------
Arbitrary data can be used to make verifiable announcements, or to have other
protocols sit on top of Sia. The arbitrary data can also be used for soft
forks, and for protocol relevant information. Any arbitrary data is allowed by
consensus, but only certain arbitrary data is considered standard.
Arbitrary data that is prefixed by the string 'NonSia' is always allowed. This
indicates that the remaining data has no relevance to Sia protocol rules, and
never will.
Arbitrary data that is prefixed by the string 'HostAnnouncement' is allowed,
but only if the data within accurately decodes to the HostAnnouncement struct
found in modules/hostdb.go, and contains no extra information.

61
3rd_party/Sia-v1.1.1-windows-amd64/doc/api/Consensus.md vendored
View File

@@ -1,61 +0,0 @@
Consensus API
=============
This document contains detailed descriptions of the consensus's API routes. For
an overview of the consensus' API routes, see
[API.md#consensus](/doc/API.md#consensus). For an overview of all API routes,
see [API.md](/doc/API.md)
There may be functional API calls which are not documented. These are not
guaranteed to be supported beyond the current release, and should not be used
in production.
Overview
--------
The consensus set manages everything related to consensus and keeps the
blockchain in sync with the rest of the network. The consensus set's API
endpoint returns information about the state of the blockchain.
Index
-----
| Route | HTTP verb |
| --------------------------------------------------------------------------- | --------- |
| [/consensus](#consensus-get) | GET |
| [/consensus/validate/transactionset](#consensusvalidatetransactionset-post) | POST |
#### /consensus [GET]
returns information about the consensus set, such as the current block height.
###### JSON Response
```javascript
{
// True if the consensus set is synced with the network, i.e. it has downloaded the entire blockchain.
"synced": true,
// Number of blocks preceding the current block.
"height": 62248,
// Hash of the current block.
"currentblock": "00000000000008a84884ba827bdc868a17ba9c14011de33ff763bd95779a9cf1",
// An immediate child block of this block must have a hash less than this
// target for it to be valid.
"target": [0,0,0,0,0,0,11,48,125,79,116,89,136,74,42,27,5,14,10,31,23,53,226,238,202,219,5,204,38,32,59,165]
}
```
#### /consensus/validate/transactionset [POST]
validates a set of transactions using the current utxo set.
###### Request Body Bytes
Since transactions may be large, the transaction set is supplied in the POST
body, encoded in JSON format.
###### Response
standard success or error response. See
[#standard-responses](#standard-responses).

100
3rd_party/Sia-v1.1.1-windows-amd64/doc/api/Daemon.md vendored
View File

@@ -1,100 +0,0 @@
Daemon API
===========
This document contains detailed descriptions of the daemon's API routes. For an
overview of the daemon's API routes, see [API.md#daemon](/doc/API.md#daemon).
For an overview of all API routes, see [API.md](/doc/API.md)
There may be functional API calls which are not documented. These are not
guaranteed to be supported beyond the current release, and should not be used
in production.
Overview
--------
The daemon is responsible for starting and stopping the modules which make up
the rest of Sia. It also provides endpoints for viewing build constants.
Index
-----
| Route | HTTP verb |
| ----------------------------------------- | --------- |
| [/daemon/constants](#daemonconstants-get) | GET |
| [/daemon/stop](#daemonstop-get) | GET |
| [/daemon/version](#daemonversion-get) | GET |
#### /daemon/constants [GET]
returns the set of constants in use.
###### JSON Response
```javascript
{
// Timestamp of the genesis block.
"genesistimestamp": 1433600000, // Unix time
// Maximum size, in bytes, of a block. Blocks larger than this will be
// rejected by peers.
"blocksizelimit": 2000000, // bytes
// Target for how frequently new blocks should be mined.
"blockfrequency": 600, // seconds per block
// Height of the window used to adjust the difficulty.
"targetwindow": 1000, // blocks
// Duration of the window used to adjust the difficulty.
"mediantimestampwindow": 11, // blocks
// How far in the future a block can be without being rejected. A block
// further into the future will not be accepted immediately, but the daemon
// will attempt to accept the block as soon as it is valid.
"futurethreshold": 10800, // seconds
// Total number of siafunds.
"siafundcount": "10000",
// Fraction of each file contract payout given to siafund holders.
"siafundportion": "39/1000",
// Number of children a block must have before it is considered "mature."
"maturitydelay": 144, // blocks
// Number of coins given to the miner of the first block. Note that elsewhere
// in the API currency is typically returned in hastings and as a bignum.
// This is not the case here.
"initialcoinbase": 300000, // Siacoins.
// Minimum number of coins paid out to the miner of a block (the coinbase
// decreases with each block). Note that elsewhere in the API currency is
// typically returned in hastings and as a bignum. This is not the case
// here.
"minimumcoinbase": 30000, // Siacoins
// Initial target.
"roottarget": [0,0,0,0,32,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
// Initial depth.
"rootdepth": [255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255],
// Largest allowed ratio between the old difficulty and the new difficulty.
"maxadjustmentup": "5/2",
// Smallest allowed ratio between the old difficulty and the new difficulty.
"maxadjustmentdown": "2/5",
// Number of Hastings in one siacoin.
"siacoinprecision": "1000000000000000000000000" // hastings per siacoin
}
```
#### /daemon/stop [GET]
cleanly shuts down the daemon. May take a few seconds.
###### Response
standard success or error response. See
[#standard-responses](#standard-responses).
#### /daemon/version [GET]
returns the version of the Sia daemon currently running.
###### JSON Response
```javascript
{
// Version number of the running Sia Daemon. This number is visible to its
// peers on the network.
"version": "1.0.0"
}
```

159
3rd_party/Sia-v1.1.1-windows-amd64/doc/api/Gateway.md vendored
View File

@@ -1,159 +0,0 @@
Gateway API
===========
This document contains detailed descriptions of the gateway's API routes. For
an overview of the gateway's API routes, see
[API.md#gateway](/doc/API.md#gateway). For an overview of all API routes, see
[API.md](/doc/API.md)
There may be functional API calls which are not documented. These are not
guaranteed to be supported beyond the current release, and should not be used
in production.
Overview
--------
The gateway maintains a peer to peer connection to the network and provides a
method for calling RPCs on connected peers. The gateway's API endpoints expose
methods for viewing the connected peers, manually connecting to peers, and
manually disconnecting from peers. The gateway may connect or disconnect from
peers on its own.
Index
-----
| Route | HTTP verb | Examples |
| ---------------------------------------------------------------------------------- | --------- | ------------------------------------------------------- |
| [/gateway](#gateway-get-example) | GET | [Gateway info](#gateway-info) |
| [/gateway/connect/___:netaddress___](#gatewayconnectnetaddress-post-example) | POST | [Connecting to a peer](#connecting-to-a-peer) |
| [/gateway/disconnect/___:netaddress___](#gatewaydisconnectnetaddress-post-example) | POST | [Disconnecting from a peer](#disconnecting-from-a-peer) |
#### /gateway [GET] [(example)](#gateway-info)
returns information about the gateway, including the list of connected peers.
###### JSON Response
```javascript
{
// netaddress is the network address of the gateway as seen by the rest of
// the network. The address consists of the external IP address and the
// port Sia is listening on. It represents a `modules.NetAddress`.
"netaddress": String,
// peers is an array of peers the gateway is connected to. It represents
// an array of `modules.Peer`s.
"peers": []{
// netaddress is the address of the peer. It represents a
// `modules.NetAddress`.
"netaddress": String,
// version is the version number of the peer.
"version": String,
// inbound is true when the peer initiated the connection. This field
// is exposed as outbound peers are generally trusted more than inbound
// peers, as inbound peers are easily manipulated by an adversary.
"inbound": Boolean
}
}
```
#### /gateway/connect/{netaddress} [POST] [(example)](#connecting-to-a-peer)
connects the gateway to a peer. The peer is added to the node list if it is not
already present. The node list is the list of all nodes the gateway knows
about, but is not necessarily connected to.
###### Path Parameters
```
// netaddress is the address of the peer to connect to. It should be a
// reachable ip address and port number, of the form 'IP:port'. IPV6 addresses
// must be enclosed in square brackets.
//
// Example IPV4 address: 123.456.789.0:123
// Example IPV6 address: [123::456]:789
:netaddress
```
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).
#### /gateway/disconnect/{netaddress} [POST] [(example)](#disconnecting-from-a-peer)
disconnects the gateway from a peer. The peer remains in the node list.
Disconnecting from a peer does not prevent the gateway from automatically
connecting to the peer in the future.
###### Path Parameters
```
// netaddress is the address of the peer to connect to. It should be a
// reachable ip address and port number, of the form 'IP:port'. IPV6 addresses
// must be enclosed in square brackets.
//
// Example IPV4 address: 123.456.789.0:123
// Example IPV6 address: [123::456]:789
:netaddress
```
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).
Examples
--------
#### Gateway info
###### Request
```
/gateway
```
###### Expected Response Code
```
200 OK
```
###### Example JSON Response
```json
{
"netaddress":"333.333.333.333:9981",
"peers":[
{
"netaddress":"222.222.222.222:9981",
"version":"1.0.0",
"inbound":false
},
{
"netaddress":"111.111.111.111:9981",
"version":"0.6.0",
"inbound":true
}
]
}
```
#### Connecting to a peer
###### Request
```
/gateway/connect/123.456.789.0:123
```
###### Expected Response Code
```
204 No Content
```
#### Disconnecting from a peer
###### Request
```
/gateway/disconnect/123.456.789.0:123
```
###### Expected Response Code
```
204 No Content
```

536
3rd_party/Sia-v1.1.1-windows-amd64/doc/api/Host.md vendored
View File

@@ -1,536 +0,0 @@
Host API
--------
This document contains detailed descriptions of the host's API routes. For an
overview of the host's API routes, see [API.md#host](/doc/API.md#host). For an
overview of all API routes, see [API.md](/doc/API.md)
There may be functional API calls which are not documented. These are not
guaranteed to be supported beyond the current release, and should not be used
in production.
Overview
--------
The host provides storage from local disks to the network. The host negotiates
file contracts with remote renters to earn money for storing other users'
files. The host's endpoints expose methods for viewing and modifying host
settings, announcing to the network, and managing how files are stored on disk.
Index
-----
| Route | HTTP verb |
| ------------------------------------------------------------------------------------- | --------- |
| [/host](#host-get) | GET |
| [/host](#host-post) | POST |
| [/host/announce](#hostannounce-post) | POST |
| [/host/storage](#hoststorage-get) | GET |
| [/host/storage/folders/add](#hoststoragefoldersadd-post) | POST |
| [/host/storage/folders/remove](#hoststoragefoldersremove-post) | POST |
| [/host/storage/folders/resize](#hoststoragefoldersresize-post) | POST |
| [/host/storage/sectors/delete/___:merkleroot___](#hoststoragesectorsdeletemerkleroot) | POST |
#### /host [GET]
fetches status information about the host.
###### JSON Response
```javascript
{
// The settings that get displayed to untrusted nodes querying the host's
// status.
"externalsettings": {
// Whether or not the host is accepting new contracts.
"acceptingcontracts": true,
// The maximum size of a single download request from a renter. Each
// download request has multiple round trips of communication that
// exchange money. Larger batch sizes mean fewer round trips, but more
// financial risk for the host - the renter can get a free batch when
// downloading by refusing to provide a signature.
"maxdownloadbatchsize": 17825792, // bytes
// The maximum duration that a host will allow for a file contract. The
// host commits to keeping files for the full duration under the threat
// of facing a large penalty for losing or dropping data before the
// duration is complete. The storage proof window of an incoming file
// contract must end before the current height + maxduration.
"maxduration": 25920, // blocks
// The maximum size of a single batch of file contract revisions. The
// renter can perform DoS attacks on the host by uploading a batch of
// data then refusing to provide a signature to pay for the data. The
// host can reduce this exposure by limiting the batch size. Larger
// batch sizes allow for higher throughput as there is significant
// communication overhead associated with performing a batch upload.
"maxrevisebatchsize": 17825792, // bytes
// The IP address or hostname (including port) that the host should be
// contacted at.
"netaddress": "123.456.789.0:9982",
// The amount of unused storage capacity on the host in bytes. It
// should be noted that the host can lie.
"remainingstorage": 35000000000, // bytes
// The smallest amount of data in bytes that can be uploaded or
// downloaded when performing calls to the host.
"sectorsize": 4194304, // bytes
// The total amount of storage capacity on the host. It should be noted
// that the host can lie.
"totalstorage": 35000000000, // bytes
// The unlock hash is the address at which the host can be paid when
// forming file contracts.
"unlockhash": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789ab",
// The storage proof window is the number of blocks that the host has
// to get a storage proof onto the blockchain. The window size is the
// minimum size of window that the host will accept in a file contract.
"windowsize": 144, // blocks
// The maximum amount of money that the host will put up as collateral
// for storage that is contracted by the renter.
"collateral": "57870370370", // hastings / byte / block
// The maximum amount of collateral that the host will put into a
// single file contract.
"maxcollateral": "100000000000000000000000000000", // hastings
// The price that a renter has to pay to create a contract with the
// host. The payment is intended to cover transaction fees
// for the file contract revision and the storage proof that the host
// will be submitting to the blockchain.
"contractprice": "30000000000000000000000000", // hastings
// The price that a renter has to pay when downloading data from the
// host.
"downloadbandwidthprice": "250000000000000", // hastings / byte
// The price that a renter has to pay to store files with the host.
"storageprice": "231481481481", // hastings / byte / block
// The price that a renter has to pay when uploading data to the host.
"uploadbandwidthprice": "100000000000000", // hastings / byte
// The revision number indicates to the renter what iteration of
// settings the host is currently at. Settings are generally signed.
// If the renter has multiple conflicting copies of settings from the
// host, the renter can expect the one with the higher revision number
// to be more recent.
"revisionnumber": 0,
// The version of external settings being used. This field helps
// coordinate updates while preserving compatibility with older nodes.
"version": "1.0.0"
},
// The financial status of the host.
"financialmetrics": {
// Number of open file contracts.
"contractcount": 2,
// The amount of money that renters have given to the host to pay for
// file contracts. The host is required to submit a file contract
// revision and a storage proof for every file contract that gets created,
// and the renter pays for the miner fees on these objects.
"contractcompensation": "123", // hastings
// The amount of money that renters have given to the host to pay for
// file contracts which have not been confirmed yet. The potential
// compensation becomes compensation after the storage proof is
// submitted.
"potentialcontractcompensation": "123", // hastings
// The amount of storage collateral which the host has tied up in file
// contracts. The host has to commit collateral to a file contract even
// if there is no storage, but the locked collateral will be returned
// even if the host does not submit a storage proof - the collateral is
// not at risk, it is merely set aside so that it can be put at risk
// later.
"lockedstoragecollateral": "123", // hastings
// The amount of revenue, including storage revenue and bandwidth
// revenue, that has been lost due to failed file contracts and
// failed storage proofs.
"lostrevenue": "123", // hastings
// The amount of collateral that was put up to protect data which has
// been lost due to failed file contracts and missed storage proofs.
"loststoragecollateral": "123", // hastings
// The amount of revenue that the host stands to earn if all storage
// proofs are submitted corectly and in time.
"potentialstoragerevenue": "123", // hastings
// The amount of money that the host has risked on file contracts. If
// the host starts missing storage proofs, the host can forfeit up to
// this many coins. In the event of a missed storage proof, locked
// storage collateral gets returned, but risked storage collateral
// does not get returned.
"riskedstoragecollateral": "123", // hastings
// The amount of money that the host has earned from storing data. This
// money has been locked down by successful storage proofs.
"storagerevenue": "123", // hastings
// The amount of money that the host has spent on transaction fees when
// submitting host announcements, file contract revisions, and storage
// proofs.
"transactionfeeexpenses": "123", // hastings
// The amount of money that the host has made from renters downloading
// their files. This money has been locked in by successsful storage
// proofs.
"downloadbandwidthrevenue": "123", // hastings
// The amount of money that the host stands to make from renters that
// downloaded their files. The host will only realize this revenue if
// the host successfully submits storage proofs for the related file
// contracts.
"potentialdownloadbandwidthrevenue": "123", // hastings
// The amount of money that the host stands to make from renters that
// uploaded files. The host will only realize this revenue if the host
// successfully submits storage proofs for the related file contracts.
"potentialuploadbandwidthrevenue": "123", // hastings
// The amount of money that the host has made from renters uploading
// their files. This money has been locked in by successful storage
// proofs.
"uploadbandwidthrevenue": "123" // hastings
},
// The settings of the host. Most interactions between the user and the
// host occur by changing the internal settings.
"internalsettings": {
// When set to true, the host will accept new file contracts if the
// terms are reasonable. When set to false, the host will not accept new
// file contracts at all.
"acceptingcontracts": true,
// The maximum size of a single download request from a renter. Each
// download request has multiple round trips of communication that
// exchange money. Larger batch sizes mean fewer round trips, but more
// financial risk for the host - the renter can get a free batch when
// downloading by refusing to provide a signature.
"maxdownloadbatchsize": 17825792, // bytes
// The maximum duration of a file contract that the host will accept.
// The storage proof window must end before the current height +
// maxduration.
"maxduration": 25920, // blocks
// The maximum size of a single batch of file contract revisions. The
// renter can perform DoS attacks on the host by uploading a batch of
// data then refusing to provide a signature to pay for the data. The
// host can reduce this exposure by limiting the batch size. Larger
// batch sizes allow for higher throughput as there is significant
// communication overhead associated with performing a batch upload.
"maxrevisebatchsize": 17825792, // bytes
// The IP address or hostname (including port) that the host should be
// contacted at. If left blank, the host will automatically figure out
// its ip address and use that. If given, the host will use the address
// given.
"netaddress": "123.456.789.0:9982",
// The storage proof window is the number of blocks that the host has
// to get a storage proof onto the blockchain. The window size is the
// minimum size of window that the host will accept in a file contract.
"windowsize": 144, // blocks
// The maximum amount of money that the host will put up as collateral
// per byte per block of storage that is contracted by the renter.
"collateral": "57870370370", // hastings / byte / block
// The total amount of money that the host will allocate to collateral
// across all file contracts.
"collateralbudget": "2000000000000000000000000000000", // hastings
// The maximum amount of collateral that the host will put into a
// single file contract.
"maxcollateral": "100000000000000000000000000000", // hastings
// The minimum price that the host will demand from a renter when
// forming a contract. Typically this price is to cover transaction
// fees on the file contract revision and storage proof, but can also
// be used if the host has a low amount of collateral. The price is a
// minimum because the host may automatically adjust the price upwards
// in times of high demand.
"mincontractprice": "30000000000000000000000000", // hastings
// The minimum price that the host will demand from a renter when the
// renter is downloading data. If the host is saturated, the host may
// increase the price from the minimum.
"mindownloadbandwidthprice": "250000000000000", // hastings / byte
// The minimum price that the host will demand when storing data for
// extended periods of time. If the host is low on space, the price of
// storage may be set higher than the minimum.
"minstorageprice": "231481481481", // hastings / byte / block
// The minimum price that the host will demand from a renter when the
// renter is uploading data. If the host is saturated, the host may
// increase the price from the minimum.
"minuploadbandwidthprice": "100000000000000" // hastings / byte
},
// Information about the network, specifically various ways in which
// renters have contacted the host.
"networkmetrics": {
// The number of times that a renter has attempted to download
// something from the host.
"downloadcalls": 0,
// The number of calls that have resulted in errors. A small number of
// errors are expected, but a large number of errors indicate either
// buggy software or malicious network activity. Usually buggy
// software.
"errorcalls": 1,
// The number of times that a renter has tried to form a contract with
// the host.
"formcontractcalls": 2,
// The number of times that a renter has tried to renew a contract with
// the host.
"renewcalls": 3,
// The number of times that the renter has tried to revise a contract
// with the host.
"revisecalls": 4,
// The number of times that a renter has queried the host for the
// host's settings. The settings include the price of bandwidth, which
// is a price that can adjust every few minutes. This value is usually
// very high compared to the others.
"settingscalls": 5,
// The number of times that a renter has attempted to use an
// unrecognized call. Larger numbers typically indicate buggy software.
"unrecognizedcalls": 6
}
}
```
#### /host [POST]
configures hosting parameters. All parameters are optional; unspecified
parameters will be left unchanged.
###### Query String Parameters
```
// When set to true, the host will accept new file contracts if the
// terms are reasonable. When set to false, the host will not accept new
// file contracts at all.
acceptingcontracts // Optional, true / false
// The maximum size of a single download request from a renter. Each
// download request has multiple round trips of communication that
// exchange money. Larger batch sizes mean fewer round trips, but more
// financial risk for the host - the renter can get a free batch when
// downloading by refusing to provide a signature.
maxdownloadbatchsize // Optional, bytes
// The maximum duration of a file contract that the host will accept.
// The storage proof window must end before the current height +
// maxduration.
maxduration // Optional, blocks
// The maximum size of a single batch of file contract revisions. The
// renter can perform DoS attacks on the host by uploading a batch of
// data then refusing to provide a signature to pay for the data. The
// host can reduce this exposure by limiting the batch size. Larger
// batch sizes allow for higher throughput as there is significant
// communication overhead associated with performing a batch upload.
maxrevisebatchsize // Optional, bytes
// The IP address or hostname (including port) that the host should be
// contacted at. If left blank, the host will automatically figure out
// its ip address and use that. If given, the host will use the address
// given.
netaddress // Optional
// The storage proof window is the number of blocks that the host has
// to get a storage proof onto the blockchain. The window size is the
// minimum size of window that the host will accept in a file contract.
windowsize // Optional, blocks
// The maximum amount of money that the host will put up as collateral
// per byte per block of storage that is contracted by the renter.
collateral // Optional, hastings / byte / block
// The total amount of money that the host will allocate to collateral
// across all file contracts.
collateralbudget // Optional, hastings
// The maximum amount of collateral that the host will put into a
// single file contract.
maxcollateral // Optional, hastings
// The minimum price that the host will demand from a renter when
// forming a contract. Typically this price is to cover transaction
// fees on the file contract revision and storage proof, but can also
// be used if the host has a low amount of collateral. The price is a
// minimum because the host may automatically adjust the price upwards
// in times of high demand.
mincontractprice // Optional, hastings
// The minimum price that the host will demand from a renter when the
// renter is downloading data. If the host is saturated, the host may
// increase the price from the minimum.
mindownloadbandwidthprice // Optional, hastings / byte
// The minimum price that the host will demand when storing data for
// extended periods of time. If the host is low on space, the price of
// storage may be set higher than the minimum.
minstorageprice // Optional, hastings / byte / block
// The minimum price that the host will demand from a renter when the
// renter is uploading data. If the host is saturated, the host may
// increase the price from the minimum.
minuploadbandwidthprice // Optional, hastings / byte
```
###### Response
standard success or error response. See
[#standard-responses](#standard-responses).
#### /host/announce [POST]
Announce the host to the network as a source of storage. Generally only needs
to be called once.
###### Query String Parameters
```
// The address to be announced. If no address is provided, the automatically
// discovered address will be used instead.
netaddress string // Optional
```
###### Response
standard success or error response. See
[#standard-responses](#standard-responses).
#### /host/storage [GET]
gets a list of folders tracked by the host's storage manager.
###### JSON Response
```javascript
{
"folders": [
{
// Absolute path to the storage folder on the local filesystem.
"path": "/home/foo/bar",
// Maximum capacity of the storage folder. The host will not store more
// than this many bytes in the folder. This capacity is not checked
// against the drive's remaining capacity. Therefore, you must manually
// ensure the disk has sufficient capacity for the folder at all times.
// Otherwise you risk losing renter's data and failing storage proofs.
"capacity": 50000000000, // bytes
// Unused capacity of the storage folder.
"capacityremaining": 100000, // bytes
// Number of failed disk read & write operations. A large number of
// failed reads or writes indicates a problem with the filesystem or
// drive's hardware.
"failedreads": 0,
"failedwrites": 1,
// Number of successful read & write operations.
"successfulreads": 2,
"successfulwrites": 3
}
]
}
```
#### /host/storage/folders/add [POST]
adds a storage folder to the manager. The manager may not check that there is
enough space available on-disk to support as much storage as requested
###### Query String Parameters
```
// Local path on disk to the storage folder to add.
path // Required
// Initial capacity of the storage folder. This value isn't validated so it is
// possible to set the capacity of the storage folder greater than the capacity
// of the disk. Do not do this.
size // bytes, Required
```
###### Response
standard success or error response. See
[#standard-responses](#standard-responses).
#### /host/storage/folders/remove [POST]
remove a storage folder from the manager. All storage on the folder will be
moved to other storage folders, meaning that no data will be lost. If the
manager is unable to save data, an error will be returned and the operation
will be stopped.
###### Query String Parameters
```
// Local path on disk to the storage folder to remove.
path // Required
// If `force` is true, the storage folder will be removed even if the data in
// the storage folder cannot be moved to other storage folders, typically
// because they don't have sufficient capacity. If `force` is true and the data
// cannot be moved, data will be lost.
force // bool, Optional, default is false
```
###### Response
standard success or error response. See
[#standard-responses](#standard-responses).
#### /host/storage/folders/resize [POST]
grows or shrink a storage folder in the manager. The manager may not check that
there is enough space on-disk to support growing the storage folder, but should
gracefully handle running out of space unexpectedly. When shrinking a storage
folder, any data in the folder that needs to be moved will be placed into other
storage folders, meaning that no data will be lost. If the manager is unable to
migrate the data, an error will be returned and the operation will be stopped.
###### Query String Parameters
```
// Local path on disk to the storage folder to resize.
path // Required
// Desired new size of the storage folder. This will be the new capacity of the
// storage folder.
newsize // bytes, Required
```
###### Response
standard success or error response. See
[#standard-responses](#standard-responses).
#### /host/storage/sectors/delete/___*merkleroot___ [POST]
deletes a sector, meaning that the manager will be unable to upload that sector
and be unable to provide a storage proof on that sector. This endpoint is for
removing the data entirely, and will remove instances of the sector appearing
at all heights. The primary purpose is to comply with legal requests to remove
data.
###### Path Parameters
```
// Merkleroot of the sector to delete.
:merkleroot
```
###### Response
standard success or error response. See
[#standard-responses](#standard-responses).

464
3rd_party/Sia-v1.1.1-windows-amd64/doc/api/HostDB.md vendored
View File

@@ -1,464 +0,0 @@
Host DB API
===========
This document contains detailed descriptions of the hostdb's API routes. For an
overview of the hostdb's API routes, see [API.md#host-db](/doc/API.md#host-db).
For an overview of all API routes, see [API.md](/doc/API.md)
There may be functional API calls which are not documented. These are not
guaranteed to be supported beyond the current release, and should not be used
in production.
Overview
--------
The hostdb maintains a database of all hosts known to the network. The database
identifies hosts by their public key and keeps track of metrics such as price.
Index
-----
| Request | HTTP Verb | Examples |
| ------------------------------------------------------- | --------- | ----------------------------- |
| [/hostdb/active](#hostdbactive-get-example) | GET | [Active hosts](#active-hosts) |
| [/hostdb/all](#hostdball-get-example) | GET | [All hosts](#all-hosts) |
| [/hostdb/hosts/___:pubkey___](#hostdbhosts-get-example) | GET | [Hosts](#hosts) |
#### /hostdb/active [GET] [(example)](#active-hosts)
lists all of the active hosts known to the renter, sorted by preference.
###### Query String Parameters
```
// Number of hosts to return. The actual number of hosts returned may be less
// if there are insufficient active hosts. Optional, the default is all active
// hosts.
numhosts
```
###### JSON Response
```javascript
{
"hosts": [
{
// true if the host is accepting new contracts.
"acceptingcontracts": true,
// Maximum number of bytes that the host will allow to be requested by a
// single download request.
"maxdownloadbatchsize": 17825792,
// Maximum duration in blocks that a host will allow for a file contract.
// The host commits to keeping files for the full duration under the
// threat of facing a large penalty for losing or dropping data before
// the duration is complete. The storage proof window of an incoming file
// contract must end before the current height + maxduration.
//
// There is a block approximately every 10 minutes.
// e.g. 1 day = 144 blocks
"maxduration": 25920,
// Maximum size in bytes of a single batch of file contract
// revisions. Larger batch sizes allow for higher throughput as there is
// significant communication overhead associated with performing a batch
// upload.
"maxrevisebatchsize": 17825792,
// Remote address of the host. It can be an IPv4, IPv6, or hostname,
// along with the port. IPv6 addresses are enclosed in square brackets.
"netaddress": "123.456.789.0:9982",
// Unused storage capacity the host claims it has, in bytes.
"remainingstorage": 35000000000,
// Smallest amount of data in bytes that can be uploaded or downloaded to
// or from the host.
"sectorsize": 4194304,
// Total amount of storage capacity the host claims it has, in bytes.
"totalstorage": 35000000000,
// Address at which the host can be paid when forming file contracts.
"unlockhash": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789ab",
// A storage proof window is the number of blocks that the host has to
// get a storage proof onto the blockchain. The window size is the
// minimum size of window that the host will accept in a file contract.
"windowsize": 144,
// Public key used to identify and verify hosts.
"publickey": {
// Algorithm used for signing and verification. Typically "ed25519".
"algorithm": "ed25519",
// Key used to verify signed host messages.
"key": "RW50cm9weSBpc24ndCB3aGF0IGl0IHVzZWQgdG8gYmU="
}
}
]
}
```
#### /hostdb/all [GET] [(example)](#all-hosts)
lists all of the hosts known to the renter. Hosts are not guaranteed to be in
any particular order, and the order may change in subsequent calls.
###### JSON Response
```javascript
{
"hosts": [
{
// true if the host is accepting new contracts.
"acceptingcontracts": true,
// Maximum number of bytes that the host will allow to be requested by a
// single download request.
"maxdownloadbatchsize": 17825792,
// Maximum duration in blocks that a host will allow for a file contract.
// The host commits to keeping files for the full duration under the
// threat of facing a large penalty for losing or dropping data before
// the duration is complete. The storage proof window of an incoming file
// contract must end before the current height + maxduration.
//
// There is a block approximately every 10 minutes.
// e.g. 1 day = 144 blocks
"maxduration": 25920,
// Maximum size in bytes of a single batch of file contract
// revisions. Larger batch sizes allow for higher throughput as there is
// significant communication overhead associated with performing a batch
// upload.
"maxrevisebatchsize": 17825792,
// Remote address of the host. It can be an IPv4, IPv6, or hostname,
// along with the port. IPv6 addresses are enclosed in square brackets.
"netaddress": "123.456.789.0:9982",
// Unused storage capacity the host claims it has, in bytes.
"remainingstorage": 35000000000,
// Smallest amount of data in bytes that can be uploaded or downloaded to
// or from the host.
"sectorsize": 4194304,
// Total amount of storage capacity the host claims it has, in bytes.
"totalstorage": 35000000000,
// Address at which the host can be paid when forming file contracts.
"unlockhash": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789ab",
// A storage proof window is the number of blocks that the host has to
// get a storage proof onto the blockchain. The window size is the
// minimum size of window that the host will accept in a file contract.
"windowsize": 144,
// Public key used to identify and verify hosts.
"publickey": {
// Algorithm used for signing and verification. Typically "ed25519".
"algorithm": "ed25519",
// Key used to verify signed host messages.
"key": "RW50cm9weSBpc24ndCB3aGF0IGl0IHVzZWQgdG8gYmU="
}
}
]
}
```
#### /hostdb/hosts/___:pubkey___ [GET] [(example)](#hosts)
fetches detailed information about a particular host, including metrics
regarding the score of the host within the database. It should be noted that
each renter uses different metrics for selecting hosts, and that a good score on
in one hostdb does not mean that the host will be successful on the network
overall.
###### Path Parameters
```
// The public key of the host. Each public key identifies a single host.
//
// Example Pubkey: ed25519:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
:pubkey
```
###### JSON Response
```javascript
{
"entry": {
// true if the host is accepting new contracts.
"acceptingcontracts": true,
// Maximum number of bytes that the host will allow to be requested by a
// single download request.
"maxdownloadbatchsize": 17825792,
// Maximum duration in blocks that a host will allow for a file contract.
// The host commits to keeping files for the full duration under the
// threat of facing a large penalty for losing or dropping data before
// the duration is complete. The storage proof window of an incoming file
// contract must end before the current height + maxduration.
//
// There is a block approximately every 10 minutes.
// e.g. 1 day = 144 blocks
"maxduration": 25920,
// Maximum size in bytes of a single batch of file contract
// revisions. Larger batch sizes allow for higher throughput as there is
// significant communication overhead associated with performing a batch
// upload.
"maxrevisebatchsize": 17825792,
// Remote address of the host. It can be an IPv4, IPv6, or hostname,
// along with the port. IPv6 addresses are enclosed in square brackets.
"netaddress": "123.456.789.0:9982",
// Unused storage capacity the host claims it has, in bytes.
"remainingstorage": 35000000000,
// Smallest amount of data in bytes that can be uploaded or downloaded to
// or from the host.
"sectorsize": 4194304,
// Total amount of storage capacity the host claims it has, in bytes.
"totalstorage": 35000000000,
// Address at which the host can be paid when forming file contracts.
"unlockhash": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789ab",
// A storage proof window is the number of blocks that the host has to
// get a storage proof onto the blockchain. The window size is the
// minimum size of window that the host will accept in a file contract.
"windowsize": 144,
// Public key used to identify and verify hosts.
"publickey": {
// Algorithm used for signing and verification. Typically "ed25519".
"algorithm": "ed25519",
// Key used to verify signed host messages.
"key": "RW50cm9weSBpc24ndCB3aGF0IGl0IHVzZWQgdG8gYmU="
},
// The string representation of the full public key, used when calling
// /hostdb/hosts.
"publickeystring": "ed25519:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef"
},
// A set of scores as determined by the renter. Generally, the host's final
// final score is all of the values multiplied together. Modified renters may
// have additional criteria that they use to judge a host, or may ignore
// certin criteia. In general, these fields should only be used as a loose
// guide for the score of a host, as every renter sees the world differently
// and uses different metrics to evaluate hosts.
"scorebreakdown": {
// The multiplier that gets applied to the host based on how long it has
// been a host. Older hosts typically have a lower penalty.
"ageadjustment": 0.1234,
// The multiplier that gets applied to the host based on how much
// proof-of-burn the host has performed. More burn causes a linear increase
// in score.
"burnadjustment": 23.456,
// The multiplier that gets applied to a host based on how much collateral
// the host is offering. More collateral is typically better, though above
// a point it can be detrimental.
"collateraladjustment": 23.456,
// The multiplier that gets applied to a host based on the host's price.
// Lower prices are almost always better. Below a certain, very low price,
// there is no advantage.
"priceadjustment": 0.1234,
// The multiplier that gets applied to a host based on how much storage is
// remaining for the host. More storage remaining is better, to a point.
"storageremainingadjustment": 0.1234,
// The multiplier that gets applied to a host based on the uptime percentage
// of the host. The penalty increases extremely quickly as uptime drops
// below 90%.
"uptimeadjustment": 0.1234,
// The multiplier that gets applied to a host based on the version of Sia
// that they are running. Versions get penalties if there are known bugs,
// scaling limitations, performance limitations, etc. Generally, the most
// recent version is always the one with the highest score.
"versionadjustment": 0.1234
}
}
```
Examples
--------
#### Active hosts
###### Request
```
/hostdb/active?numhosts=2
```
###### Expected Response Code
```
200 OK
```
###### Example JSON Response
```javascript
{
"hosts": [
{
"acceptingcontracts": true,
"maxdownloadbatchsize": 17825792,
"maxduration": 25920,
"maxrevisebatchsize": 17825792,
"netaddress": "123.456.789.0:9982",
"remainingstorage": 35000000000,
"sectorsize": 4194304,
"totalstorage": 35000000000,
"unlockhash": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789ab",
"windowsize": 144,
"publickey": {
"algorithm": "ed25519",
"key": "RW50cm9weSBpc24ndCB3aGF0IGl0IHVzZWQgdG8gYmU="
}
"publickeystring": "ed25519:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
},
{
"acceptingcontracts": true,
"maxdownloadbatchsize": 17825792,
"maxduration": 25920,
"maxrevisebatchsize": 17825792,
"netaddress": "123.456.789.1:9982",
"remainingstorage": 314,
"sectorsize": 4194304,
"totalstorage": 314159265359,
"unlockhash": "ba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210",
"windowsize": 144,
"publickey": {
"algorithm": "ed25519",
"key": "WWVzIEJydWNlIFNjaG5laWVyIGNhbiByZWFkIHRoaXM="
}
"publickeystring": "ed25519:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
}
]
}
```
#### All hosts
###### Request
```
/hostdb/all
```
###### Expected Response Code
```
200 OK
```
###### Example JSON Response
```javascript
{
"hosts": [
{
"acceptingcontracts": false,
"maxdownloadbatchsize": 17825792,
"maxduration": 25920,
"maxrevisebatchsize": 17825792,
"netaddress": "123.456.789.2:9982",
"remainingstorage": 314,
"sectorsize": 4194304,
"totalstorage": 314159265359,
"unlockhash": "abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789",
"windowsize": 144,
"publickey": {
"algorithm": "ed25519",
"key": "SSByYW4gb3V0IG9mIDMyIGNoYXIgbG9uZyBqb2tlcy4="
}
"publickeystring": "ed25519:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
},
{
"acceptingcontracts": true,
"maxdownloadbatchsize": 17825792,
"maxduration": 25920,
"maxrevisebatchsize": 17825792,
"netaddress": "123.456.789.0:9982",
"remainingstorage": 35000000000,
"sectorsize": 4194304,
"totalstorage": 35000000000,
"unlockhash": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789ab",
"windowsize": 144,
"publickey": {
"algorithm": "ed25519",
"key": "RW50cm9weSBpc24ndCB3aGF0IGl0IHVzZWQgdG8gYmU="
}
"publickeystring": "ed25519:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
},
{
"acceptingcontracts": true,
"maxdownloadbatchsize": 17825792,
"maxduration": 25920,
"maxrevisebatchsize": 17825792,
"netaddress": "123.456.789.1:9982",
"remainingstorage": 314,
"sectorsize": 4194304,
"totalstorage": 314159265359,
"unlockhash": "ba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210",
"windowsize": 144,
"publickey": {
"algorithm": "ed25519",
"key": "WWVzIEJydWNlIFNjaG5laWVyIGNhbiByZWFkIHRoaXM="
}
"publickeystring": "ed25519:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
}
]
}
```
#### Hosts
###### Request
```
/hostdb/hosts/ed25519:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
```
###### Expected Response Code
```
200 OK
```
###### Example JSON Response
```javascript
{
"entry": {
"acceptingcontracts": false,
"maxdownloadbatchsize": 17825792,
"maxduration": 25920,
"maxrevisebatchsize": 17825792,
"netaddress": "123.456.789.2:9982",
"remainingstorage": 314,
"sectorsize": 4194304,
"totalstorage": 314159265359,
"unlockhash": "abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789",
"windowsize": 144,
"publickey": {
"algorithm": "ed25519",
"key": "SSByYW4gb3V0IG9mIDMyIGNoYXIgbG9uZyBqb2tlcy4="
}
"publickeystring": "ed25519:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
},
"scorebreakdown": {
"ageadjustment": 0.1234,
"burnadjustment": 0.1234,
"collateraladjustment": 23.456,
"priceadjustment": 0.1234,
"storageremainingadjustment": 0.1234,
"uptimeadjustment": 0.1234,
"versionadjustment": 0.1234,
}
}
```

124
3rd_party/Sia-v1.1.1-windows-amd64/doc/api/Miner.md vendored
View File

@@ -1,124 +0,0 @@
Miner API
=========
This document contains detailed descriptions of the miner's API routes. For an
overview of the miner's API routes, see [API.md#miner](/doc/API.md#miner). For
an overview of all API routes, see [API.md](/doc/API.md)
There may be functional API calls which are not documented. These are not
guaranteed to be supported beyond the current release, and should not be used
in production.
Overview
--------
The miner provides endpoints for getting headers for work and submitting solved
headers to the network. The miner also provides endpoints for controlling a
basic CPU mining implementation.
Index
-----
| Route | HTTP verb |
| ---------------------------------- | --------- |
| [/miner](#miner-get) | GET |
| [/miner/start](#minerstart-get) | GET |
| [/miner/stop](#minerstop-get) | GET |
| [/miner/header](#minerheader-get) | GET |
| [/miner/header](#minerheader-post) | POST |
#### /miner [GET]
returns the status of the miner.
###### JSON Response
```javascript
{
// Number of mined blocks. This value is remembered after restarting.
"blocksmined": 9001,
// How fast the cpu is hashing, in hashes per second.
"cpuhashrate": 1337,
// true if the cpu miner is active.
"cpumining": false,
// Number of mined blocks that are stale, indicating that they are not
// included in the current longest chain, likely because some other block at
// the same height had its chain extended first.
"staleblocksmined": 0,
}
```
#### /miner/start [GET]
starts a single threaded cpu miner. Does nothing if the cpu miner is already
running.
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).
#### /miner/stop [GET]
stops the cpu miner. Does nothing if the cpu miner is not running.
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).
#### /miner/header [GET]
provides a block header that is ready to be grinded on for work.
###### Byte Response
For efficiency the header for work is returned as a raw byte encoding of the
header, rather than encoded to JSON.
Blocks are mined by repeatedly changing the nonce of the header, hashing the
header's bytes, and comparing the resulting hash to the target. The block with
that nonce is valid if the hash is less than the target. If none of the 2^64
possible nonces result in a header with a hash less than the target, call
`/miner/header [GET]` again to get a new block header with a different merkle
root. The above process can then be repeated for the new block header.
The other fields can generally be ignored. The parent block ID field is the
hash of the parent block's header. Modifying this field will result in an
orphan block. The timestamp is the time at which the block was mined and is set
by the Sia Daemon. Modifying this field can result in invalid block. The merkle
root is the merkle root of a merkle tree consisting of the timestamp, the miner
outputs (one leaf per payout), and the transactions (one leaf per transaction).
Modifying this field will result in an invalid block.
| Field | Byte range within response | Byte range within header |
| --------------- | -------------------------- | ------------------------ |
| target | [0-32) | |
| header | [32-112) | |
| parent block ID | [32-64) | [0-32) |
| nonce | [64-72) | [32-40) |
| timestamp | [72-80) | [40-48) |
| merkle root | [80-112) | [48-80) |
```
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (returned bytes)
tttttttttttttttttttttttttttttttt (target)
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh (header)
pppppppppppppppppppppppppppppppp (parent block ID)
nnnnnnnn (nonce)
ssssssss (timestamp)
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm (merkle root)
```
#### /miner/header [POST]
submits a header that has passed the POW.
###### Request Body Bytes
For efficiency headers are submitted as raw byte encodings of the header in the
body of the request, rather than as a query string parameter or path parameter.
The request body should contain only the 80 bytes of the encoded header. The
encoding is the same encoding used in `/miner/header [GET]` endpoint. Refer to
[#byte-response](#byte-response) for a detailed description of the byte
encoding.

327
3rd_party/Sia-v1.1.1-windows-amd64/doc/api/Renter.md vendored
View File

@@ -1,327 +0,0 @@
Renter API
==========
This document contains detailed descriptions of the renter's API routes. For an
overview of the renter's API routes, see [API.md#renter](/doc/API.md#renter). For
an overview of all API routes, see [API.md](/doc/API.md)
There may be functional API calls which are not documented. These are not
guaranteed to be supported beyond the current release, and should not be used
in production.
Overview
--------
The renter manages the user's files on the network. The renter's API endpoints
expose methods for managing files on the network and managing the renter's
allocated funds.
Index
-----
| Route | HTTP verb |
| ------------------------------------------------------------- | --------- |
| [/renter](#renter-get) | GET |
| [/renter](#renter-post) | POST |
| [/renter/contracts](#rentercontracts-get) | GET |
| [/renter/downloads](#renterdownloads-get) | GET |
| [/renter/files](#renterfiles-get) | GET |
| [/renter/prices](#renter-prices-get) | GET |
| [/renter/delete/___*siapath___](#renterdeletesiapath-post) | POST |
| [/renter/download/___*siapath___](#renterdownloadsiapath-get) | GET |
| [/renter/rename/___*siapath___](#renterrenamesiapath-post) | POST |
| [/renter/upload/___*siapath___](#renteruploadsiapath-post) | POST |
#### /renter [GET]
returns the current settings along with metrics on the renter's spending.
###### JSON Response
```javascript
{
// Settings that control the behavior of the renter.
"settings": {
// Allowance dictates how much the renter is allowed to spend in a given
// period. Note that funds are spent on both storage and bandwidth.
"allowance": {
// Amount of money allocated for contracts. Funds are spent on both
// storage and bandwidth.
"funds": "1234", // hastings
// Number of hosts that contracts will be formed with.
"hosts":24,
// Duration of contracts formed, in number of blocks.
"period": 6048, // blocks
// If the current blockheight + the renew window >= the height the
// contract is scheduled to end, the contract is renewed automatically.
// Is always nonzero.
"renewwindow": 3024 // blocks
}
},
// Metrics about how much the Renter has spent on storage, uploads, and
// downloads.
"financialmetrics": {
// How much money, in hastings, the Renter has spent on file contracts,
// including fees.
"contractspending": "1234", // hastings
// Amount of money spent on downloads.
"downloadspending": "5678", // hastings
// Amount of money spend on storage.
"storagespending": "1234", // hastings
// Amount of money spent on uploads.
"uploadspending": "5678", // hastings
// Amount of money in the allowance that has not been spent.
"unspent": "1234" // hastings
}
}
```
#### /renter [POST]
modify settings that control the renter's behavior.
###### Query String Parameters
```
// Number of hastings allocated for file contracts in the given period.
funds // hastings
// Number of hosts that contracts should be formed with. Files cannot be
// uploaded to more hosts than you have contracts with, and it's generally good
// to form a few more contracts than you need.
hosts
// Duration of contracts formed. Must be nonzero.
period // block height
// Renew window specifies how many blocks before the expriation of the current
// contracts the renter will wait before renewing the contracts. A smaller
// renew window means that Sia must be run more frequently, but also means
// fewer total transaction fees. Storage spending is not affected by the renew
// window size.
renewwindow // block height
```
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).
#### /renter/contracts [GET]
returns active contracts. Expired contracts are not included.
###### JSON Response
```javascript
{
"contracts": [
{
// Block height that the file contract ends on.
"endheight": 50000, // block height
// ID of the file contract.
"id": "1234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
// Address of the host the file contract was formed with.
"netaddress": "12.34.56.78:9",
// A signed transaction containing the most recent contract revision.
"lasttransaction": {},
// Remaining funds left for the renter to spend on uploads & downloads.
"renterfunds": "1234", // hastings
// Size of the file contract, which is typically equal to the number of
// bytes that have been uploaded to the host.
"size": 8192 // bytes
}
]
}
```
#### /renter/downloads [GET]
lists all files in the download queue.
###### JSON Response
```javascript
{
"downloads": [
{
// Siapath given to the file when it was uploaded.
"siapath": "foo/bar.txt",
// Local path that the file will be downloaded to.
"destination": "/home/users/alice",
// Size, in bytes, of the file being downloaded.
"filesize": 8192, // bytes
// Number of bytes downloaded thus far.
"received": 4096, // bytes
// Time at which the download was initiated.
"starttime": "2009-11-10T23:00:00Z" // RFC 3339 time
}
]
}
```
#### /renter/files [GET]
lists the status of all files.
###### JSON Response
```javascript
{
"files": [
{
// Path to the file in the renter on the network.
"siapath": "foo/bar.txt",
// Size of the file in bytes.
"filesize": 8192, // bytes
// true if the file is available for download. Files may be available
// before they are completely uploaded.
"available": true,
// true if the file's contracts will be automatically renewed by the
// renter.
"renewing": true,
// Average redundancy of the file on the network. Redundancy is
// calculated by dividing the amount of data uploaded in the file's open
// contracts by the size of the file. Redundancy does not necessarily
// correspond to availability. Specifically, a redundancy >= 1 does not
// indicate the file is available as there could be a chunk of the file
// with 0 redundancy.
"redundancy": 5,
// Percentage of the file uploaded, including redundancy. Uploading has
// completed when uploadprogress is 100. Files may be available for
// download before upload progress is 100.
"uploadprogress": 100, // percent
// Block height at which the file ceases availability.
"expiration": 60000
}
]
}
```
#### /renter/prices [GET]
lists the estimated prices of performing various storage and data operations.
###### JSON Response
```javascript
{
// The estimated cost of downloading one terabyte of data from the
// network.
"downloadterabyte": "1234", // hastings
// The estimated cost of forming a set of contracts on the network. This
// cost also applies to the estimated cost of renewing the renter's set of
// contracts.
"formcontracts": "1234", // hastings
// The estimated cost of storing one terabyte of data on the network for
// a month, including accounting for redundancy.
"storageterabytemonth": "1234", // hastings
// The estimated cost of uploading one terabyte of data to the network,
// including accounting for redundancy.
"uploadterabyte": "1234", // hastings
}
```
#### /renter/delete/___*siapath___ [POST]
deletes a renter file entry. Does not delete any downloads or original files,
only the entry in the renter.
###### Path Parameters
```
// Location of the file in the renter on the network.
*siapath
```
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).
#### /renter/download/___*siapath___ [GET]
downloads a file to the local filesystem. The call will block until the file
has been downloaded.
###### Path Parameters
```
// Location of the file in the renter on the network.
*siapath
```
###### Query String Parameters
```
// Location on disk that the file will be downloaded to.
destination
```
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).
#### /renter/rename/___*siapath___ [POST]
renames a file. Does not rename any downloads or source files, only renames the
entry in the renter. An error is returned if `siapath` does not exist or
`newsiapath` already exists.
###### Path Parameters
```
// Current location of the file in the renter on the network.
*siapath
```
###### Query String Parameters
```
// New location of the file in the renter on the network.
newsiapath
```
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).
#### /renter/upload/___*siapath___ [POST]
uploads a file to the network from the local filesystem.
###### Path Parameters
```
// Location where the file will reside in the renter on the network.
*siapath
```
###### Query String Parameters
```
// The number of data pieces to use when erasure coding the file.
datapieces // int
// The number of parity pieces to use when erasure coding the file. Total
// redundancy of the file is (datapieces+paritypieces)/datapieces.
paritypieces // int
// Location on disk of the file being uploaded.
source // string - a filepath
```
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).

521
3rd_party/Sia-v1.1.1-windows-amd64/doc/api/Wallet.md vendored
View File

@@ -1,521 +0,0 @@
Wallet
======
This document contains detailed descriptions of the wallet's API routes. For an
overview of the wallet's API routes, see [API.md#wallet](/doc/API.md#wallet).
For an overview of all API routes, see [API.md](/doc/API.md)
There may be functional API calls which are not documented. These are not
guaranteed to be supported beyond the current release, and should not be used
in production.
Overview
--------
The wallet stores and manages siacoins and siafunds. The wallet's API endpoints
expose methods for creating and loading wallets, locking and unlocking, sending
siacoins and siafunds, and getting the wallet's balance.
You must create a wallet before you can use the wallet's API endpoints. You can
create a wallet with the `/wallet/init` endpoint. Wallets are always encrypted
on disk. Calls to some wallet API endpoints will fail until the wallet is
unlocked. The wallet can be unlocked with the `/wallet/unlock` endpoint. Once
the wallet is unlocked calls to the API endpoints will succeed until the wallet
is locked again with `/wallet/lock`, or Siad is restarted. The host and renter
require the miner to be unlocked.
Index
-----
| Route | HTTP verb |
| --------------------------------------------------------------- | --------- |
| [/wallet](#wallet-get) | GET |
| [/wallet/033x](#wallet033x-post) | POST |
| [/wallet/address](#walletaddress-get) | GET |
| [/wallet/addresses](#walletaddresses-get) | GET |
| [/wallet/backup](#walletbackup-get) | GET |
| [/wallet/init](#walletinit-post) | POST |
| [/wallet/lock](#walletlock-post) | POST |
| [/wallet/seed](#walletseed-post) | POST |
| [/wallet/seeds](#walletseeds-get) | GET |
| [/wallet/siacoins](#walletsiacoins-post) | POST |
| [/wallet/siafunds](#walletsiafunds-post) | POST |
| [/wallet/siagkey](#walletsiagkey-post) | POST |
| [/wallet/transaction/___:id___](#wallettransactionid-get) | GET |
| [/wallet/transactions](#wallettransactions-get) | GET |
| [/wallet/transactions/___:addr___](#wallettransactionsaddr-get) | GET |
| [/wallet/unlock](#walletunlock-post) | POST |
#### /wallet [GET]
returns basic information about the wallet, such as whether the wallet is
locked or unlocked.
###### JSON Response
```javascript
{
// Indicates whether the wallet has been encrypted or not. If the wallet
// has not been encrypted, then no data has been generated at all, and the
// first time the wallet is unlocked, the password given will be used as
// the password for encrypting all of the data. 'encrypted' will only be
// set to false if the wallet has never been unlocked before (the unlocked
// wallet is still encryped - but the encryption key is in memory).
"encrypted": true,
// Indicates whether the wallet is currently locked or unlocked. Some calls
// become unavailable when the wallet is locked.
"unlocked": true,
// Number of siacoins, in hastings, available to the wallet as of the most
// recent block in the blockchain.
"confirmedsiacoinbalance": "123456", // hastings, big int
// Number of siacoins, in hastings, that are leaving the wallet according
// to the set of unconfirmed transactions. Often this number appears
// inflated, because outputs are frequently larger than the number of coins
// being sent, and there is a refund. These coins are counted as outgoing,
// and the refund is counted as incoming. The difference in balance can be
// calculated using 'unconfirmedincomingsiacoins' - 'unconfirmedoutgoingsiacoins'
"unconfirmedoutgoingsiacoins": "0", // hastings, big int
// Number of siacoins, in hastings, are entering the wallet according to
// the set of unconfirmed transactions. This number is often inflated by
// outgoing siacoins, because outputs are frequently larger than the amount
// being sent. The refund will be included in the unconfirmed incoming
// siacoins balance.
"unconfirmedincomingsiacoins": "789", // hastings, big int
// Number of siafunds available to the wallet as of the most recent block
// in the blockchain.
"siafundbalance": "1", // big int
// Number of siacoins, in hastings, that can be claimed from the siafunds
// as of the most recent block. Because the claim balance increases every
// time a file contract is created, it is possible that the balance will
// increase before any claim transaction is confirmed.
"siacoinclaimbalance": "9001", // hastings, big int
}
```
#### /wallet/033x [POST]
loads a v0.3.3.x wallet into the current wallet, harvesting all of the secret
keys. All spendable addresses in the loaded wallet will become spendable from
the current wallet. An error will be returned if the given `encryptionpassword`
is incorrect.
###### Query String Parameters
```
// Path on disk to the v0.3.3.x wallet to be loaded.
source
// Encryption key of the wallet.
encryptionpassword
```
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).
#### /wallet/address [GET]
gets a new address from the wallet generated by the primary seed. An error will
be returned if the wallet is locked.
###### JSON Response
```javascript
{
// Wallet address that can receive siacoins or siafunds. Addresses are 76 character long hex strings.
"address": "1234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789ab"
}
```
#### /wallet/addresses [GET]
fetches the list of addresses from the wallet.
###### JSON Response
```javascript
{
// Array of wallet addresses owned by the wallet.
"addresses": [
"1234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789ab",
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
]
}
```
#### /wallet/backup [GET]
creates a backup of the wallet settings file. Though this can easily be done
manually, the settings file is often in an unknown or difficult to find
location. The /wallet/backup call can spare users the trouble of needing to
find their wallet file. The destination file is overwritten if it already
exists.
###### Query String Parameters
```
// path to the location on disk where the backup file will be saved.
destination
```
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).
#### /wallet/init [POST]
initializes the wallet. After the wallet has been initialized once, it does not
need to be initialized again, and future calls to /wallet/init will return an
error. The encryption password is provided by the api call. If the password is
blank, then the password will be set to the same as the seed.
###### Query String Parameters
```
// Password that will be used to encrypt the wallet. All subsequent calls
// should use this password. If left blank, the seed that gets returned will
// also be the encryption password.
encryptionpassword
// Name of the dictionary that should be used when encoding the seed. 'english'
// is the most common choice when picking a dictionary.
dictionary // Optional, default is english.
```
###### JSON Response
```javascript
{
// Wallet seed used to generate addresses that the wallet is able to spend.
"primaryseed": "hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello"
}
```
#### /wallet/seed [POST]
gives the wallet a seed to track when looking for incoming transactions. The
wallet will be able to spend outputs related to addresses created by the seed.
The seed is added as an auxiliary seed, and does not replace the primary seed.
Only the primary seed will be used for generating new addresses.
###### Query String Parameters
```
// Key used to encrypt the new seed when it is saved to disk.
encryptionpassword
// Name of the dictionary that should be used when encoding the seed. 'english'
// is the most common choice when picking a dictionary.
dictionary
// Dictionary-encoded phrase that corresponds to the seed being added to the
// wallet.
seed
```
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).
#### /wallet/seeds [GET]
returns a list of seeds in use by the wallet. The primary seed is the only seed
that gets used to generate new addresses. This call is unavailable when the
wallet is locked.
A seed is an encoded version of a 128 bit random seed. The output is 15 words
chosen from a small dictionary as indicated by the input. The most common
choice for the dictionary is going to be 'english'. The underlying seed is the
same no matter what dictionary is used for the encoding. The encoding also
contains a small checksum of the seed, to help catch simple mistakes when
copying. The library
[entropy-mnemonics](https://github.com/NebulousLabs/entropy-mnemonics) is used
when encoding.
###### Query String Parameters
```
// Name of the dictionary that should be used when encoding the seed. 'english'
// is the most common choice when picking a dictionary.
dictionary
```
###### JSON Response
```javascript
{
// Seed that is actively being used to generate new addresses for the wallet.
"primaryseed": "hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello",
// Number of addresses that remain in the primary seed until exhaustion has
// been reached. Once exhaustion has been reached, new addresses will
// continue to be generated but they will be more difficult to recover in the
// event of a lost wallet file or encryption password.
"addressesremaining": 2500,
// Array of all seeds that the wallet references when scanning the blockchain
// for outputs. The wallet is able to spend any output generated by any of
// the seeds, however only the primary seed is being used to generate new
// addresses.
"allseeds": [
"hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello world hello",
"foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo",
]
}
```
#### /wallet/siacoins [POST]
Function: Send siacoins to an address. The outputs are arbitrarily selected
from addresses in the wallet.
###### Query String Parameters
```
// Number of hastings being sent. A hasting is the smallest unit in Sia. There
// are 10^24 hastings in a siacoin.
amount // hastings
// Address that is receiving the coins.
destination // address
```
###### JSON Response
```javascript
{
// Array of IDs of the transactions that were created when sending the coins.
// The last transaction contains the output headed to the 'destination'.
// Transaction IDs are 64 character long hex strings.
transactionids [
"1234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
]
}
```
#### /wallet/siafunds [POST]
sends siafunds to an address. The outputs are arbitrarily selected from
addresses in the wallet. Any siacoins available in the siafunds being sent (as
well as the siacoins available in any siafunds that end up in a refund address)
will become available to the wallet as siacoins after 144 confirmations. To
access all of the siacoins in the siacoin claim balance, send all of the
siafunds to an address in your control (this will give you all the siacoins,
while still letting you control the siafunds).
###### Query String Parameters
```
// Number of siafunds being sent.
amount // siafunds
// Address that is receiving the funds.
destination // address
```
###### JSON Response
```javascript
{
// Array of IDs of the transactions that were created when sending the coins.
// The last transaction contains the output headed to the 'destination'.
// Transaction IDs are 64 character long hex strings.
"transactionids": [
"1234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
]
}
```
#### /wallet/siagkey [POST]
Function: Load a key into the wallet that was generated by siag. Most siafunds
are currently in addresses created by siag.
###### Query String Parameters
```
// Key that is used to encrypt the siag key when it is imported to the wallet.
encryptionpassword
// List of filepaths that point to the keyfiles that make up the siag key.
// There should be at least one keyfile per required signature. The filenames
// need to be commna separated (no spaces), which means filepaths that contain
// a comma are not allowed.
keyfiles
```
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).
#### /wallet/lock [POST]
locks the wallet, wiping all secret keys. After being locked, the keys are
encrypted. Queries for the seed, to send siafunds, and related queries become
unavailable. Queries concerning transaction history and balance are still
available.
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).
#### /wallet/transaction/___:id___ [GET]
gets the transaction associated with a specific transaction id.
###### Path Parameters
```
// ID of the transaction being requested.
:id
```
###### JSON Response
```javascript
{
"transaction": {
// Raw transaction. The rest of the fields in the resposne are determined
// from this raw transaction. It is left undocumented here as the processed
// transaction (the rest of the fields in this object) are usually what is
// desired.
"transaction": {
// See types.Transaction in https://github.com/NebulousLabs/Sia/blob/master/types/transactions.go
},
// ID of the transaction from which the wallet transaction was derived.
"transactionid": "1234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
// Block height at which the transaction was confirmed. If the transaction
// is unconfirmed the height will be the max value of an unsigned 64-bit
// integer.
"confirmationheight": 50000,
// Time, in unix time, at which a transaction was confirmed. If the
// transaction is unconfirmed the timestamp will be the max value of an
// unsigned 64-bit integer.
"confirmationtimestamp": 1257894000,
// Array of processed inputs detailing the inputs to the transaction.
"inputs": [
{
// Type of fund represented by the input. Possible values are
// 'siacoin input' and 'siafund input'.
"fundtype": "siacoin input",
// true if the address is owned by the wallet.
"walletaddress": false,
// Address that is affected. For inputs (outgoing money), the related
// address is usually not important because the wallet arbitrarily
// selects which addresses will fund a transaction.
"relatedaddress": "1234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789ab",
// Amount of funds that have been moved in the input.
"value": "1234", // hastings or siafunds, depending on fundtype, big int
}
],
// Array of processed outputs detailing the outputs of the transaction.
// Outputs related to file contracts are excluded.
"outputs": [
{
// Type of fund is represented by the output. Possible values are
// 'siacoin output', 'siafund output', 'claim output', and 'miner
// payout'. Siacoin outputs and claim outputs both relate to siacoins.
// Siafund outputs relate to siafunds. Miner payouts point to siacoins
// that have been spent on a miner payout. Because the destination of
// the miner payout is determined by the block and not the transaction,
// the data 'maturityheight', 'walletaddress', and 'relatedaddress' are
// left blank.
"fundtype": "siacoin output",
// Block height the output becomes available to be spent. Siacoin
// outputs and siafund outputs mature immediately - their maturity
// height will always be the confirmation height of the transaction.
// Claim outputs cannot be spent until they have had 144 confirmations,
// thus the maturity height of a claim output will always be 144 larger
// than the confirmation height of the transaction.
"maturityheight": 50000,
// true if the address is owned by the wallet.
"walletaddress": false,
// Address that is affected. For outputs (incoming money), the related
// address field can be used to determine who has sent money to the
// wallet.
"relatedaddress": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
// Amount of funds that have been moved in the output.
"value": "1234", // hastings or siafunds, depending on fundtype, big int
}
]
}
}
```
#### /wallet/transactions [GET]
returns a list of transactions related to the wallet.
###### Query String Parameters
```
// Height of the block where transaction history should begin.
startheight // block height
// Height of of the block where the transaction history should end. If
// 'endheight' is greater than the current height, all transactions up to and
// including the most recent block will be provided.
endheight // block height
```
###### JSON Response
```javascript
{
// All of the confirmed transactions appearing between height 'startheight'
// and height 'endheight' (inclusive).
"confirmedtransactions": [
{
// See the documentation for '/wallet/transaction/:id' for more information.
}
],
// All of the unconfirmed transactions.
"unconfirmedtransactions": [
{
// See the documentation for '/wallet/transaction/:id' for more information.
}
]
}
```
#### /wallet/transactions/___:addr___ [GET]
returns all of the transactions related to a specific address.
###### Path Parameters
```
// Unlock hash (i.e. wallet address) whose transactions are being requested.
:addr
```
###### JSON Response
```javascript
{
// Array of processed transactions that relate to the supplied address.
"transactions": [
{
// See the documentation for '/wallet/transaction/:id' for more information.
}
]
}
```
#### /wallet/unlock [POST]
unlocks the wallet. The wallet is capable of knowing whether the correct
password was provided.
###### Query String Parameters
```
// Password that gets used to decrypt the file. Most frequently, the encryption
// password is the same as the primary wallet seed.
encryptionpassword string
```
###### Response
standard success or error response. See
[API.md#standard-responses](/doc/API.md#standard-responses).

BIN
3rd_party/Sia-v1.1.1-windows-amd64/doc/assets/codereview.png vendored
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 39 KiB

BIN
3rd_party/Sia-v1.1.1-windows-amd64/doc/assets/covertool.png vendored
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 86 KiB

482
3rd_party/Sia-v1.1.1-windows-amd64/doc/whitepaper.tex vendored
View File

@@ -1,482 +0,0 @@
\documentclass[twocolumn]{article}
\usepackage{amsmath}
\begin{document}
\frenchspacing
\title{Sia: Simple Decentralized Storage}
\author{
{\rm David Vorick}\\
Nebulous Inc.\\
david@nebulouslabs.com
\and
{\rm Luke Champine}\\
Nebulous Inc.\\
luke@nebulouslabs.com
}
\maketitle
\subsection*{Abstract}
The authors introduce Sia, a platform for decentralized storage.
Sia enables the formation of storage contracts between peers.
Contracts are agreements between a storage provider and their client, defining what data will be stored and at what price.
They require the storage provider to prove, at regular intervals, that they are still storing their client's data.
Contracts are stored in a blockchain, making them publicly auditable.
In this respect, Sia can be viewed as a Bitcoin derivative that includes support for such contracts.
Sia will initially be implemented as an altcoin, and later financially connected to Bitcoin via a two-way peg.
\section{Introduction}
Sia is a decentralized cloud storage platform that intends to compete with existing storage solutions, at both the P2P and enterprise level.
Instead of renting storage from a centralized provider, peers on Sia rent storage from each other.
Sia itself stores only the storage contracts formed between parties, defining the terms of their arrangement.
A blockchain, similar to Bitcoin \cite{btc, btcdg}, is used for this purpose.
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.
The host is compensated for every proof they submit, and penalized for missing a proof.
Since these proofs are publicly verifiable (and are publicly available in the blockchain), network consensus can be used to automatically enforce storage contracts.
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.
We acknowledge that storing data on a single untrusted host guarantees little in the way of availability, bandwidth, or general quality of service.
Instead, we recommend storing data redundantly across multiple hosts.
In particular, the use of erasure codes can enable high availability without excessive redundancy.
Sia will initially be implemented as a blockchain-based altcoin.
Future support for a two-way peg with Bitcoin is planned, as discussed in ``Enabling Blockchain Innovations with Pegged Sidechains'' \cite{side}.
The Sia protocol largely resembles Bitcoin except for the changes noted below.
\section{General Structure}
Sia's primary departure from Bitcoin lies in its transactions.
Bitcoin uses a scripting system to enable a range of transaction types, such as pay-to-public-key-hash and pay-to-script-hash.
Sia opts instead to use an $M$--of--$N$ multi-signature scheme for all transactions, eschewing the scripting system entirely.
This reduces complexity and attack surface.
Sia also extends transactions to enable the creation and enforcement of storage contracts.
Three extensions are used to accomplish this: contracts, proofs, and contract updates.
Contracts declare the intention of a host to store a file with a certain size and hash.
They define the regularity with which a host must submit storage proofs.
Once established, contracts can be modified later via contract updates.
The specifics of these transaction types are defined in sections \ref{sec:contracts} and \ref{sec:storage}.
\section{Transactions}
A transaction contains the following fields: \\
\noindent
\begin{tabular}{ l | l }
\textbf{Field} & \textbf{Description} \\ \hline
Version & Protocol version number \\
Arbitrary Data & Used for metadata or otherwise \\
Miner Fee & Reward given to miner \\
Inputs & Incoming funds \\
Outputs & Outgoing funds (optional) \\
File Contract & See: File Contracts (optional) \\
Storage Proof & See: Proof of Storage (optional) \\
Signatures & Signatures from each input \\
\end{tabular}
\subsection{Inputs and Outputs}
An output comprises a volume of coins.
Each output has an associated identifier, which is derived from the transaction that the output appeared in.
The ID of output $i$ in transaction $t$ is defined as:
\[
H(t || \text{``output''} || i)
\]
where $H$ is a cryptographic hashing function, and ``output'' is a string literal.
The block reward and miner fees have special output IDs, given by:
\[
H(H(\text{Block Header}) || \text{``blockreward''})
\]
Every input must come from a prior output, so an input is simply an output ID.
Inputs and outputs are also paired with a set of \textit{spend conditions}.
Inputs contain the spend conditions themselves, while outputs contain their Merkle root hash \cite{merkle}.
\subsection{Spend Conditions}
Spend conditions are properties that must be met before coins are ``unlocked'' and can be spent.
The spend conditions include a time lock and a set of public keys, and the number of signatures required.
An output cannot be spent until the time lock has expired and enough of the specified keys have added their signature.
The spend conditions are hashed into a Merkle tree, using the time lock, the number of signatures required, and the public keys as leaves.
The root hash of this tree is used as the address to which the coins are sent.
In order to spend the coins, the spend conditions corresponding to the address hash must be provided.
The use of a Merkle tree allows parties to selectively reveal information in the spend conditions.
For example, the time lock can be revealed without revealing the number of public keys or the number of signatures required.
It should be noted that the time lock and number of signatures have low entropy, making their hashes vulnerable to brute-forcing.
This could be resolved by adding a random nonce to these fields, increasing their entropy at the cost of space efficiency.
\subsection{Signatures}
Each input in a transaction must be signed.
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.
The input ID indicates which input the signature is being applied to.
The time lock specifies when the signature becomes valid.
Any subset of fields in the transaction can be signed, with the exception of the signature itself (as this would be impossible).
There is also a flag to indicate that the whole transaction should be signed, except for the signatures.
This allows for more nuanced transaction schemes.
The actual data being signed, then, is a concatenation of the time lock, input ID, flags, and every flagged field.
Every such signature in the transaction must be valid for the transaction to be accepted.
\section{File Contracts}
\label{sec:contracts}
A file contract is an agreement between a storage provider and their client.
At the core of a file contract is the file's Merkle root hash.
To construct this hash, the file is split into segments of constant size and hashed into a Merkle tree.
The root hash, along with the total size of the file, can be used to verify storage proofs.
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.
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).
Submitting a valid proof during the challenge window triggers an automatic payment to the ``valid proof'' address (presumably the host).
If, at the end of the challenge window, no valid proof has been submitted, coins are instead sent to the ``missed proof'' address
(likely an unspendable address in order to disincentivize DoS attacks; see section \ref{subsec:host-protect}).
Contracts define a maximum number of proofs that can be missed; if this number is exceeded, the contract becomes invalid.
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.
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.
Completing or missing a proof results in a new transaction output belonging to the recipient specified in the contract.
The output ID of a proof depends on the contract ID, defined as:
\[
H(\text{transaction} || \text{``contract''} || i)
\]
where $i$ is the index of the contract within the transaction.
The output ID of the proof can then be determined from:
\[
H(\text{contract ID} || \text{outcome} || W_i)
\]
Where $W_i$ is the window index, i.e. the number of windows that have elapsed since the contract was formed.
The outcome is a string literal: either ``validproof'' and ``missedproof'', corresponding to the validity of the proof.
The output ID of a contract termination is defined as:
\[
H(\text{contract ID} || \text{outcome})
\]
Where outcome has the potential values ``successfultermination'' and ``unsucessfultermination'', corresponding to the termination status of the contract.
File contracts are also created with a list of ``edit conditions,'' analogous to the spend conditions of a transaction.
If the edit conditions are fulfilled, the contract may be modified.
Any of the values can be modified, including the contract funds, file hash, and output addresses.
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.
Theoretically, peers could create ``micro-edit channels'' to facilitate frequent edits; see discussion of \mbox{micropayment} channels, section \ref{sec:uptime}.
\section{Proof of Storage}
\label{sec:storage}
Storage proof transactions are periodically submitted in order to fulfill file contracts.
Each storage proof targets a specific file contract.
A storage proof does not need to have any inputs or outputs; only a contract ID and the proof data are required.
\subsection{Algorithm}
Hosts prove their storage by providing a segment of the original file and a list of hashes from the file's Merkle tree.
This information is sufficient to prove that the segment came from the original file.
Because proofs are submitted to the blockchain, anyone can verify their validity or invalidity.
Each storage proof uses a randomly selected segment.
The random seed for challenge window $W_i$ is given by:
\[
H(\text{contract ID} || H(B_{i-1}))
\]
where $B_{i-1}$ is the block immediately prior to the beginning of $W_i$.
If the host is consistently able to demonstrate possession of a random segment, then they are very likely storing the whole file.
A host storing only 50\% of the file will be unable to complete approximately 50\% of the proofs.
\subsection{Block Withholding Attacks}
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.
However, the attacker has only one chance to manipulate the random number for a particular challenge.
Furthermore, withholding a block to manipulate the random number will cost the attacker the block reward.
If an attacker is able to mine 50\% of the blocks, then 50\% of the challenges can be manipulated.
Nevertheless, the remaining 50\% are still random, so the attacker will still fail some storage proofs.
Specifically, they will fail half as many as they would without the withholding attack.
To protect against such attacks, clients can specify a high challenge frequency and large penalties for missing proofs.
These precautions should be sufficient to deter any financially-motivated attacker that controls less than 50\% of the network's hashing power.
Regardless, clients are advised to plan around potential Byzantine attacks, which may not be financially motivated.
\subsection{Closed Window Attacks}
Hosts can only complete a storage proof if their proof transaction makes it into the blockchain.
Miners could maliciously exclude storage proofs from blocks, depriving themselves of transaction fees but forcing a penalty on hosts.
Alternatively, miners could extort hosts by requiring large fees to include storage proofs, knowing that they are more important than the average transaction.
This is termed a \textit{closed window attack}, because the malicious miner has artificially ``closed the window.''
The defense for this is to use a large window size.
Hosts can reasonably assume that some percentage of miners will include their proofs in return for a transaction fee.
Because hosts consent to all file contracts, they are free to reject any contract that they feel leaves them vulnerable to closed window attacks.
\section{Arbitrary Transaction Data}
Each transaction has an arbitrary data field which can be used for any type of information.
Nodes will be required to store the arbitrary data if it is signed by any signature in the transaction.
Nodes will initially accept up to 64 KB of arbitrary data per block.
This arbitrary data provides hosts and clients with a decentralized way to organize themselves.
It can be used to advertise available space or files seeking a host, or to create a decentralized file tracker.
Arbitrary data could also be used to implement other types of soft forks.
This would be done by creating an ``anyone-can-spend'' output but with restrictions specified in the arbitrary data.
Miners that understand the restrictions can block any transaction that spends the output without satisfying the necessary stipulations.
Naive nodes will stay synchronized without needing to be able to parse the arbitrary data.
\section{Storage Ecosystem}
Sia relies on an ecosystem that facilitates decentralized storage.
Storage providers can use the arbitrary data field to announce themselves to the network.
This can be done using standardized template that clients will be able to read.
Clients can use these announcements to create a database of potential hosts, and form contracts with only those they trust.
\subsection{Host Protections}
\label{subsec:host-protect}
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.
The provider may also refuse to sign a contract until the entire file has been uploaded to them.
Contract terms give storage providers some flexibility.
They can advertise themselves as minimally reliable, offering a low price and a agreeing to minimal penalties for losing files;
or they can advertise themselves as highly reliable, offering a higher price and agreeing to harsher penalties for losing files.
An efficient market will optimize storage strategies.
Hosts are vulnerable to denial of service attacks, which could prevent them from submitting storage proofs or transferring files.
It is the responsibility of the host to protect themselves from such attacks.
\subsection{Client Protections}
\label{subsec:client-protect}
Clients can use erasure codes, such as regenerating codes \cite{reg}, to safeguard against hosts going offline.
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.
(The values of $n$ and $m$ vary based on the specific erasure code and redundancy factor.)
Each piece is then encrypted and stored across many hosts.
This allows a client to attain high file availability even if the average network reliability is low.
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.
Availability can be further improved by rehosting file pieces whose hosts have gone offline.
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.
These downloads can be run in parallel to maximize available bandwidth.
\subsection{Uptime Incentives}
\label{sec:uptime}
The storage proofs contain no mechanism to enforce constant uptime.
There are also no provisions that require hosts to transfer files to clients upon request.
One might expect, then, to see hosts holding their clients' files hostage and demanding exorbitant fees to download them.
However, this attack is mitigated through the use of erasure codes, as described in section \ref{subsec:client-protect}.
The strategy gives clients the freedom to ignore uncooperative hosts and work only with those that are cooperative.
As a result, power shifts from the host to the client, and the ``download fee'' becomes an ``upload incentive.''
In this scenario, clients offer a reward for being sent a file, and hosts must compete to provide the best quality of service.
Clients may request a file at any time, which incentivizes hosts to maximize uptime in order to collect as many rewards as possible.
Clients can also incentivize greater throughput and lower latency via proportionally larger rewards.
Clients could even perform random ``checkups'' that reward hosts simply for being online, even if they do not wish to download anything.
However, we reiterate that uptime incentives are not part of the Sia protocol; they are entirely dependent on client behavior.
Payment for downloads is expected to be offered through preexisting micropayment channels \cite{mpc}.
Micropayment channels allow clients to make many consecutive small payments with minimal latency and blockchain bloat.
Hosts could transfer a small segment of the file and wait to receive a micropayment before proceeding.
The use of many consecutive payments allows each party to minimize the risk of being cheated.
Micropayments are small enough and fast enough that payments could be made every few seconds without having any major effect on throughput.
\subsection{Basic Reputation System}
Clients need a reliable method for picking quality hosts.
Analyzing their history is insufficient, because the history could be spoofed.
A host could repeatedly form contracts with itself, agreeing to store large ``fake'' files, such as a file containing only zeros.
It would be trivial to perform storage proofs on such data without actually storing anything.
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.
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.
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.
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.
More complex systems, such as those that use human review or other metrics, could be implemented out-of-band in a more centralized setting.
\section{Siafunds}
Sia is a product of Nebulous Incorporated.
Nebulous is a for-profit company, and Sia is intended to become a primary source of income for the company.
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.
When the company needs to spend money, it must trade away portions of its source of income.
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.
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.
This is accomplished by imposing a fee on all contracts.
When a contract is created, 3.9\% of the contract fund is removed and distributed to the holders of \textit{siafunds}.
Nebulous Inc. will initially hold approx. 88\% of the siafunds, and the early crowd-fund backers of Sia will hold the rest.
Siafunds can be sent to other addresses, in the same way that siacoins can be sent to other addresses.
They cannot, however, be used to fund contracts or miner fees.
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.
These siacoins are sent to the same address as the siafunds.
\section{Economics of Sia}
The primary currency of Sia is the siacoin.
The supply of siacoins will increase permanently, and all fresh supply will be given to miners as a block subisdy.
The first block will have 300,000 coins minted.
This number will decrease by 1 coin per block, until a minimum of 30,000 coins per block is reached.
Following a target of 10 minutes between blocks, the annual growth in supply is:\\
\tabcolsep=0.11cm \noindent
\begin{tabular}{ l | *{7}{c} }
Year & 1 & 2 & 3 & 4 & 5 & 8 & 20 \\ \hline
Growth & 90\% & 39\% & 21\% & 11.5\% & 4.4\% & 3.2\% & 2.3\%
\end{tabular} \\
There are inefficiencies within the Sia incentive scheme.
The primary goal of Sia is to provide a blockchain that enforces storage contracts.
The mining reward, however, is only indirectly linked to the total value of contracts being created.
The siacoin, especially initially, is likely to have high volatility.
Hosts can be adversely affected if the value of the currency shifts mid-contract.
As a result, we expect to see hosts increasing the price of long-term contracts as a hedge against volatility.
Additionally, hosts can advertise their prices in a more stable currency (like USD) and convert to siacoin immediately before finalizing a contract.
Eventually, the use of two-way pegs with other crypto-assets will give hosts additional means to insulate themselves from volatility.
% \section{Under Consideration}
% The primary foundation of Sia has been established above.
% Other considerations, such as mining algorithms, block time, etc., can be assumed to mirror those found in Bitcoin.
% 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.
% We caution that these propositions have not yet been rigorously examined from a security standpoint.
% \subsection{Flexible Contracts}
% Contracts, in their present form, are fairly strict.
% There is a set penalty for each missed storage proof, and a termination upon $n$ total missed storage proofs.
% Increased flexibility in the penalty schedule may be desirable.
% Contracts are also permanent, creating what is essentially an uneditable file on the network.
% There may be value in enabling clients and hosts to negotiate an updated file hash or other updated contract terms.
% Updating the terms of the contract would require consent from all parties.
% \subsection{Proof of Existence Windows}
% In an attempt to partially resolve the closed window attacks, we could use a proof of existence strategy.
% A host can create a hash of the storage proof which they submit to the blockchain within the window.
% The host then has a greatly extended window in which they can demonstrate that the proof of storage was created during the required window.
% This has two advantages.
% First, an attacker cannot selectively exclude proof of existence hashes, because there's no way to figure out who owns each hash.
% Either the attacker doesn't include any unknown proof of existence hashes, or the attacker risks including undesired proof of existence hashes.
% 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.
% A further improvement would enable Merkle Tree proofs of existence.
% This would enable a host to submit multiple proofs of storage in a single proof of existence hash.
% % delete/expand this section?
% \subsection{Siafund the Miner fees}
% 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.
% \subsection{Miner Fee Adjustments}
% 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.
% 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.
% Link to discussion threads of this potential change.
% Additionally, miners have incentives not to propagate high fee transactions, because this will prevent other miners from mining the transaction and collecting the fees.
% 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.
% Link to discussion threads of this potential change.
% \subsection{More Frequent Target Adjustments}
% % 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.
% Bitcoin adjusts its block difficulty every 2016 blocks, with a target of 10 minutes per block.
% 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.
% To mitigate this effect, we are considering adjusting the difficulty after every block.
% % I don't understand this paragraph
% 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.
% Difficulty adjustments every block creates a much smoother function for when mining rigs are no longer profitable.
% The clamp on mining growth can also be increased.
% The clamp serves to prevent an attacker from being easily manipulating the difficulty.
% % 2,016,000 what?
% 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.
% 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.
% 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.
% 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.
% \subsection{Committing to State}
% 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.
% This would mean creating a structure for a database that represents the state of the network and hashing it.
% We could follow suggestions similar to those presented in ``Ultimate blockchain compression'' \cite{ubc}.
% \subsection{Variance Enforced Merge Mining}
% Bitcoin enforces a number of leading 0s on a winning block.
% Sia could enforce something like a single leading 1, followed by a bunch of leading 0s.
% This creates the property that no hash is ever valid for both Bitcoin and Sia.
% The value to this is that the number of payouts a miner gets from finding blocks goes up.
% 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.
% A block that solves the coin with the highest difficulty will always be valid for both blockchains.
% (I need to read more about merge mining before I publish this section)
\section{Conclusion}
Sia is a variant on the Bitcoin protocol that enables decentralized file storage via cryptographic contracts.
These contracts can be used to enforce storage agreements between clients and hosts.
After agreeing to store a file, a host must regularly submit storage proofs to the network.
The host will automatically be compensated for storing the file regardless of the behavior of the client.
Importantly, contracts do not require hosts to transfer files back to their client when requested.
Instead, an out-of-band ecosystem must be created to reward hosts for uploading.
Clients and hosts must also find a way to coordinate; one mechanism would be the arbitrary data field in the blockchain.
Various precautions have been enumerated which mitigate Sybil attacks and the unreliability of hosts.
Siafunds are used as a mechanism of generating revenue for Nebulous Inc., the company responsible for the release and maintenance of Sia.
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.
Miners may also derive a part of their block subsidy from siafunds, with similar benefits.
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.
We believe Sia will provide a fertile platform for decentralized cloud storage in trustless environments.
\onecolumn
\begin{thebibliography}{9}
\bibitem{btc}
Satoshi Nakamoto,
\emph{Bitcoin: A Peer-to-Peer Electronic Cash System}.
\bibitem{merkle}
R.C. Merkle,
\emph{Protocols for public key cryptosystems},
In Proc. 1980 Symposium on Security and Privacy,
IEEE Computer Society, pages 122-133, April 1980.
\bibitem{cpr}
Hovav Shacham, Brent Waters,
\emph{Compact Proofs of Retrievability},
Proc. of Asiacrypt 2008, vol. 5350, Dec 2008, pp. 90-107.
\bibitem{reg}
K. V. Rashmi, Nihar B. Shah, and P. Vijay Kumar,
\emph{Optimal Exact-Regenerating Codes for Distributed Storage at the MSR and MBR Points via a Product-Matrix Construction}.
\bibitem{side}
Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Peolstra, Jorge Timon, Pieter Wuille,
\emph{Enabling Blockchain Innovations with Pegged Sidechains}.
\bibitem{alts}
Andrew Poelstra,
\emph{A Treatise on Altcoins}.
\bibitem{ibf}
Gavin Andresen,
\emph{O(1) Block Propagation},
https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2
\bibitem{hdw}
Gregory Maxwell,
\emph{Deterministic Wallets},
https://bitcointalk.org/index.php?topic=19137.0
\bibitem{ubc}
etotheipi,
Ultimate blockchain compression w/ trust-free lite nodes, \newline
https://bitcointalk.org/index.php?topic=88208.0
\bibitem{poc}
Gregory Maxwell,
\emph{Proof of Storage to make distributed resource consumption costly.} \newline
https://bitcointalk.org/index.php?topic=310323.0
\bibitem{mpc}
Mike Hearn,
\emph{Rapidly-adjusted (micro)payments to a pre-determined party},\newline
https://en.bitcoin.it/wiki/Contracts\#Example\_7:\_Rapidly-adjusted\_.28micro.29payments\_to\_a\_pre-determined\_party
\bibitem{btcdg}
Bitcoin Developer Guide,
https://bitcoin.org/en/developer-guide
\end{thebibliography}
\end{document}

BIN
3rd_party/Sia-v1.1.1-windows-amd64/siac.exe vendored
View File

Binary file not shown.

BIN
3rd_party/Sia-v1.1.1-windows-amd64/siac.exe.sig vendored
View File

Binary file not shown.

BIN
3rd_party/Sia-v1.1.1-windows-amd64/siad.exe vendored
View File

Binary file not shown.

BIN
3rd_party/Sia-v1.1.1-windows-amd64/siad.exe.sig vendored
View File

Binary file not shown.

40
CMakeLists.txt
View File

@@ -82,9 +82,9 @@ target_link_libraries(siadrive PRIVATE siadrive.api siadrive.dokan.api)
if (MSVC)
target_include_directories(siadrive PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/cef)
target_link_libraries(siadrive PRIVATE
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/obj/cef/libcef_dll_wrapper.lib
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/libcef.dll.lib
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/chrome_elf.dll.lib)
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/obj/cef/libcef_dll_wrapper.lib
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/libcef.dll.lib
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/chrome_elf.dll.lib)
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
set_target_properties(siadrive PROPERTIES COMPILE_FLAGS "/MTd")
@@ -93,28 +93,28 @@ if (MSVC)
endif()
set(CEF_LIBS
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/libcef.dll
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/chrome_elf.dll
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/osmesa.dll
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/libEGL.dll
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/libGLESv2.dll
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/d3dcompiler_47.dll)
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/libcef.dll
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/chrome_elf.dll
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/osmesa.dll
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/libEGL.dll
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/libGLESv2.dll
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/d3dcompiler_47.dll)
file(GLOB CEF_SUPPORT
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/icudtl.dat
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/cef.pak
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/*.bin
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/cef_*.pak)
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/icudtl.dat
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/cef.pak
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/*.bin
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/cef_*.pak)
if (CMAKE_BUILD_TYPE STREQUAL "Debug")
set(CEF_LIBS ${CEF_LIBS}
${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}/siadrive.pdb
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/libcef.dll.pdb
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/chrome_elf.dll.pdb
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/osmesa.dll.pdb
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/libEGL.dll.pdb
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/libGLESv2.dll.pdb
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/obj/cef/libcef_dll_wrapper_cc.pdb)
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/libcef.dll.pdb
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/chrome_elf.dll.pdb
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/osmesa.dll.pdb
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/libEGL.dll.pdb
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/libGLESv2.dll.pdb
${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/obj/cef/libcef_dll_wrapper_cc.pdb)
endif()
SET ( CMAKE_EXE_LINKER_FLAGS /MANIFEST:NO )
@@ -133,7 +133,7 @@ if (MSVC)
install(FILES ${CEF_SUPPORT} DESTINATION ${SIADRIVE_INSTALL_FOLDER})
install(TARGETS siadrive.api siadrive.dokan.api DESTINATION ${SIADRIVE_INSTALL_FOLDER})
install(TARGETS siadrive DESTINATION ${SIADRIVE_INSTALL_FOLDER})
install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/out_2987/${CMAKE_BUILD_TYPE}_GN_x64/locales DESTINATION ${SIADRIVE_INSTALL_FOLDER})
install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/3rd_party/CEF/chromium_git/ochromium/src/out/${CMAKE_BUILD_TYPE}_GN_x64/locales DESTINATION ${SIADRIVE_INSTALL_FOLDER})
install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/htdocs DESTINATION ${SIADRIVE_INSTALL_FOLDER})
endif()

14
build_common.cmd
View File

@@ -4,9 +4,17 @@ set PATH=%ROOT%bin;%PATH%
pushd "%ROOT%"
wget --no-check-certificate https://cmake.org/files/v3.7/cmake-3.7.2-win64-x64.zip || goto :ERROR
unzip -o -q -d bin\ cmake-3.7.2-win64-x64.zip || goto :ERROR
del /q cmake-3.7.2-win64-x64.zip || goto :ERROR
if NOT EXIST "bin\cmake-3.7.2-win64-x64\bin\cmake.exe" (
wget --no-check-certificate https://cmake.org/files/v3.7/cmake-3.7.2-win64-x64.zip || goto :ERROR
unzip -o -q -d bin\ cmake-3.7.2-win64-x64.zip || goto :ERROR
del /q cmake-3.7.2-win64-x64.zip || goto :ERROR
)
if NOT EXIST "\bin\nsis-3.01\nsis.exe" (
wget --no-check-certificate "https://sourceforge.net/projects/nsis/files/NSIS 3/3.01/nsis-3.01.zip/download" || goto :ERROR
unzip -o -q -d bin\ nsis-3.01.zip || goto :ERROR
del /q nsis-3.01.zip
)
goto :END

4
build_debug_x64.cmd
View File

@@ -2,10 +2,10 @@
set ROOT=%~dp0%
pushd "%ROOT%"
REM call build_common.cmd
call build_common.cmd
set CMAKE=%ROOT%bin\cmake-3.7.2-win64-x64\bin\cmake
REM call 3rd_party\CEF\create.cmd Debug
call 3rd_party\CEF\create.cmd Debug
mkdir build
mkdir build\debug

12
htdocs/js/index.js
View File

@@ -1,8 +1,12 @@
// Main
(() => {
window.uiUpdate = (()=> {
function setInnerText(id, balance) {
document.getElementById(id).innerText = balance;
function setInnerText(id, text) {
document.getElementById(id).innerText = text;
}
function setValue(id, value) {
document.getElementById(id).value = value;
}
function setSelect(id, itemList) {
@@ -78,7 +82,9 @@
setInnerText('ID_ServerVersion', version);
},
setAvailableDriveLetters: (drives)=> {
setSelect('ID_MountDrives', drives);
if (document.getElementById('ID_MountButton').innerText !== 'Unmount') {
setSelect('ID_MountDrives', drives);
}
}
};
})();