Have an option for SP to reject deals from a bls account

[jennijuju]

Checklist

• This is not a new feature or an enhancement to the Filecoin protocol. If it is, please open an FIP issue.
• This is not a new feature request. If it is, please file a feature request instead.
• This is not brainstorming ideas. If you have an idea you'd like to discuss, please open a new discussion on the lotus forum and select the category as Ideas.
• I have a specific, actionable, and well motivated improvement to propose.

Lotus component

• lotus daemon - chain sync
• lotus miner - mining and block production
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt)
• lotus miner/market - storage deal
• lotus miner/market - retrieval deal
• lotus miner/market - data transfer
• lotus client
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

Improvement Suggestion

while randomly going through some gas trace os PSD message, we realized that for some PSD message that including deals made with clients that's using bls wallet causes up to ~40% gas usage of PSDs to be verifyingsiguature, which can be significantly saved if the client uses secp256k1.

verifySignature: map[crypto.SigType]int64{
			crypto.SigTypeBLS:       16598605,
			crypto.SigTypeSecp256k1: 1637292,
		},

lotus sp should have an option to say they want to reject such deals so that they can decrease the cost of deal onboarding for clients.

[jennijuju]

SP should encourage clients to use secp256k1 wallet unless client has strong preference.

[ribasushi]

Can they not just use the DealFilter hooks? Adding more and more stuff into lotus config goes against the "let's simplify" push... 😸

[jennijuju]

Can they not just use the DealFilter hooks? Adding more and more stuff into lotus config goes against the "let's simplify" push... 😸

Simplying filecoin protocol != “stop developing lotus to provide better ux/help user make better decisions using lotus”

What would be your strategy to document and make sure that SP, especially the new ones, adopt this rule in their dealfilter?

[ribasushi]

My strategy would be to have zero market-side config in "lotus the daemon" ( this means not adding any new ones, and very strongly discouraging existing ones, to the point of removing them in some distant future ).
All "dynamic decisions" should happen through "dynamic callbacks", which is what stuff like the Filter protocol implements.
Nearly every SP from the X-cohorts is asking for exactly this as well.

So yes - every SP is expected to have a sophisticated dynamic deal filter where they express decisions like this. These filters ( plural ) should not be maintained by lotus-team nor anyone at PL, aside from providing a bare-bones reference-implementation.

[jennijuju]

My strategy would be to have zero market-side config in "lotus the daemon" ( this means not adding any new ones, and very strongly discouraging existing ones, to the point of removing them in some distant future ). All "dynamic decisions" should happen through "dynamic callbacks", which is what stuff like the Filter protocol implements. Nearly every SP from the X-cohorts is asking for exactly this as well.

So yes - every SP is expected to have a sophisticated dynamic deal filter where they express decisions like this. These filters ( plural ) should not be maintained by lotus-team nor anyone at PL, aside from providing a bare-bones reference-implementation.

That is in our roadmap, however, not until Boost is ready for production. MinerX is a more experienced group and they know how to do things, most of the time. There was a very long time even them dont know how to write the filter scripts - still is the case for many other SPs and that's why tools CID gravity exists.

Meantime, lotus should provide easier configurable interfaces for SP before we completely decouple boost.

[dd45e640b42e6da7da96faee3996ef7c]

@whyrusleeping is this on the ask v2 radar?

how is ask v2 planned to be integrated into lotus? if we externalize the ask completely with v2 then we should not bother to implement this option into lotus.

[jennijuju]

@whyrusleeping is this on the ask v2 radar?

how is ask v2 planned to be integrated into lotus? if we externalize the ask completely with v2 then we should not bother to implement this option into lotus.

this is not - and I don’t think this should get to ask protocol. Happy to be convinced tho