Closed altafan closed 2 years ago
Shouldn't gen folder be at the base folder ie. api-spec/protobuf/gen and at same level be the protos api-spec/protobuf/ocean/v1 ?
I didn't changed this. gen/
is indeed in the base folder, this branch is even with master at this commit, so should be all ok.
Also we should add swagger support with Open API for JSON HTTP interface
Alright. I'm going to open a dedicated ticket as soon as this gets merged.
Note that, ideally, this PR wasn't expecting to make any change to api-spec (despite some bug fixing), but in the meanwhile @louisinger and I agreed out-of-bound to drop the "account key" way of referencing a wallet account in favor of just its name. The reason is that we want the system to pick a proper account derivation index for a new account, to prevent the client from choosing indexes of previously deleted accounts, for example. From this, since a client works with account labels from the very beginning of their lifecycles, it's not likely it will prefer to identify them via their indexes later. There seems to be no advantage in adding such complexity on the ocean-wallet side. Account index, just like the account extended key, can just be retrieved as an account detail when getting wallet info.
UPDATE: I added a uint32 sighash_type
field to both sign methods of the TransactionService in order for a client to specify one if needed. The system falls back to SIGHASH_ALL in case the user doesn't specify one.
@tiero this commit should fix the issue raised on taxi-daemon.
Moved proto version from v1alpha
to v1
.
This adds the very first version of the Ocean implementation of a single-key native-segwit wallet.
Design
The following is a representation of the project design as a bullet list from the inner layer to the outer:
Wallet/Account
to handle lock/unlock, key pairs derivation, etc, and related Repo.Utxo
representing an output owned by one of the accounts of the wallet, and related Repo. Utxos are all stored as revealed.Transaction
representing a tx involving one or more wallet accounts, and related Repo (this was not present in tdex-daemon).WalletService
- TODO: Restore.AccountService
- complete.TransactionService
- TODO: Mint, Remint, Burn, Pegin, ClaimPegin.NotificationService
- complete.RepoManager
- handles connection with concrete db and allows to register handlers for domain events.BlockchainScanner
- a sort of revised tdex-daemon's blockchain listener. A service listening to blockchain/mempool events and notifying the wallet about utxos/txs related to addresses of its accounts.MnemonicStore
- the place where to persist the wallet mnemonic in plain textMnemonicCypher
- a service that encrypts/decrypts a text using a password.CoinSelector
- a service that implements a specific coin selection strategy and returns a subset of the give utxos covering target amount and asset.RepoManager
- inmemory and badger implementations.BlockchainScanner
- neutrino implementation.MnemonicStore
- inmemory implementation (makes us of viper).MnemonicCypher
- AES128 implementation.CoinSelector
- smallest subset strategy impl (already implemented in tdex-daemon).gRPC, with or without TLS enabled. Let's consider adding: macaroon auth, grpc gateway. For both topics, we will eventually open dedicated tickets if we want them as features of the grpc interface.This service is intended to be used locally as sidecar for other service, therefore it doesn't need TLS/macaroons auth.Flow
The list below is a description of the flows generated by domain events:
Please @tiero, @louisinger review this.