What happens in the case of repair when there is no request expiry? Will the sliding Kademlia address window be enough of a deterrent?

Good question, I think we should add a maximum duration for repair. When the host fails to repair within that time, it also loses its collateral. What do you think?

Good point @emizzle, I would say @markspanbroek solution should work 👍 I guess we will make it as Contract's constructor parameter?

How would the max duration be checked? It would require a transaction.

The max duration might need to be a function of the rate at which the sliding window expands (or inversely the rate which the sliding window expands might need to be a function of the max duration) because it feels like we should have allowed x% of the network to attempt to repair the slot before we close off the ability to repair the slot.

I guess we will make it as Contract's constructor parameter?

The max duration for repair would depend on several factors, such as the data size, the amount of redundancy, the overall capacity in the network for repair, or even the sliding window as @emizzle mentioned. So I would add it as a parameter to the storage request, for the client to determine. Better to have that complexity in the node than in the smart contract.

How would the max duration be checked? It would require a transaction.

Good point. When the host has not sent in a storage proof within the maximum duration for repair, it won't be able to withdraw its collateral. Also, a new host is allowed to reserve the slot after the maximum duration, at which point the collateral of the previous host can be burned. The main drawback of this is that there won't be a nice SlotFreed event when the maximum duration is reached, which makes it harder for hosts to act on it.

The max duration for repair would depend on several factors, such as the data size, the amount of redundancy, the overall capacity in the network for repair, or even the sliding window as @emizzle mentioned. So I would add it as a parameter to the storage request, for the client to determine. Better to have that complexity in the node than in the smart contract.

I guess makes sense, although couldn't we just simply reuse the request expiry duration also for repair expiry? Maybe increased by some coefficient (which could be contract-wide) to offset potential additional recovery/recomputation of data? IMHO it could be used for now and if we find later on the need to have it separated into its own parameter than we can add it later on...

I mean the request expiry already should incorporate in its calculation variables like data size, redundancy etc...

The "overall capacity in the network for repair" is also IMHO something that is not possible to estimate prior to repair is really needed.

The main drawback of this is that there won't be a nice SlotFreed event when the maximum duration is reached, which makes it harder for hosts to act on it.

The SlotFreed is currently emitted thanks to Validators that check the proofs were submitted. Maybe they could also check if the reserved slot was indeed filled? Provided that we would offer them a cut on the burned collateral?

I mean the request expiry already should incorporate in its calculation variables like data size, redundancy etc...

Not exactly, when there is very little redundancy (n-k is small) then there are only a few hosts that have the data necessary for repair. This could slow down repairs. But the total amount of data is smaller, so starting the contract could be faster.

The SlotFreed is currently emitted thanks to Validators that check the proofs were submitted. Maybe they could also check if the reserved slot was indeed filled? Provided that we would offer them a cut on the burned collateral?

That is a good idea. In a way they'd be looking for additional missing proofs.

The max duration for repair would depend on several factors, such as the data size, the amount of redundancy, the overall capacity in the network for repair, or even the sliding window as @emizzle mentioned. So I would add it as a parameter to the storage request, for the client to determine. Better to have that complexity in the node than in the smart contract.

This may be too detailed for now and a problem we can address later, but we should at least consider bounding the max duration parameter in the contract to prevent clients from being able to shoot themselves in the foot. Too small of a value could cause slots to go unrepaired and the contract to fail. Too large could cause squatting. Also, if the sliding window is contract-based, the max duration parameter could be bounded by the sliding window rate to provide opportunity to a minimum % of the hosts for repair (as mentioned previously).

Good point @emizzle, I would say @markspanbroek solution should work 👍 I guess we will make it as Contract's constructor parameter?

I think overall, these approaches have severe UX drawbacks and they expose both the client and the providers to serious loss, both in monetary and resources. I did an analysis around the initial contract interaction. I believe approach 2 from my writeup is the most flexible and has the best UX characteristics, we should seriously re-evaluate this approach in the same context.

Thanks for the detailed write-up. I think you're right. Allowing a host to reserve a slot without collateral makes the whole design simpler. Squatting of slots, which is the main downside of this approach, is discouraged by both the gas fees, and the expanding window mechanism. I think those should be enough of a deterrent. I have updated the document to reflect this design.

I am not so convinced about approach 2 and the deterrents, more here: #166 (comment)

Adam raised some good points about the strength of the deterrents to prevent squatting. If we could disincentivise client withholding, then perhaps approach 3 would be the best. I outlined a suggestion in the discussion.