Single-key native segwit Ocean implementation

[altafan]

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:

• Domain layer: the core domains are essentially a copycat of those of tdex-daemon. Domain repositories generate events for real-time updates on the internal status of wallet and relates accounts/utxos/txs:
  • 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).
• Application layer: core services reflecting the proto of the api-spec. These services make use of external ones, "hided" behind "portable interfaces" to avoid lock-in dependencies in the core business logic:
  • WalletService - TODO: Restore.
  • AccountService - complete.
  • TransactionService - TODO: Mint, Remint, Burn, Pegin, ClaimPegin.
  • NotificationService - complete.
• Ports layer: a collection of services defined as interfaces used at application level:
  • 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 text
  • MnemonicCypher - 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.
• Infrastructure (implementation) layer: this is not a proper layer but rather a collection of implementations of the core portable interfaces:
  • 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).
• Interface layer:
  • 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:

• Unlocking the wallet: The grpc service start with only its WalletService registered on the public reachable interface and registers a handler to get notified whenever the wallet is unlocked. When this happens, the service registers the missing service to the public interface.
• Creating an account: When a new account is created, ocean spawns a dedicated blockchain scanner for that account, which is stopped only if the account is deleted or the wallet switched off. At wallet restart, ocean takes care of spawning a bc scanner for every existing account and start watching all its derived addresses.
• Deriving a new address: A new account address can be derived by either the user or the wallet itself (change address, when crafting a tx). Whenever one or more addresses are derived, those are passed to the account's bc scanner in order to start watching them and get eventually notified about related utxos/txs. When a tx report is received, the tx itself and the utxos owned by the wallet are stored in the related repositories.
• Selecting utxos: When asking the wallet to select utxos for a target amount and asset, those returned in response are temporarily locked by the system to prevent double-spending them in other txs. Whenever a utxo is locked, the system spawns a goroutine waiting for a predefined expiration window before unlocking it if still locked to prevent locking utxos forever. Since it might happen that the wallet is switched off while a utxo was locked, at every startup, the wallet checks if there utxos that can be directly unlocked or for which spawning goroutines waiting for the time left until lock expirtation.

Please @tiero, @louisinger review this.

[altafan]

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.

[altafan]

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.

[altafan]

@tiero this commit should fix the issue raised on taxi-daemon.

[altafan]

Moved proto version from v1alpha to v1.