Commit Graph

52 Commits

Author SHA1 Message Date
Anthony Laibe da2f155f2d feat: add account position 2023-06-26 16:15:48 +02:00
Ivan Belyakov ad1b8b6d43 fix(wallet): added `remove` event for accounts. Stop loading
transfers for removed account

Updates #10246
2023-06-05 08:22:08 +02:00
Khushboo-dev-cpp 8b91e3aaaf
chore: Add ColorId for Wallet accounts that can be shared with mobile (#3521) 2023-06-02 17:06:51 +02:00
Sale Djenic 34f5ef031c feat: a profile keypair name follows display name
As part of this commit `UpdateKeypairName` endpoint added,
will be used to rename all but the profile keypairs.
2023-05-25 19:46:47 +02:00
Sale Djenic eeaaf0ce3f feat: accounts improvements applied
- old `accounts` table is moved/mapped to `keypairs` and `keypairs_accounts`
- `keycards` table has foreign key which refers to `keypairs.key_uid`
- `Keypair` introduced as a new type
- api endpoints updated according to this change
2023-05-25 19:46:47 +02:00
Sale Djenic 189c7a6919 chore: `keypairs` package which actually refers to keycards is renamed to `keycards` package
This commit renames few api endpoints:
- old `AddMigratedKeyPairOrAddAccountsIfKeyPairIsAdded` renamed to `AddKeycardOrAddAccountsIfKeycardIsAdded`
- old `GetAllMigratedKeyPairs` renamed to `GetAllKnownKeycardsGroupedByKeyUID`
- old `GetMigratedKeyPairByKeyUID` renamed to `GetKeycardByKeyUID`
- old `DeleteKeypair` renamed to `DeleteAllKeycardsWithKeyUID`
2023-05-10 09:27:51 +02:00
Sale Djenic 31144ed5a3 chore: `password` removed from the `DeleteAccount` function
Asking for a password when removing a key is not necessary.
2023-05-09 10:48:44 +02:00
Sale Djenic 392d808af0 feat: `GetAccountsByKeyUID` endpoint added 2023-04-25 14:03:32 +02:00
Sale Djenic c8ef2c1a7f fix: deleting derived from address keystore file applied to all keypairs being migrated instead to a profile keypair only 2023-04-25 14:03:32 +02:00
Sale Djenic 34badf2405 fix: `SaveAccounts` endpoint changed to `SaveAccount` which requires a single account to be provided instead of array of accounts 2023-04-21 16:35:24 +02:00
Sale Djenic 5d7da45f07 feat: `VerifyKeystoreFileForAccount` endpoint added 2023-04-21 16:35:24 +02:00
Sale Djenic a37b586915 fix: delete account endpoint updated
Local keystore file deletion is done only if an account being deleted is migrated to a keycard.
2023-04-11 12:14:35 +02:00
Sale Djenic 5d79b3514c feat: `GetRandomMnemonic` endpoint added to accounts api 2023-03-28 16:19:27 +02:00
Sale Djenic d30c88b80e neat: accounts and wallet api sorted out
Unused endpoints removed, new ones with more meaningful naming are added and
their purposes were revised.
2023-03-28 16:19:27 +02:00
Sale Djenic b660672a60 chore(accounts): `type` column from `accounts` table updated
`type` column is set for all rows to appropriate value. Before this change
accounts which were generated from the keypair created importing seed phrase
had `generated` value for the `type`.

According to above, a function for generating an account sets the `type`
based on the passed derive from address.
2023-03-07 11:28:06 +01:00
Sale Djenic 2d16e7b891 feat(keycard): keycard details are being synced among devices
- sync all keycards state
- sync every keycard change
2023-02-27 16:03:02 +01:00
Sale Djenic 30e20b42a0 chore(keycard): `last_update_clock` column added to `keycards` table
`last_update_clock` will be used later for synchronization.
All keypair functions take clock value in consideration when
making a decision whether to perform an action or not.
2023-02-27 16:03:02 +01:00
Sale Djenic c207c88cd3 chore(keycard): `AddMigratedKeyPair` renamed to `AddMigratedKeyPairOrAddAccountsIfKeyPairIsAdded` which better describes what that function does 2023-02-27 16:03:02 +01:00
Sale Djenic 242c85cd6a fix: `DeleteAccount` and `AddMigratedKeyPair` declaration change
Both functions `DeleteAccount` and `AddMigratedKeyPair` require password to be provided
in order to delete account from the keystore properly (removing account from the cache and
deleting corresponding local keystore file).

Password parameter can be also an empty string, since there are cases when an account is
not added to the keystore (in case of keycard account), so we have nothing to delete.
2023-02-02 15:53:25 +01:00
Sale Djenic c8994fe175 test: `TestConvertAccount` test update
This tests the entire process of converting a regular account to a keycard
account and then converting that keycard account back to a regular account.

For the need of this test I had to improve `DeleteAccount` function, cause the
previous implementation didn't remove account from the keystore cache, but
only from the keystore.
2023-01-27 13:20:52 +01:00
Sale Djenic 902d4b7501 fix(keycard): convert regular to a keycard account process fixed 2023-01-27 13:20:52 +01:00
Sale Djenic d8e2884d4e feat(keycard): `DeleteKeypair` endpoint added 2023-01-27 13:20:52 +01:00
Sale Djenic dbf8a3c6be feat(keycard): `DeleteAccountForMigratedKeypair` endpoint added 2023-01-13 11:09:57 +01:00
Sale Djenic d7caf67a52 feat(keycard): `RemoveMigratedAccountsForKeycard` endpoint added 2023-01-13 11:09:57 +01:00
Sale Djenic 691c930828 fix: `GetAllKnownKeycards` new keypair endpoint added
Handling results of `GetAllMigratedKeyPairs` and `GetMigratedKeyPairByKeyUID`
endpoints updated in a way that account address is unique in the address list.
2022-12-12 11:40:56 +01:00
Sale Djenic 77b7ce5a09 fix: corresponding keystore files are deleted when account is migrated to a keycard 2022-11-09 18:07:16 +03:00
Sale Djenic c2b17acc07 feat: 5 functions added, the same as we had, but without pass verification (need for a keycard users)
The following three new functions introduced, for which password should be verified
on the client side (in case of a keycard user we don't have keystores to check pass):
- `AddAccountWithMnemonicPasswordVerified`
- `AddAccountWithMnemonicAndPathPasswordVerified`
- `AddAccountWithPrivateKeyPasswordVerified`
- `GenerateAccountPasswordVerified`
- `GenerateAccountWithDerivedPathPasswordVerified`

update
2022-10-28 13:27:55 +02:00
Richard Ramos b8fd999b54
fix: lint (#2845)
Co-authored-by: Samuel Hawksby-Robinson <samuel@samyoul.com>
2022-09-27 18:59:02 -04:00
Sale Djenic 698c32f3e3 chore: `UpdateKeycardUID` function exposed 2022-09-21 15:01:53 +02:00
Sale Djenic 00aa103788 feat: `keypairs` table added and necessary endpoints exposed via accounts api 2022-09-12 09:52:22 +02:00
Sale Djenic 41f3a19a49 feat: `key_uid` column added to the `accounts` table 2022-09-12 08:51:15 +02:00
Sale Djenic 655a406b0c feat: verify password function exposed via api 2022-08-29 14:09:32 +02:00
Samuel Hawksby-Robinson 26b33aa09d Added AccountType to enforce strict typing on Accounts
Also a tpyo was fixed, probably introduced by me.
2022-08-25 22:01:43 +01:00
Vitaliy Vlasov 3dee94e505 Wallet sync for generated accounts 2022-07-06 19:24:43 +03:00
Vitaliy Vlasov 011238b1d1 Wallet sync 2022-05-18 15:25:20 +03:00
Khushboo-dev-cpp 15e5584ed2
feat: Add hasActivity param to derived addresses (#2663)
Added functionality to find target address when 6th param in path is added
for ex: "m'/44'/60'/0'/0/500" reperents the Address at the 500th index

Added a api to get the Address derived from a private key
2022-05-18 13:31:45 +02:00
Anthony Laibe cf8941c1d8
fix: delete account sync keystore (#2652) 2022-05-12 13:06:58 +02:00
Anthony Laibe 2485e84bf5
fix: default derived from for status account (#2651) 2022-05-09 10:00:48 +02:00
Khushboo-dev-cpp 5f92e84c19
feat: Add "alreadyCreated" field for a derived address to state if that wallet address is already used (#2644) 2022-05-03 10:14:49 +02:00
Khushboo-dev-cpp b83f4a6c83
fix: Add derivation path to wallet account generation (#2618) 2022-04-13 11:15:26 +02:00
Anthony Laibe 9fef24917a
fix: generation path (#2637) 2022-04-11 12:35:18 -04:00
Anthony Laibe f1cd9120c9
fix: prevent to import same account twice (#2633) 2022-04-11 11:18:28 -04:00
Anthony Laibe dd86a82a0f
fix: Align generated account and key store (#2628) 2022-04-08 09:56:38 -04:00
Samuel Hawksby-Robinson e67592d556
Sync Settings (#2478)
* Sync Settings

* Added valueHandlers and Database singleton

Some issues remain, need a way to comparing incoming sql.DB to check if the connection is to a different file or not. Maybe make singleton instance per filename

* Added functionality to check the sqlite filename

* Refactor of Database.SaveSyncSettings to be used as a handler

* Implemented inteface for setting sync protobuf factories

* Refactored and completed adhoc send setting sync

* Tidying up

* Immutability refactor

* Refactor settings into dedicated package

* Breakout structs

* Tidy up

* Refactor of bulk settings sync

* Bug fixes

* Addressing feedback

* Fix code dropped during rebase

* Fix for db closed

* Fix for node config related crashes

* Provisional fix for type assertion - issue 2

* Adding robust type assertion checks

* Partial fix for null literal db storage and json encoding

* Fix for passively handling nil sql.DB, and checking if elem has len and if len is 0

* Added test for preferred name behaviour

* Adding saved sync settings to MessengerResponse

* Completed granular initial sync and clock from network on save

* add Settings to isEmpty

* Refactor of protobufs, partially done

* Added syncSetting receiver handling, some bug fixes

* Fix for sticker packs

* Implement inactive flag on sync protobuf factory

* Refactor of types and structs

* Added SettingField.CanSync functionality

* Addressing rebase artifact

* Refactor of Setting SELECT queries

* Refactor of string return queries

* VERSION bump and migration index bump

* Deactiveate Sync Settings

* Deactiveated preferred_name and send_status_updates

Co-authored-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
2022-03-23 18:47:00 +00:00
Khushboo-dev-cpp 5f81b3acf9
feat: Added emoji params for a wallet account (#2582) 2022-03-11 11:59:15 +01:00
Anthony Laibe 2b8b2be1f2
feat: move create accounts to status go (#2492) 2022-01-24 10:29:18 +01:00
Roman Volosovskyi a92a95cf83
status-im/status-react#9203 Faster tx fetching with less request
*** How it worked before this PR on multiaccount creation:
- On multiacc creation we scanned chain for eth and erc20 transfers. For
  each address of a new empty multiaccount this scan required
  1. two `eth_getBalance` requests to find out that there is no any
     balance change between zero and the last block, for eth transfers
  2. and `chain-size/100000` (currently ~100) `eth_getLogs` requests,
     for erc20 transfers
- For some reason we scanned an address of the chat account as well, and
  also accounts were not deduplicated. So even for an empty multiacc we
  scanned chain twice for each chat and main wallet addresses, in result
  app had to execute about 400 requests.
- As mentioned above, `eth_getBalance` requests were used to check if
  there were any eth transfers, and that caused empty history in case
  if user already used all available eth (so that both zero and latest
  blocks show 0 eth for an address). There might have been transactions
  but we wouldn't fetch/show them.
- There was no upper limit for the number of rpc requests during the
  scan, so it could require indefinite number of requests; the scanning
  algorithm was written so that we persisted the whole history of
  transactions or tried to scan form the beginning again in case of
  failure, giving up only after 10 minutes of failures. In result
  addresses with sufficient number of transactions would never be fully
  scanned and during these 10 minutes app could use gigabytes of
  internet data.
- Failures were caused by `eth_getBlockByNumber`/`eth_getBlockByHash`
  requests. These requests return significantly bigger responses than
  `eth_getBalance`/`eth_transactionsCount` and it is likely that
  execution of thousands of them in parallel caused failures for
  accounts with hundreds of transactions. Even for an account with 12k
  we could successfully determine blocks with transaction in a few
  minutes using `eth_getBalance` requests, but `eth_getBlock...`
  couldn't be processed for this acc.
- There was no caching for for `eth_getBalance` requests, and this
  caused in average 3-4 times more such requests than is needed.

*** How it works now on multiaccount creation:
- On multiacc creation we scan chain for last ~30 eth transactions and
  then check erc20 in the range where these eth transactions were found.
  For an empty address in multiacc this means:
  1. two `eth_getBalance` transactions to determine that there was no
     balance change between zero and the last block; two
     `eth_transactionsCount` requests to determine there are no outgoing
     transactions for this address; total 4 requests for eth transfers
  2. 20 `eth_getLogs` for erc20 transfers. This number can be lowered,
     but that's not a big deal
- Deduplication of addresses is added and also we don't scan chat
  account, so a new multiacc requires ~25 (we also request latest block
  number and probably execute a few other calls) request to determine
  that multiacc is empty (comparing to ~400 before)
- In case if address contains transactions we:
  1. determine the range which contains 20-25 outgoing eth/erc20
     transactions. This usually requires up to 10 `eth_transactionCount`
     requests
  2. then we scan chain for eth transfers using `eth_getBalance` and
     `eth_transactionCount` (for double checking zero balances)
  3. we make sure that we do not scan db for more than 30 blocks with
     transfers. That's important for accounts with mostly incoming
     transactions, because the range found on the first step might
     contain any number of incoming transfers, but only 20-25 outgoing
     transactions
  4. when we found ~30 blocks in a given range, we update initial
     range `from` block using the oldest found block
  5. and now we scan db for erc20transfers using `eth_getLogs`
     `oldest-found-eth-block`-`latest-block`, we make not more than 20 calls
  6. when all blocks which contain incoming/outgoing transfers for a
     given address are found, we save these blocks to db and mark that
     transfers from these blocks are still to be fetched
  7. Then we select latest ~30 (the number can be adjusted) blocks from
     these which were found and fetch transfers, this requires 3-4
     requests per transfer.
  8. we persist scanned range so that we know were to start next time
  9. we dispatch an event which tells client that transactions are found
  10. client fetches latest 20 transfers
- when user presses "fetch more" button we check if app's db contains next
  20 transfers, if not we scan chain again and return transfers after

small fixes
2020-01-23 10:36:11 +02:00
Pedro Pombeiro c8a911ebd1 Use goimports instead of gofmt 2020-01-06 10:17:23 +01:00
Pedro Pombeiro dd894ece15 Start abstracting geth Keystore 2019-12-19 14:11:48 +01:00
yenda f855228010 add accounts_deleteAccount method (#1738)
* add accounts_deleteAccount method

* set account created and updated at dates, order by creation date
2019-12-16 10:23:36 -05:00