Follow up: host and renter sync issues

[n8mgr]

Follow up from #83: if the renter and host aren't on the same block, their input proofs will be out-of-sync, and the transaction will be invalid. Therefore, the renter and host must agree on a validation context when forming and renewing a contract.

[lukechampine]

Any value we send, we have to deal with a small race between the call to cm.TipContext and w.FundTransaction

Hmm, true. Makes me wonder if FundTransaction should take (or return!) a ValidationContext.

The easiest fix would be to send the renter's ChainIndex in the initial ContractRequest and make the host slightly flexible, like the txpool.

Yeah, with cm.UpdateElementProof we should be able to implement the degree of flexibility needed. The tricky thing is that flexibility is "asymmetric" -- if the host is ahead of the renter, then it can adjust its proofs; but if the host is behind the renter, then it can't.

I suppose another option is to simply require the renter and host to be synced, aborting the RPC if they aren't. This will be occasionally annoying, but contracts are formed/renewed infrequently enough that it's not a huge inconvenience if you have to retry 1 minute later.

[n8mgr]

Makes me wonder if FundTransaction should take (or return!) a ValidationContext.

Another option, as you mentioned in our call, would be to have a ProofManager that updates and adds proofs to transactions. That would give us a single "source of truth" for proofs and lessen how many different modules throw them around. Building a contract resolution will have a similar race if the wallet and renter/host haven't processed the same blocks.

type ProofManager struct {
    AddElement(element types.StateElement)
    AddProofs(*types.Transaction) types.ChainIndex
}

I suppose another option is to simply require the renter and host to be synced, aborting the RPC if they aren't

I agree; having to retry isn't that bad. We should allow at least one block back to try and lessen the inconvenience, though.