How to set proper start_epoch for a storage deal

[longfeiWan9]

Source from a Slack message.

I have a question about the dealClient on the makeDealProposal function about the start_epoch parameter. Is there a problem with the Storage Provider accepting a deal after the start_epoch of the deal? I this deal going to get included? I am thinking to add this as current epoch + 2days( 172800 epochs(blocks)).

The question is actually around setting a proper start_epoch when we propose a storage deal with SP?

[longfeiWan9]

Thanks for all the detailed information provided by @f8-ptrk.

To summary up the discussion on Slack.

Roughly, the lifetime of a storage deal includes:

• Publish a storage deal proposal on-chain by storage client - setting start_epoch.
• Storage provider picks up deal proposals. agrees on deal terms with the client
• Data Transfer from clients to SP
• SP commit a sector to seal deals before start_epoch
• SP publishes storage deals on-chain

But transferring data from clients to SP and sealing sectors takes a lot of time, so it would be better to set up start_epoch properly so SP has enough time to receive data and seal deal proposals in the sector.

Based on the software (Lotus or boost) that SP is running, it will potentially reject deal proposals if they do not have a chance to land on-chain with a very short start_epoch according to the analysis logic.

Experience and suggestions:

On Filecoin Mainnet:

• Patrick from Facktor8: their SP would like to discover the deal proposal 24 hours before start_epoch, which means at least setting start_epoch as 24 hours later, but 48 hours will be ideal.
• popular storage platforms, web3.storage for example, uses72h between sending the proposal to SPs and start_epoch.

On Hyperspace:

• 24h is safe. And especially the miner ending in t01129 will seal everything you send to it if the start epoch is within 2-3h.