Clarify (ir-)recoverability of complete slashing

[anorth]

The faults spec for a consensus fault states that

All of the miner's pledge collateral and all of their power is irrevocably slashed

For an unreported storage fault, it doesn't use the word "irrecoverable" but does remove all collateral and power.

Please clarify what "irrecoverable" means in this context. Is it just emphasising that the offender can't get their pledge collateral back, or is it implying that the miner can no longer participate in consensus block mining (and/or other functions), even if it posts new collateral. Are both faults irrecoverable or is the storage fault intentionally recoverable?

Pseudocode in https://github.com/filecoin-project/specs/blob/master/actors.md#slashconsensusfault and https://github.com/filecoin-project/specs/blob/master/actors.md#slashstoragefault both seem to imply the latter, but both have very different "implementations" of that. If this really is intended, then other methods which might recover (such as pledging new collateral) must check the SlashedAt or whatever state change is implied by SelfDestruct().

[anorth]

This paragraph in the mining spec talks about a reinstatement mechanism (since the miner hasn't lost their storage collateral, assuming it's distinct from pledge collateral). That may be out of date, though, failing to account for generation attack window.

[anorth]

The go-filecoin team are designing and implementing this in the immediate future, as part of our efforts to complete storage protocol implementation. An indicative response here ahead of the actual spec would be helpful.

[whyrusleeping]

Consensus slashing is irrevocable. the miner is ejected from the storage market and can no longer mine blocks (the current spec also has the miner actor deleted entirely).

Storage faults are recoverable, intentionally. If you go offline for some time due to an emergency, or hardware failure, you should still be able to continue providing your services to the network.

[anorth]

Thanks, makes sense.

In SlashStorageFault:

	if self.SlashedAt > 0 {
		Fatal("miner already slashed")
	}

... is probably incorrect, unless something will reset SlashedAt. The subsequent test for an empty proving set probably covers it.

[whyrusleeping]

Yeah, there isnt yet a way in the spec for a storage miner to recover. we need to figure out a way for that to happen