Paying the storage miner under the offchain repair model about specs HOT 8 CLOSED

I like the 'after data transfer' approach for cases where the client is a broker. Since brokers are staked pretty heavily on-chain, the cost to DoS a miner as a broker is quite high.

For arbitrary clients, I don't think there are any good solutions that don't present DoS vectors. The first 'up front' method could work, but the expense is really annoying, and random clients arent likely to sit around waiting for storage miners to ask them to reconcile their payment channel updates.

from specs.

I have a new payment channel construction for Broker<->Miner payments that has nice coalescing and multi-lane payments (can have multiple independent vouchers for different file storage agreements). I'll try and post that early next week after I clean it up a bit.

from specs.

From @nicola: CommD does go on chain (unless we do weird aggregation stuff). This makes the 'after data transfer' method much more viable

from specs.

Thought: The information required by the miner to cash out a payment channel voucher should contain the data needed by the repair broker to prove they are doing their job correctly. In this case, the way that the repair miner 'challenges' the storage miner for the inclusion proof is by threatening to close the payment channel.

Needs more thought, but if it works out, it should simplify things.

from specs.

The initial up-front approach could just be: Payments are contingent on the existence of a sector on-chain from the miner that contains the subtree X, where X is the file in question. The 'proof' here would be a merkleproof, from the sector CommD root to X, for any size of X larger than 1MB, this should be less than 300 bytes, which is reasonable.

from specs.

Candidate generalized payments flow for 'payments over time':

• Setup
  • Client opens payment channel to miner with funds F
• Proposal
  • At blocktime X, Client sends a set of N payment channel updates to the miner, for a file to be stored for M blocks, for a total of P FIL
    • Starting with T=0, each of the N updates is valid after block X+(M/N)T, and allows the withdrawal of P(M/N)*T FIL. Each update also contains an 'expiry' time of X+M, and a nonce of T.
    • These updates can be redeemed via the RedeemStoragePayment method on the payment channel actor. This method takes in the parameters from the update, as well as some initial validity parameters (to be discussed below)
  • After sending these to the miner, The miner will be able to receive payment if they actually perform the services in question.
• Cancellation
  • If the miner does not accept the proposal, the client can call CloseChannel. This will set a timeout that will allow the client to reclaim their funds after a timeout of T_ch blocks.
  • If the miner does accept the deal, but the client tries to cancel anyways in an attempt to cheat the miner, the miner can submit their payment channel update for T=0. This does not give the miner any money at that point, but forces the payment channel to be extended at least until block X+M.
• Redemption
  • At any point, the miner can claim payment, assuming that the requirements of one of the updates are met.
  • Once an update is applied, no other update with a lower nonce can be applied. And any updates with larger nonces will only pay out the difference in values between the last claimed payment and the current claimed payment.

Payment validity requirements:
To ensure that the miner only gets paid for doing their job, the payment channel updates need to be contingent on some specific parameters. For the inital payments for storage miners, these payments should be contingent on the existence, on-chain, of a sector that can be proved to contain the data in question (via a merkleproof).

from specs.

For most cases, the above flow should work for interacting with storage miners. For smaller files, the merkleproof required for submitting the update may be rather large. If that is a problem, we can then introduce another round of interaction in which the miner tells the client about a sector, and shows the client a merklepath from the sectors commD to their data. The client can then send a new set of payment channels with the condition changed to "Sector X exists and is valid".

from specs.

For client-repair-miner interactions, the same flow can be used, but the criteria on the updates can be changed to: "There exists a deal on chain that contains (via merklepath) data X". And those can be replaced with "Deal Y exists and is valid" with a successive round of communication.

from specs.