Limit the renter funds for new contracts without data

[npelov]

Usually (correct me if I'm wrong) when renter starts an upload and contracts are created it creates few backup contracts that will not be used unless something breaks. These contracts ideally stay empty. Weather or not I got it right it's a fact that there are empty contracts with amounts 60-80SC which lock at least double that according to collateral setting:

I don't fully understand the difference between account funding and remaining renter funds columns, but I think the limit I set in config is for account funding and the locked collateral is calculated from renter funds (again - correct me). As you see locked funds are 75 and 82 respectively in my two examples.

My suggestion (or you come up with better one) is to make 'Maximum balance' from config also valid for remaining renter funds the for contracts that never had any data. Once half of that - 5 SC is spent on data/bandwidth you can refresh the contract with the limits as before the change. The idea is to reduce SC locked in contracts that may not be used. That limit the locked funds for both renter and hostd (correct me).

I see lots of no-data contracts that have remaining renter funds = 10SC so maybe that's already implemented, but then what are the no-data contracts with >10SC? leftover (renewed) from V1? I remember there were much more no-data contracts that locked a lot of funds back in v1.

[n8mgr]

We do not want to restrict contract formations on the host end too much. There are already two major protections in place to protect hosts from abuse. The first is max collateral, meaning the renter cannot lock more than a specific value into a contract. The second is the collateral multiplier. Hosts will reject contracts unless the renter also locks enough allowance to justify the collateral. By default the renter needs to lock 1 SC for every 2 SC on the host end. The ratios look well within tolerance for both of your contracts, even favoring the host slightly, and the amounts locked are relatively low.

In terms of how renterd creates contracts. It creates 20 "extra" contracts by default, but data should be spread across the entire set as long as all the hosts are working. There's also a ramp up. Each contract is funded with enough SC to store 32GiB of storage. Each refresh doubles that up to a cap of 256GiB per refresh. This ramp was chosen as a good trade-off between costs to both parties and frequency of refreshes with regards to the average block time.

V2 solved most of the excessive locking problems. There will always be some risk of unused locked funds on the host end, but the renter is also locking SC away. Adding further restrictions adds additional complexity. We may revisit this in the future, but we are currently very happy with where hosts are right now in terms of collateral locking efficiency.

A couple of clarifications on the columns:

• Remaining renter funds is how much the renter has available to spend.
• Locked collateral is how much collateral you locked into the contract.
• Account funding is how much SC the renter has used to fund accounts, but not yet spent. The rest of the usage fields are pretty self explanatory. Account funds can be spent on either uploading or downloading.

[npelov]

Yes, I thought the problem is bigger because in V1 I had lots and lots of zero data contracts locking lots of coins. But that doesn't seem to be the case anymore - I have only these two in all 4 hosts. Anyway, it looks you have given it enough thought.

I still don't get the 'Remaining renter funds' vs 'Account funding' difference though.
Remaining renter funds - is that amount locked from renter? is it locked in the blockchain. is there a reading that explains it?
Account funds - spent on uploading or downloading, but not storage? Is this one for bandwidth usage and the other one is for storage?