bitshares-ui
bitshares-ui copied to clipboard
bitshares
Auto blacklist proposal scammers
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.
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.
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.
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.
How about several stages (2-3) until accepting a proposal and get an overview/information before last stage about what happens, if accepting proposal?
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).
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.
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?
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.
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
Three people were scammed only by openledger-security the last days, why does this not have a high priority tag?
Kencode suggested maybe having a sort of automated white list where only people you have sent funds to previously can create proposals for you.
Accounts could choose to 'accept proposals from everyone' somewhere in the permissions (i.e. for committee accounts that won't fall for scams and need to be open for proposals)
The frontend will soon listen to the blacklist of the account bitshares.org-notifications, maintained by UI team and bitshares.org owner. Furthermore, a news headline is added through that account as well (more precisely through the asset TEST), see #2679
a correction needs to be made for all the accounts that where hacked and lost control.
- restore control with weight to the public key (via concensus)
- retrieve back the funds that were taken and still on the bitshares platform.
- contact authorities for the funds that were withdrawals.
Please provide HOWTO
a correction needs to be made for all the accounts that where hacked and lost control.
-
restore control with weight to the public key (via concensus) -> not possible with weight (see attached)
-
retrieve back the funds that were taken and still on the bitshares platform. -> bustard hacker has moved already funds
-
contact authorities for the funds that were withdrawals. -> if they would answer and support not several days after hack, this would not happen
Hacker is "putler666", he should be stopped and banned from ledger!
Hacker is "putler666", he should be stopped and banned from ledger!
gdex-security created a proposal: Update account data for putler666
putler666 transfered everything in BTS to huibao000
- it is possible as the 21 witnesses can agree on it or have the committee agree on it. same goes with the other bullets.
- not all funds were moved. and if so then 3 is the way.
- take responsibility on your side, make the community aware of the hack, put pressure, but don't put the blame on others before you took full responsibility on it.
Do you how many times, I wrote them... Please provide HOWTO for
- restore control with weight to the public key (via concensus)?
create a new transaction approval type for that which requires the multi-sig of x commitee (even votes) to allow the ownership or weight of an account to be changed
I use bitshares desktop version 3.1.190618 (latest?) bitshares-UI to update goes to a different link, where is the latest version? Thanks.
a correction needs to be made for all the accounts that where hacked and lost control.
- restore control with weight to the public key (via concensus)
- retrieve back the funds that were taken and still on the bitshares platform.
- contact authorities for the funds that were withdrawals.
On 1.: This would require a BSIP. Are you interested in helping work it out?
Please advice for BSIP? I am interested to get my funds back.
The BSIP I had in mind won't get you your funds back unfortunately. It could restore access to accounts.
Just FYI this is a similar BSIP which restore access to accounts as well: https://github.com/bitshares/bsips/pull/149.
And there is a discussion about this issue: https://github.com/bitshares/bsips/issues/154
A lot of comments and communication to read. Any available instruction/link to restore access to account will be helpful?
It's impossible to restore access by now. That's why a new BSIP is needed if you want to restore access.
@startailcoon @sschiessl-bcp What progress had been made about this? Here are new reports:
I used 'send' to withdraw EOS to the bitshares account 'binancecleos', intending to withdraw it to Binance EOS account of the same name 'binancecleos'. This does not appear to be a Binance account. ... BTS accounts using exactly the same name as the Binance account for certain coins: deepcrypto8 : STEEM bnb136ns6lfw4zs5hg4n85vdthaad7hq5m4gtkgf23 : BNB These 3 accounts are traps set up to catch this mistake and all have payments into them, all presumably the same mistake
We should add those accounts to this page:
