typos

swarm/docs/smash/smash.rst

@@ -41,7 +41,7 @@ Auditing a particular chunk :math:`\chunk` is done via a *challenge*. Who initia
 
 To generate a challenge the original owner only needs to reveal a *seed*. Once the storer learns the seed for the challenge, they can use this seed to find the corresponding *secret* by a procedure defined below which requires them to have the data. The secret itself is the response to the challenge in its simplest form.
 
-If the secret is not prematurely revealed by the original owner, the storers must have calculated it themselves, since it cannot be guessed and is cryptographically secure against brute forcing if the set of seeds is large enough. As the calculation relies on the data, storers are incentivised to keep the chunk in full. Once a secret is verified as valid, it is fair to assume that the swarm had the file at some point. Moreover, as the seed had never been revealed until the challenge was issued nor was the seed or guessable in advance, and since the seed was also used in the calculation, we know that storers still have the chunk currently, ie., at least they had it when the seed was revealed.
+If the secret is not prematurely revealed by the original owner, the storers must have calculated it themselves, since it cannot be guessed and is cryptographically secure against brute forcing if the set of seeds is large enough. As the calculation relies on the data, storers are incentivised to keep the chunk in full. Once a secret is verified as valid, it is fair to assume that the swarm had the file at some point. Moreover, as the seed had never been revealed until the challenge was issued nor was the seed guessable in advance, and since the seed was also used in the calculation, we know that storers still have the chunk currently, ie., at least they had it when the seed was revealed.
 
 If the storer keeps the data they will always know that they will always be able to calculate a correct response.
 If a storer chooses not to preserve the data, it is impossible to be 100% sure that they give the right secret to a challange. Given these properties it is valid to say that *responding to a challenge with a valid secret can be considered a reliable positive proof of current custody*.
@@ -551,7 +551,7 @@ As a consequence of this, the best strategy is to proceed backwards and check th
 ..  rubric:: Footnotes
 ..  [#] In order to protect against offending nodes to simply responding with frivolous litigation notices, the notice needs to contain a transaction hash for the challenge sent to the blockchain. This way parent auditors can rest assured the audit is indeed escalated.
 
-Note that in our recursive auditing scheme, the intermediate (non leaf) nodes were not only audited themselves, but they also served to initiate audits on the subtrees encoded in their chunk. This offers great efficiency gains becasue if the entire audit were to be carried out by just one peer, then chunks for each intermediate node would need to be retrieved in order for the main auditor to initiate all the audit requests for subtrees. Collective auditing has the immediate benefit that no intermediate chunks ever need to be actually retrieved, because the audit of subtrees are carried out by peers that store the chunk.
+Note that in our recursive auditing scheme, the intermediate (non leaf) nodes were not only audited themselves, but they also served to initiate audits on the subtrees encoded in their chunk. This offers great efficiency gains because if the entire audit were to be carried out by just one peer, then chunks for each intermediate node would need to be retrieved in order for the main auditor to initiate all the audit requests for subtrees. Collective auditing has the immediate benefit that no intermediate chunks ever need to be actually retrieved, because the audit of subtrees are carried out by peers that store the chunk.
 
 Ensuring correct syncing and distribution
 ------------------------------------------------------------

swarm/docs/sw^3/storage.rst

@@ -30,6 +30,7 @@ Filecoin's proof of work is defined to include proof that the miner possesses a
 Using a strong proof of retrievability scheme, IPFS ensures that winning miner had relevant data. As miners compete, they find their chances of winning will be proportional to the percentage of the existing storage units they actually store. This is because the missing ones need to be retrieved from other nodes and thus delaying nodes chance to respond.
 
 We see a whole range of issues with this particular approach:
+
 * it is not clear that network latency cannot be masked by the parallel calculation of the ordinary proof of work component in the algorithm
 * if the set of chunks are not selected differently for each node, mining will resemble a DDOS on nodes that actually store the data needed for the round.
 * even if the selection of data to prove varies depending on the miner, normal operation incurs huge network traffic
@@ -48,7 +49,7 @@ To summarise, we consider positive incentivisation in itself insufficient for en
 Compensation for storage and guarantees for long-term data preservation
 ========================================================================
 
-While Swarm's core storage component is analogous to traditional DHTs both in terms of network topology and routing used in retrieval, it uses the narrowest interpretation of immutable content addressed archive. Instead of just metadata about the whereabouts of the the addressed content, the proximate nodes actually store the data itself.
+While Swarm's core storage component is analogous to traditional DHTs both in terms of network topology and routing used in retrieval, it uses the narrowest interpretation of immutable content addressed archive. Instead of just metadata about the whereabouts of the addressed content, the proximate nodes actually store the data itself.
 When a new chunk enters the swarm storage network, it is propagated from node to node via a process called 'syncing'. The goal is for chunks to end up at nodes whose address is closest to the chunk hash. This way chunks can be located later for retrieval using kademlia key-based routing.
 
 ..  index::
@@ -71,12 +72,12 @@ A long-term storage incentivisation scheme faces unique challenges. For example,
 
 Instead, we need punitive measures to ensure compliance with storage promises. These will work using a :dfn:`deposit system`. Nodes wanting to sell promisory storage guarantees should have a *stake verified and locked-in* at the time of making their promise. This implies  that nodes must be *registered* in advance with a contract and put up a security deposit.
 
-Following :dfn:`registration`, a node may sell storage promises covering the time period for which their funds are locked. While their registration is active, if they are found to have lost a chunk that was covered by their promise, they stand to loose (part of) their deposit.
+Following :dfn:`registration`, a node may sell storage promises covering the time period for which their funds are locked. While their registration is active, if they are found to have lost a chunk that was covered by their promise, they stand to loose their deposit.
 
 Requirements
 -------------
 
-In this context, :dfn:`*owner*` refers to the originator of a chunk (the one that uploads a document to the swarm), while :dfn:`storer` refers to a swarm node that actually stores the given chunk.
+In this context, :dfn:`owner` refers to the originator of a chunk (the one that uploads a document to the swarm), while :dfn:`storer` refers to a swarm node that actually stores the given chunk.
 
 Let us start from some reasonable usage requirements:
 
@@ -87,8 +88,6 @@ Let us start from some reasonable usage requirements:
 
 An Owner's risk preference consists of the time period covered as well as on the :dfn:`degrees of redundancy` or certainty. These preferences should be specified on a per-chunk basis and they should be completely flexible on the protocol level.
 
-The total amount of deposit that nodes risk losing in case the chunk is lost could also be variable. Degrees of redundancy could be approximated by the total amount of deposit storers stake: in this approximation two nodes standing to lose 50 each if a chunk is lost provide as much security as five nodes each standing to lose 20. In this kind of network, the security deposit is therefore a variable amount that each node advertises. Variants of this deposit scheme are discussed below.
-
 Satisfying storers' risk preferences means that they have ways to express their certainty of preserving what they store and factor that in their pricing. Some nodes may not wish to provide storage guarantees that are too long term while others cannot afford to stake too big of a deposit. This differentiates nodes in their competition for service provision.
 
 A *market mechanism* means there is flexible price negotation or discovery or automatic feedback loops that tend to respond to changes in supply and demand.