Store Condition in Payment Channel

[acruikshank]

Description

The redeemer of a payment channel voucher will sometimes need to supply a significant amount of data as additional parameters to a condition, and generally speaking, that data will be the same from one voucher to the next. The payment broker should store the full condition in the payment channel.

In the case of miner payments, this means storing the verifyPieceInclusion condition including the sector id and piece inclusion proof. These should not change from one redeem to the next (but the condition must be replayed, because the miner's LastPoSt could go out of date).

Acceptance criteria

1. When a Redeem is successful, the payment broker sets a redeemed flag on the payment channel and stores a condition predicate with the concatenation of condition and redeemerSuppliedParams (the parameters actually sent in the message) as condition in the payment channel.
2. When Redeem or Close is called, and a condition exists in the voucher, and the redeemed flag is true, and paymentchannel.condition exists, and redeemerConditionParams is empty, the payment broker will construct the condition message from the cached condition.
3. In the above case, we will not overwrite the condition.

NOTE There is potential problem here that the payer could provide some vouchers with a condition that requires additional params, and then later vouchers that have conditions that require no parameters. If the target redeems one of the earlier vouchers successfully, and then attempts to redeem a no parameter voucher, we will try to use the old parameters and the voucher will fail.

This is not a problem for the existing storage client, storage miner scenario, and any valid case where this might happen is far fetched. If we do feel like we need to solve this, we should store a hash of the condition and only reuse parameters if the hashes match. For now this extra data on chain isn't worth it.

[rosalinekarr]

@acruikshank, would the redeemed flag on the PaymentChannel be redundant with the already existing AmountRedeemed field? Could we just check AmountRedeemed > 0?

[rosalinekarr]

For anyone reading this issue, my previous question was resolved offline. redeemed is not redundant because it is possible to redeem a value of zero.

[rosalinekarr]

@acruikshank, how should we handle acceptance criteria #1 when no condition is provided to the redeem method?

[acruikshank]

@rosalinekarr and I discussed in another channel. A nil condition passed into redeem should both allow the redeem to execute without checking a condition and clear the existing condition. This permits a last payment that requires a minimal information on chain if the target is willing to wait and the payer does not cancel the payment channel.