Skip to content

Contract management

David Vorick requested to merge contract-management into master

I have not gotten to the testing yet, and my notebook has a list of about 20 TODOs that I think will need to be done before this can be merged. But I tried to keep the change as simple as this:

Merge all contract management (tracking if a contract had money, renewing if not enough money, renewing if expiring, retiring if expired, forming new contracts, etc.) into a single loop in the codebase that gets called every time there's a new block. The loop is exclusive, so if you call the loop while another instance of the loop is running, the second call will just silently fail (as the first call is doing all the dirty work).

Some other changes ended up coming through as well. I tried to keep it minimal, but:

  • forming contracts and renewing contracts now has a cancelChan for the dial operation
  • allowance.Funds now reports the amount the host is spending on its active contracts. Trying to set the value to something else is a no-op. Another PR will juggle around what the values mean and figure out how to best preserve compatibility with the API
  • contract formation is a lot smarter. Looks at funds remaining, checks for price gouging, checks for other issues, is more aware of contract usefulness, etc.
  • contract formation is now one at a time, instead of all or nothing

There are two really big things missing here:

  • contractor has no way to provide feedback to the hostdb about failed connections and stuff. If a host is not responding to connections, or drops an upload, or isn't doing downloads, the host needs to have its score appropriately reduced. This will help protect renters against crappy hosts
  • the allowance stuff needs to be handled better. It's not okay to be completely ignoring the 'allowance.Funds' value that the user is setting. What's likely going to happen is that the existing fields are going to be deprecated, but we will map them onto new fields. I'll discuss more details when that PR arrives, but I'm thinking of 'allowance.MaxSpending' as replacing what is currently 'allowance.Funds'. In the API package, it'll translate one field into the other to preserve compatibility. And then what this PR is using as 'Funds' will probably be renamed to 'allowance.ActiveSpending' or something like that.

Merge request reports