-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make arbitrate deal able to slash miners for never posting the sector #306
Comments
one way we could do this would be to allow the unstarted deal slashing only for the duration of one proving period after the deal start, then when the miner is slashed, add this to the arbitrated deals set. I think this has the desired effect, needs more thought |
ArbitrateDeal currently looks to penalise both pledge and storage collateral, which doesn't match |
At the beginning of payment channel setting up, miner and client both should put collateral (that is a kind of storage collateral) into a payment channel which should trigger arbitrated deal (which acts like smart contract) to penalize either side of the payment channel who breach the deal after proving period expire. |
In general, collateral is only required to be posted by the miner when committing a sector. For the first sector a miner could post (but hasn't yet, hence the need to arbitrate), there will be no collateral to penalise. But I guess for subsequent deals, where a miner does have some committed sectors, the collateral for those sectors could be penalised. The miner would then have to post new collateral before committing further sectors. Unless we change how and when collateral is posted, arbitration may have to handle the possibility that the miner has zero balance. |
if a miner and a client make a deal, and the miner never posts the sector, the client should have some recourse. The miner can never get paid for this data, but the client is out their fees for setting up the payment channel, their time, and bandwidth. So that kinda sucks for them.
This isnt easy, as we have to balance this solution against the client not being allowed to slash the miner twice for the same failed deal, all while avoiding putting information about each deal on chain.
The text was updated successfully, but these errors were encountered: