notes.md

• 1.1. "the probability of it being requested" - what's "it"? Should probably say "a given chunk".
• 1.2.1 "discreet" should be "discrete".
• 1.2.3 "Unfortunately, barring basic verification, no guarantees can be gained from the raw transaction." - what guarantees are missing?
• 1.2.3 "Receiver may only keep" should be "The receiver may keep only".
• 1.2.3 Doesn't the chequebook contract suffer from the same nonce-order issue as regular payments?
• 2.3 "First we show how [to] delegate"
• 2.3 "this yields a potential256푥equivalent replicas the owner can upload" - doesn't it only yield 256 replicas, since any chunks with the same nonce will be stored identically?
• 2.3.1 "Here is a schematic: (Figure 2.3.1)" - there's no figure.
• 2.4 Steps 1-2 appear to read the whole file, so what does 3. repeat? In general, this pseudocode is difficult to understand as currently formulated.
• 2.4 "Overcompensating, we could say that there should always be the same number of paritychunks (eg. 28) even when there are fewer (than 100) data chunks so that we alwasy end upwith m-of-m+28. " - this would lead to 30 chunks where there were previously two - a huge increase!
• Having two different schemes for generating alternate chunk encodings seems unduly complex. Why not pick one that works for all lengths?
• 2.4 Footnote 3 is truncated.
• 2.4 & 2.5 - if nodes request parity chunks by default, doesn't this mean that random access into a file is no longer possible without loading at least an entire level of the tree?
• Instead of using error coding, couldn't you ask for receipts from multiple nodes?
• Instead of burning the deposit, couldn't you require it to be at least as much as the value of all insured storage?
• Could the payment for storage be used in place of the deposit? As time goes on, a storer has 'earned' some fraction of the fee, but won't get any of it unless they keep it the whole duration, so their incentive to keep it goes up towards the end of the retention period.
• 2.7 What is the receiving node's incentive to pay to receive a chunk, when it doesn't know if it'll ever be fetched? Could a malicious attacker generate huge volumes of useless chunks that hash close to a victim node, to skew the balance of payments for that node?
• 2.8.1 Extra stars around 'auditing'.
• Is there any need to upload the actual block to the blockchain? Uploading a proof would prove the storer has the block, and although they could retain it for proofs but refuse to produce it, there's no incentive to do that. On the other hand, if the entire block has to be uploaded, and the user has to pay for that, a similarly malicious node could force everything to litigation, costing the user the entire cost of uploading the missing file to the blockchain, again to no advantage of the storer's.
• Perhaps user and storer should have to pay half the cost each of uploading a chunk, so both have a strong disincentive?
• 2.9.2 ":dfn:guardian" in the generated PDF.
• 2.9.2 "it needs to provide validreceipts from closer nodes with deposit totalling X or more" "This process will end up blaminga single node for the loss" - couldn't multiple nodes end up being held responsible if none of them have the block?
• 2.9.3 If the custodian retains the receipts for the cocustodians, what happens if the custodian goes offline?
• 2.9.4 "rubust".
• 2.10.1 How users pay for storage isn't really adequately described. This section notes they can't be treated as a 'balance of payments' like regular chunk exchanges, but doesn't explain how they will be treated.
• 2.11.1 I think this is the first mention of "sync tokens". What are they?
• How does setting a required deposit interact with how chunks are stored to the closest verified peers? If I set a large deposit, the 3 closest nodes might be a long way from the target hash; how are they located?
• 3.3 Issued cheques can't ever decrease in value, so how does IOU swapping work?

2.4 "Overcompensating, we could say that there should always be the same number of paritychunks (eg. 28) even when there are fewer (than 100) data chunks so that we alwasy end upwith m-of-m+28. " - this would lead to 30 chunks where there were previously two - a huge increase!

absolutely correct. we are aware of this. However, two points

1. More likely than 100-of-128, we will see encodings using 120 data chunks or even more: 125-of-128.
2. Without this overcompensation we cannot guarantee the same level of safety for the left over chunks. The exact redundancy required to get the same degree of safety depends on variables whose value we do not know (for example the probability of a chunk going missing in a given time period). Thus we either have to estimate all those value, or we overcompensate.