Auto blacklist proposal scammers

[froooze]

Is your feature request related to a problem? Please describe.
Getting scam proposals is still annoying and I don't have any information what the proposal does from the UI.

Describe the solution you'd like
Blacklist people, who abuse the system:

• Proposals per hour or day
• How old the account is
• How much is the account value in BTS

With blacklist, they can still be visible, but in a less visible way and with warnings. Now I have to pay a fee to remove this, the UI could do this, without any fees.

[abitmore]

I got an idea. Let someone or a group with reputation (manually) maintain a blacklist on chain, E.G. with the on-chain account blacklisting feature, so the list can be updated quickly enough, better for UX than current mechanism which only updates when a new release is out. Although it's a somehow centralized solution, IMHO it would work. The maintainer account(s) can be multi-sig thus would be decentralized to an extent. We can even vote in a worker for the maintenance work.

For every account in the blacklist, show a warning icon next to the account name whenever it appears (on every page that shows account names). Ideally we can have a setting to directly filter out actions related to the accounts.

[froooze]

User should decide, if it should be removed completely from visibility.

[startailcoon]

We could, with abitmore's idea, also be able to handle whitelisted accounts as verified good accounts. The user could then toggle to hide all blacklisted accounts by this entity.

[abitmore]

By the way users are able to configure their own black/white lists, I guess we can (ab)use the lists for this feature, although it was not by-design (black/white lists are meant to be used by asset admins to authorize actions related to assets).

Actually, this is a non-consensus feature, ideally we can store user settings with custom_operation (rather than account_whitelist_operation which is consensus-related), then we need to write a plugin to track the data, with this approach, we can even design a mechanism so a user can decide to use another user's or a group of other users' lists.

[HB1github]

How about several stages (2-3) until accepting a proposal and get an overview/information before last stage about what happens, if accepting proposal?

[rsswlkr]

Just fix at the root - can't create proposed transaction until users added <> to whitelist/contacts. There should be no legit reason for creating a proposed tx unless the other party has been informed first. Up to 3rd parties to make sure proposals aren't rejected. Auto-popup 'Reject' button if not on users whitelist/contacts; extreme version, auto-reject (or default user setting).

[shulthz]

Just fix at the root - can't create proposed transaction until users added <> to whitelist/contacts. There should be no legit reason for creating a proposed tx unless the other party has been informed first. Up to 3rd parties to make sure proposals aren't rejected. Auto-popup 'Reject' button if not on users whitelist/contacts; extreme version, auto-reject (or default user setting).

This is the right way.

[bitfanatic]

Just fix at the root - can't create proposed transaction until users added <> to whitelist/contacts. There should be no legit reason for creating a proposed tx unless the other party has been informed first. Up to 3rd parties to make sure proposals aren't rejected. Auto-popup 'Reject' button if not on users whitelist/contacts; extreme version, auto-reject (or default user setting).

Could the feature be enhanced with a extra step
Where the proposing account if not already is whitelisted
Has to be approved with a signed message?

[abitmore]

can't create proposed transaction until users added <> to whitelist/contacts

I don't think it should be default behavior in core. It just like saying "don't ring your phone if someone not in your contact list called you", or "reject emails from people not in contact list", usually a client-side feature. Although it's possible to implement it as a core parameter, I think it's better to make it opt-in.

unless the other party has been informed first

The proposal IS informing the party. We just need to make it clear enough.

[froooze]

My thoughts on implementation:

• Make clear, that proposed transaction means handing over ownership
• Auto hide proposals from blacklisted accounts (no user interaction needed)
• Two confirmations are needed for proposals, which are not whitelisted